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

	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

	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 

		    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]