Re: Alias code - how does the SHARC do it..

[Alan Lehotsky <lehotsky at tiac dot net>]

As to how the sharc handles the two memory spaces, the simple answer is

	BADLY.

:-)

The expanded answer is that we have added two attributes (parsed like
volatile),

	__DM__
	__PM__

that indicate which address space a pointer reference accesses.  This is
important
on the SHARC for two reasons:

	1/ parallelism.  The DSP can do TWO memory operations (fetch or store)
		in one instruction, one on each of the PM and DM busses.

	2/ address space and speed.  The PM bus is a 24 bit address bus and can
access
	 	fast on-chip memory, while the DM bus is a full 32 bit address and
can be
		off-chip (and I think on-chip too).

The attributes are used to set the size of accesses to DMmode or PMmode (which
requires a LOT of modifications to the front end where there are too many
simplifications using the Pmode #defined value.

The PMmode vs. DMmode is also used to control register allocation, such
that the
correct DAG registers are allocated for different kinds of pointers, viz.

		int PM *p;		// Candidate for DAG 2 registers (24 bits) because it
						// accesses PM data

		static char DM c;	// data word allocated in DM memory (which is
the default
							// for static data anyway...


I've left out a lot of the grody details, including extra code in reload
to handle indexed addressing and some of the horrible problems that occur when
we encounter postmodify addressing and don't have reload registers

I'm not happy with the "mode" approach, but it is the simplest way to keep the
PM/DM distinction correctly propagated thru all the compiler optimization
passes.

-- Al Lehotsky




At 12:23 AM +0000 7/1/98, Michael P. Hayes wrote:

* Joern Rennecke writes:
*  > > While on the alias code subject, EGCS could do with a mechanism so
*  > > that a programmer can hint to the compiler that a memory reference is
*  > > to a different address space, say an internal memory block.  The
*  > > backend could then do a better scheduling job by knowing that the
*  > > memory access is likely to be faster than normal and that it won't
*  > > conflict with an external memory access.  Any ideas?
*  >
*  > We'd need yet another field in the MEM to represent that.
*
* Yes, but how would we inform the front-end to set this flag?  Ideally,
* C needs another qualifer like fast or internal to say that a pointer
* is likely to be referring to something in internal memory.  It
* probably should be more general to deal with processors, in particular
* DSPs, that have multiple address spaces that the compiler needs to be
* aware of when generating fast code.  Does anyone know how the SHARC
* port deals with this?
*


------------------------------------------------------------------------

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

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation