Re: Segment register support for the i386

[Alan Lehotsky <lehotsky at tiac dot net>]

At 12:22 +0300 1/1/00, Denis Chertykov wrote:
>Alan Lehotsky <lehotsky@tiac.net> writes:
>
>>  >>  Something like PCODEmode and PDATAmode.
>>
>>	Yes.  That would help.  I've had to work around problems
>>	in the machine-independent parts of GCC for my ADI SHARC
>>	port dealing with the distinction between code and data
>>	addressing.
>
>As I know ADSP 2181 also uses hacks inside machine-independent parts
>of GCC. (Is this your work ?)


	No, I'm innocent of that crime :-)

	I am supporting the SHARC compiler for Mercury Computer Systems,
	the original hacks were done by Analog Devices when they first
	did the port for the 21020 DSP chip.

>Why you use `pm' and `dm' modifiers instead of __attribute__ ((..))
>which is standard in GCC. Also you can access PM data with macros.
>It's not so readable as `pm' modifier but it's standard.

	I actually think the port predates __attribute__.  I've modified
	Mercury's code to use __attribute__ (but left in the old PM
	and DM modifiers for backwards compatibility.

	But even with that, it was necessary to make front-end modifications
	to deal with two address spaces.  There are just a lot of places
	that assume that Pmode covers all the bases.

>  >
>>	As an architectural data-point, the SHARC has two different
>>	size pointers - a 32 bit one (DM) and a 24 bit one (PM).
>>	The address spaces on this machine overlap somewhat.
>
>SHARC always have only 32bits registers (40bits in floating point mode).
>Or I'm wrong ?


	The PM registers are all 24 bits.  They can only physically
	address 16M words of memory.  [When you assign from a PM register,
	it sign-extends into 32 bits....]

	My crime was adding a THIRD kind of pointer - namely a 30 bit
	word address with two bits to indicate "byte-in-word" so that
	the 'char' and 'short' type could be supported as 8 and 16
	bit datums.  This also rippled thru the front end in order that
	the code optimization wouldn't suffer.

>
>IMHO change value of POINTER_SIZE according with PXXXmode are very
>difficult.
>IMHO if we want to make this work (I want) we must split this work to
>more simple stages.
>Any suggestions ?

	Mercury is still using 2.8.1 as a code-base.  [It took me the
	two years (part time) to convert from a 2.3.3 based port to
	the 2.8.1]  If I ever convince them to move to 2.95 and beyond,
	I'd like to discuss how we could support multiple address
	spaces in a more portable fashion.  And I'd want to contribute
	work to help.   But right now, I'm not actively enhancing the
	SHARC compiler - just fixing bugs.

-- Al
------------------------------------------------------------------------

		    Quality Software Management
		http://www.tiac.net/users/lehotsky
			lehotsky@tiac.net
			(978)287-0435 Voice
			(978)808-6836 Cellular
			(978)287-0436 Fax/Data

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation