This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: New port (ip2k)
At 3:19 AM +0400 5/30/02, Denis Chertykov wrote:
>Alan Lehotsky <apl@alum.mit.edu> writes:
>.....
> > 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):
>
>@findex LIMIT_BASE_REG_CLASS
>@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
>modes.
>
>If not defined, it will default to BASE_REG_CLASS.
Oh, I guess I did write up the doc for the GCC Porting Guide documents.
It's been a year since I've thought about this stuff....
Maybe I'm not quite
as bad a boy as I originally thought :-)
>
>@findex SECONDARY_RELOAD_CLASS
>@findex SECONDARY_INPUT_RELOAD_CLASS
>
>
>>
>> 2/ explained why it is necessary so that it can be approved by
>> the reload maintainer.
>
>You already explained it in text below.
Sorry if I'm being pedantic here.....
Well, we need to follow the format for a patch, namely providing
1/ an explanation of the problem
2/ the diff's that implement the fix
3/ the changelog entry
4/ certify that we built and bootstrapped a compiler with
the patch in?
<< did I forget anything >>
What I just did was a handwave from memory, and the
description below sounds
like it might be equivalent to LIMIT_RELOAD_CLASS, but it isn't because
LIMIT_BASE_REG_CLASS lets you look at the RTX....
>
>
>
>Ohhhhhhh.
>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.
It would be REALLY nice if your AVR port could use LIMIT_BASE_REG_CLASS
as an additional existance proof that this is something
generally useful
(and otherwise very difficult to work around....)
>
>
>>
>> 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....]
>
>Denis.
>PS: May be a will continue answer. I must sleep now.
Yow! You must be about 9 hours ahead of me, talk about burning the
midnight oil! (Or are you far enough North that you're
already seeing very
long days?
Regards,
Al
--
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