Xref: utzoo comp.arch:17144 comp.compilers:1050
Path: utzoo!utgpu!watserv1!watmath!att!ima!esegue!compilers-sender
From: mike@vlsivie.at (Inst.f.Techn.Informatik)
Newsgroups: comp.arch,comp.compilers
Subject: Re: Register Allocation and Aliasing
Keywords: optimize,code
Message-ID: <1990Jul15.205606.19343@esegue.segue.boston.ma.us>
Date: 15 Jul 90 20:56:06 GMT
References: <1990Jul06.194618.4957@esegue.segue.boston.ma.us>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: mike@vlsivie.at (Inst.f.Techn.Informatik)
Followup-To: comp.arch,comp.compilers
Organization: Technical University of Vienna, AUSTRIA
Lines: 29
Approved: compilers@esegue.segue.boston.ma.us

In article <1990Jul06.194618.4957@esegue.segue.boston.ma.us>, rfg@ncd.com (Ron Guilmette) writes:
> In article <1990Jul05.155937.13214@esegue.segue.boston.ma.us> you write:
> >...
> >    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, ...
> 
> Actually, this sounds like a marvelous idea to me!

It most certainly is a marvelous idea! And it works! And it has been 
implemented. Here a short description:
As opposed to the suggestions made in these postings, there is no overhead 
vor loading the addresses associated with extra instructions into breakpoint 
registers. It is done automagically. It also uses a dynamic allocation 
scheme for the register values and can use *LOTS* of registers
(Anywhere from 8 KB to 64KB). 
IT EVEN HAS A NAME: it's called ``cache memory''. Access times are short 
and if integrated on the chip can be as fast as a register access.

				bye,
					mike :-)

Michael K. Gschwind             mike@vlsivie.at
Technical University, Vienna    mike@vlsivie.uucp
Voice: (++43).1.58801 8144      e182202@awituw01.bitnet
Fax:   (++43).1.569697
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue.  Meta-mail to compilers-request@esegue.