This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: New port (ip2k)
- From: Alan Lehotsky <apl at alum dot mit dot edu>
- To: Denis Chertykov <denisc at overta dot ru>
- Cc: law at redhat dot com, Denis Chertykov <denisc at overta dot ru>,Joe Buck <Joe dot Buck at synopsys dot com>, gcc at gcc dot gnu dot org,Pavel Baranov <pavel dot baranov at ubicom dot com>
- Date: Wed, 29 May 2002 16:25:26 -0400
- Subject: Re: New port (ip2k)
- References: <32455.1022701233@porcupine.cygnus.com><y9e2pvqc.fsf@localhost.localdomain>
At 12:03 AM +0400 5/30/02, Denis Chertykov wrote:
>law@redhat.com 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.
2/ explained why it is necessary so that it can be approved
by the reload maintainer.
(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.
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....]
--
Quality Software Management
http://home.earthlink.net/~qsmgmt
apl@alum.mit.edu
(978)287-0435 Voice
(978)808-6836 Cell
Software Process Improvement / Management Consulting
Language Design / Compiler Implementation