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)

At 3:19 AM +0400 5/30/02, Denis Chertykov wrote:
>Alan Lehotsky <> 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):
>@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.

	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 :-)

>>	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....

>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....]
>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?


		    Quality Software Management
		          (978)287-0435 Voice
		          (978)808-6836 Cell

	Software Process Improvement / Management Consulting
	     Language Design / Compiler Implementation

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