Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!vsi1!wyse!mips!earl
From: earl@mips.COM (Earl Killian)
Newsgroups: comp.arch
Subject: Re: CISC instructions
Message-ID: <2914@wright.mips.COM>
Date: 29 Aug 88 00:49:58 GMT
References: <13254@mimsy.UUCP> <2912@wright.mips.COM> <13266@mimsy.UUCP>
Lines: 31

In article <13266@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> Well, actually, I was thinking in terms of what I could do with PCC
> and the current 4.3BSD-tahoe, without doing serious surgery.  I need
> ap to make sigtramp work as is (otherwise I could just use positive
> offsets from fp, a la the Tahoe); and I need fp to keep PCC happy,
> and to make alloca() work (you do not expect me to force everyone
> to give up GNU Emacs! :-) ).

Yeah, I understand, but do you realize how unfortunate this is?  Every
VAX Unix on the planet could be made an average of 25% faster if
someone would just use the Pastel compiler's procedure call protocol.
Perhaps this is hard with PCC, what about GCC?

As for alloca, you don't need to give it up.  Pastel generates a frame
pointer iff one is really needed.  For C, the equivalent would be for
your compiler to detect calls to alloca and use a frame pointer in
that one procedure.

> >No registers saved is actually quite realistic, when the call protocol
> >uses a mix of both callee and caller-saved registers.
> 
> Not possible `without doing serious surgery'.

Actually 4.3bsd VAX Unix has 8 callee-saved registers (r6-r11, fp, ap)
and 6 caller-saved registers (r0-r5), so it already works.  People
just don't think of the registers this way; they think of them as
variables and temps.  But a real register allocator (as in Pastel or
gcc) wouldn't need to think of them that way.
-- 
UUCP: {ames,decwrl,prls,pyramid}!mips!earl
USPS: MIPS Computer Systems, 930 Arques Ave, Sunnyvale CA, 94086