Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!hplabs!pyramid!wendyt
From: wendyt@pyrps5 (Wendy Thrash)
Newsgroups: comp.sys.pyramid
Subject: Re: ftp notes
Message-ID: <58126@pyramid.pyramid.com>
Date: 7 Feb 89 00:21:00 GMT
Sender: daemon@pyramid.pyramid.com
Reply-To: wendyt@pyrps5.UUCP (Wendy Thrash)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 35

In article <57894@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
>The problem is that the compiler grabs "unused" registers in the call-from
>window (the 'P' registers) for scratch space. So, if the function in question
>only declares one argument and tries to get the rest by traversal, you end up
>getting compiler scratch values overwriting your argument list. If you simply
>declare the function to have 13 arguments, then the compiler puts its scratch
>variables in local 'L' registers, and the parameter list traversal works.
>
>I noticed in OSx 5.0 that the compiler now puts scratch variables in the call-
>to register window (the 'T' registers), which neatly avoids the problem. Some-
>how, though, I don't think the compiler group quite had my kind of hacking in
>mind when they made that change....

I suspect it's a bit early to be talking about what the OSx 5.0 compiler does,
so you should probably ignore anything you hear about it.  You should
particularly take what Carl tells you about it with a grain of salt, though
everything else he's ever written is absolutely true. :-)

As the alleged perpetrator of the hypothetical register allocator that may
someday appear in a Pyramid compiler, perhaps even in OSx 5.0 if there should
ever be such a release of OSx, I assure you that you can't count on this
hypothetical allocator to spare the PRs.  If such a piece of software did
exist, I'm quite sure it would cram as much as it could into TRs and LRs, but
would happily use PRs if it deemed that to be necessary.  Moreover, if one
attempted to fool this (hypothetical) allocator by declaring dummy arguments
that were never used, I'm sure the allocator would notice that they were never
used and would blithely overwrite those PRs if it felt like it.  I'm sure,
though, that kindly compiler writers would provide some sort of mechanism,
perhaps in the form of a #pragma, to prevent those registers from being used.
I suspect they would even document the behavior of the allocator in the release
notes.

So, if Pyramid should ever release OSx m.n with m > 4 or m == 4 and n > 4,
then clever programmers might want to read the release notes to see what
(ahem) advances in compiler technology might do to their clever code.