From: wilson@cs.utexas.edu (Paul Wilson)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 14 Apr 1992 13:52:08 -0500
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: estoril.cs.utexas.edu

In article <GUMBY.92Apr14021204@Cygnus.COM> gumby@Cygnus.COM (David V. Wallace) writes:
>   Date: 10 Apr 92 21:56:05 GMT
>   From: wilson@cs.utexas.edu (Paul Wilson)
>
>   In article <GUMBY.92Apr7160702@Cygnus.COM> gumby@Cygnus.COM (David V. Wallace) writes:
>   >
>   >   Date: 7 Apr 92 19:54:48 GMT
>   >   From: wilson@cs.utexas.edu (Paul Wilson)
>   >                                                     (I think most
>   >   of the costs of floats are the compiler's problem, not the hardware's;
>   >   with good inlining, dataflow analysis, etc., most floats can be raw
>   >   untagged values on the stack or in registers.
>   >
>   >This makes scavenging the stack painful if you're doing realtime gc in
>   >another execution thread.
>
>   The easy way to do this is to partition the register set into pointer
>   registers and nonpointer registers, as is done in Yale's T compiler.
>
>This doesn't work on current architectures (and I apologize that I had
>forgotten that this discussion is on _future_ architectures).  The two
>problems are:
> o - on a register-poor architecture (such as the sparc) the cost of
>     untagging may still be lower than the cost of all the reloads
>     you'll have to do because you don't have enough free registers of
>     the proper type.  Judicious tag choice and bibop-ing is needed to
>     make this true, of course.

Umm... I didn't say this was the ``right'' way to do it---just the
easy way.  (In fact, I said the opposite.)  I agree it's not as attractive
on a register-poor architecture.

I'm not sure if the SPARC qualifies as a register-poor architecture
in this respect.  It does in another respect, though.  It's got
tons o' registers, but very few GLOBAL registers you can play with
in an application-specific way.  In particular, I'd like special
global registers for values I need to reference often in my
system: a current-environment pointer, a base-pointer to my
card-marking bitmap (used for gc purposes, but used by any
code that stores potential pointers into the heap, not just
at gc time), and a coupla pervasive constants like false and null.
I'd rather have fewer registers in my windows and more in my
bank of globals.  (Registers, registers, everywhere, but...)

And if I recall correctly, the SPARC ABI has either zero or
close to zero registers you can use in this way---the global
registers are either reserved for particular uses or reserved
to the system for whatever it wants, so you can't absolutely
count on them not getting clobbered by system calls, etc.  Yuck.

(I think this may be one of the reasons that the GNU C compiler
still doesn't define a portable way to allocate a global register :-(.)

>   The ``right'' way to do it is to have the compiler record what's where,
>   and in what format, at what point in the code.  (For compactness, that
>   might involve defaults so that you only record the (relatively few)
>   exceptions explicitly.)
>
>Would you keep this info close to the function or in a seperate area?
>Which has better performance?

Good question.  I'd guess locality would enter into this in funny
ways. (On timescales smaller than the gc interval, you don't want
the info grouped with the function.  On timescales larger than
that, you may.)  On the other hand, I believe Moss et al.'s results
show that the space cost is less than 20%, so maybe it's no big deal
just to group it with the code. 

-- 
| Paul R. Wilson, runtime environmentalist          wilson@cs.utexas.edu      |
| U. of Texas Computer Sciences Dept.               voice: (512) 471-9555     |
| Taylor Hall 2.124, Austin, TX 78712-1188          fax:   (512) 471-8885     |
| "Inertia makes the world go 'round."              DoD M.C. # e  (Sz GS450T) |
From: linley@hpcuhe.cup.hp.com (Linley Gwennap)
Date: Fri, 10 Apr 1992 21:23:27 GMT
Subject: Re: Condition Codes and RISC arch.
Organization: Hewlett Packard, Cupertino