Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mitel!sce!cognos!geovision!gd
From: gd@geovision.uucp (Gord Deinstadt)
Newsgroups: comp.arch
Subject: Re: 80486 vs. 68040 code size [really: how many regs]
Message-ID: <643@geovision.UUCP>
Date: 19 May 89 22:27:54 GMT
References: <950@aber-cs.UUCP>
Reply-To: gd@geovision.UUCP (Gord Deinstadt)
Distribution: eunet,world
Organization: GeoVision Corp, Ottawa, Canada
Lines: 34

A few comments on / questions about super-global register allocation:

1.  How do you handle calls via a pointer?  Does your linker have to
be able to figure out all possible values of the function pointer?
Can this be done?  Or could you just tell the linker that these
functions are called somewhere and never mind where?  In this case it
would have to assume the worst, ie. that each was at the root of the tree.

2.  How do you handle signals?  I suppose the O/S could save all registers
before activating the signal handler, and restore them afterward.  No,
that doesn't work - restoring the registers resets some globals that you
WANTED to change.  (A solution for this would also solve 1.)

3.  All registers must be saved when calling a routine in a shared run-time
library.  Or, the linker could know which regs the library may use for each
entry point.  This gets more complicated if one library calls another, but
it seems manageable.

4.  The linker has to know if a variable is in shared memory.  Current 
optimizers are saved in situations such as this:

	for ( ; ; ) {
		wait_for_semaphore() ;
		switch (shmemp->thing) {

by the fact that shmemp->thing is in the heap, so they assume it might
have changed during the call to wait_for_semaphore().  However, a super-
global register allocator assumes it knows ALL about the program, and so
it is CERTAIN that the value can't have changed.  You have to tell it,
somehow.  A "shared" keyword in the storage declaration would suffice,
but that's a language change, and you know how those software types are!
:-) :-)

Gord Deinstadt		gdeinstadt@geovision