Path: utzoo!attcan!uunet!philmtl!philabs!briar!chc
From: chc@briar.Philips.Com (Chi-Hung Chi)
Newsgroups: comp.arch
Subject: Re: Register Allocation and Aliasing
Keywords: optimize, analysis
Message-ID: <103382@philabs.Philips.Com>
Date: 10 Jul 90 14:19:51 GMT
References: <1990Jul9.073203.3358@xavax.com> <9737@brazos.Rice.edu>
Sender: news@philabs.Philips.Com
Reply-To: chc@briar.philips.com.UUCP (Chi-Hung Chi)
Organization: Philips Laboratories, Briarcliff Manor, NY
Lines: 29

>Phil Harbison writes:
>>This sounds like an interesting idea.  What if we just added a tag
>>to each register in the CPU.  The tag would store the address which
>>the register represents.  A valid bit would be set if the tag was
>>in use, and cleared for empty or scratch registers.  A dirty bit
>>could be set when the register was not consistent with memory.  All
>>load/store instructions would have to check the tags, so the tags
>>would have to be fully associative.  Registers with the dirty bit
>>set could be automatically written back when they were reused.

This is what my thesis advisor (Hank Dietz) and I call "CReg" 
structure (Cache Register).  Two years ago, we had a preliminary 
paper about CReg which appeared in Supercomputing '88. Some updated
technical reports about the implementation and allocation of CRegs
and its extension to multiprocessors are under preparation and
should be ready very soon.

>>The whole scheme strikes me as "cache."  Hank Dietz has argued
>>(I believe) that the decision to keep a variable in cache or
>>register should be based on whether or not it is aliased.
>>
>>For data breakpoints, perhaps there's an easy modification
>>of cache hardware?

This is the primary functional difference between registers and cache
from a compiler's viewpoint. See my thesis for details.

- Chi-Hung Chi
  (chc@philabs.philips.com)