Xref: utzoo comp.arch:17124 comp.compilers:1041
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!yale!mintaka!snorkelwacker!spdcc!esegue!compilers-sender
From: torbenm@diku.dk (Torben [gidius Mogensen)
Newsgroups: comp.arch,comp.compilers
Subject: Re: Register Allocation and Aliasing
Keywords: optimize
Message-ID: <1990Jul14.224533.14161@esegue.segue.boston.ma.us>
Date: 14 Jul 90 22:45:33 GMT
References: <1990Jul06.194618.4957@esegue.segue.boston.ma.us>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: torbenm@diku.dk (Torben [gidius Mogensen)
Organization: Department Of Computer Science, University Of Copenhagen
Lines: 50
Approved: compilers@esegue.segue.boston.ma.us

rfg@ncd.com (Ron Guilmette) writes:

>In article <1990Jul05.155937.13214@esegue.segue.boston.ma.us> you write:
>>How often are quantities that *might* be allocated to registers *not*
>>allocated to registers, because of the remote *possibility* of
>>aliasing via some circuitous pointers?
>>
>>    Hare brained idea: allocate quantities that *might* be aliased to
>>registers anyway.  Provide a register to contain the true memory
>>address of the aliased quantity, which causes a trap when the address
>>is accessed (or automagically forwards to/from the register).  Not
>>only are aliasing problems avoided, but you've got a set of data
>>address breakpoint registers as well! (ie. this technique could be
>>experimentally evaluated on machines that have data address
>>breakpoints).

>Actually, this sounds like a marvelous idea to me!

>I guess that the only drawback would be the cost of the additional hardware
>to support the data breakpoints, but (as you noted) some machines already
>have such facilities, so it can't be THAT expensive.

There are two other (simpler) ways to circumvent the aliasing problem
in a processor architecture.

One is to assign fixed addresses to registers, e.g.  let the first N
addresses refer to the N registers.  The processor would recognize
that all the top bits in the address are 0, and use registers instead.
I believe this was done in some PDP 11s.  [actually, the PDP-6/10/20 -John]

One is have no data registers at all, but keep everything in memory.
This is not as costly as it may sound, as cache memory can be accessed
(almost) as fast as register memory. An added benefit is fast process
switch. Register allocation becomes a non-issue and register
saving/loading in process calls is done invisibly on a "call-by-need"
basis, as cache cells are overwritten. The only problem is address
size in instructions, but this can be solved in several ways. One is
to use a stacktop relative addressing similar to what Simon Peyton
Jones suggested recently.

Another way is the method used in the TI 99000 series: use a pointer
to a block of memory that can be addressed using short addresses. This
block was actually called the "register block". This series of
processors was actually quite interesting, and it is a shame that TI
dropped it in favor of the 8086. (Some people may remember the TI 99/4
home computer, which used a 99000 processor. It was notoriously slow,
but this was (I have heard) mainly due to bad programming and system
design).

	Torben Mogensen (torbenm@diku.dk)
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue.  Meta-mail to compilers-request@esegue.