This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New port (ip2k)

Alan Lehotsky <> writes:

> At 12:03 AM +0400 5/30/02, Denis Chertykov wrote:
> > writes:
> >
> >>   In message <k7pmsu9e.fsf@localhost.localdomain>, Denis Chertykov writes:
> >>   > > Also note the work may be original based on work Red Hat did
> >> for Ubicom --
> >>   >   > > if that is the case, then the underlying work would be
> >> covered by Red Hat'
> >>   > > blanket copyright assignment.
> >>   >
> >>   > What must we have to commit port ? (Which disclaimers and assignments)
> >>  No additional assignments from Red Hat are needed -- again, this work is
> >>  covered by Red Hat's blanket assignment to the FSF.
> >
> >So, Can I send port for approval right now ?
> >
> >Technical question:
> >ip2k port have a macro LIMIT_BASE_REG_CLASS which used two times in reload.c
> >Just a two call. Can it be approved ?
> >I can describe a problem more detailed if required.
> 	This is where I suppose I should "cringe" with a certain
> amount of pent-up
> 	guilt.  But, please keep in mind Bismarck's observation about
> "sausages and
> 	politics" - the IP2K is *NOT* for the faint-of-heart compiler
> developer....
> 	Some "history" for the listening audience....
> 	This was a change I made when doing the IP2K port
> originally. It clearly needs
> 	1/ to be documented and described in the porting guide's
> reload section.  I'm a bad
> 	boy for not doing that at the time I implemented the fix.

What is "porting guide's reload section" ?
I have found the following fragment in tm.texi (UBICOM's CVS):

@item LIMIT_BASE_REG_CLASS (@var{x}, @var{mode})
A C expression that alters the BASE_REG_CLASS which would be used to
load the @var{x} as an address to access memory in @var{mode}.  This is
useful on machines where some base registers don't support all access

If not defined, it will default to BASE_REG_CLASS.


> 	2/ explained why it is necessary so that it can be approved by
> the reload maintainer.

You already explained it in text below.

> 	 (It all has to do with the fact that
> 	the IP2K has only 3 address registers, SP, DP and IP.  IP is
> only capable of
> 	addressing with zero-displacement, the other two pointer
> registers can do
> 	something like 0..127 displacement if I recall correctly.  Without the
> 	LIMIT_BASE_REG_CLASS, we end up ALWAYS using DP and never using IP
> 	because we don't know when it's safe to do so.  LIMIT_BASE_REG_CLASS
> 	looks at the address (I'm working from hazy memory here) and
> discovers that
> 	a narrower register class is acceptable here.
> 	I also think that there are a couple of other places in reload
> that need patches to work with the IP2K, in particular, there is a
> patch I posted regarding having two places in reload that call
> find_reloads_address() with a NULL instead of a reference to the MEM
> that is being reloaded.  These need to pass down the MEM, or else
> the LEGITIMIZE_RELOAD_ADDRESS macro never gets a chance to fix those
> addresses.
> 	This causes bad things to happen, as we don't get a chance to
> reload spilled
> 	values that are at stack displacements too far away for simple
> SP+offset
> 	addressing.

I have a very very clean understanding of this problem. 
I had a similar problem with AVR port.
I solve such problem in different way:
1. Simulate memory access by PROBLEM_POINTER (IP for ip2k and X for avr);
2. Reload all wrong addresses which handled by LEGITIMIZE_RELOAD_ADDRESS;
3. Simulate SP+offset-longer-than-normal.

IMHO: All these problems (PROBLEM_POINTER and SP+offset-longer-than-normal)
      can be resolved if LEGITIMIZE_RELOAD_ADDRESS will be called for
      any bad address.
IMHO: This is a point for fix.

> 	Denis, I'll be happy to help write up the description - but
> you will need to figure out the patch to reload.  [There were source
> markers around all those things as a reminder that this was a
> precondition to getting the port into shape for submission....]

PS: May be a will continue answer. I must sleep now.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]