Re: Register Allocation and Aliasing

torbenm@diku.dk (Torben [gidius Mogensen)
Sat, 14 Jul 90 22:45:33 GMT

          From comp.compilers

Related articles
Register Allocation and Aliasing aglew@oberon.crhc.uiuc.edu (1990-07-05)
Re: Register Allocation and Aliasing rfg@ncd.com (1990-07-06)
Re: Register Allocation and Aliasing preston@rice.edu (Preston Briggs) (1990-07-14)
Re: Register Allocation and Aliasing pur-ee!hankd@dynamo.ecn.purdue.edu (1990-07-14)
Re: Register Allocation and Aliasing torbenm@diku.dk (1990-07-14)
Re: Register Allocation and Aliasing mike@vlsivie.at (1990-07-15)
Re: Register Allocation and Aliasing aglew@dwarfs.crhc.uiuc.edu (1990-07-16)
Re: Register Allocation and Aliasing phorgan@cup.portal.com (Patrick Horgan) (1990-07-17)
Re: Register Allocation and Aliasing heggy@cs.pitt.edu (1990-07-17)
Re: Register Allocation and Aliasing aglew@oberon.crhc.uiuc.edu (1990-07-17)
Re: Register Allocation and Aliasing lupine!rfg@uunet.UU.NET (1990-07-19)
[2 later articles]
| List of all articles for this month |

Newsgroups: comp.arch,comp.compilers
From: torbenm@diku.dk (Torben [gidius Mogensen)
Keywords: optimize
Organization: Department Of Computer Science, University Of Copenhagen
References: <1990Jul06.194618.4957@esegue.segue.boston.ma.us>
Date: Sat, 14 Jul 90 22:45:33 GMT

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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.