Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!pyramid!csg
From: csg@pyramid.pyramid.com (Carl S. Gutekunst)
Newsgroups: comp.sys.pyramid
Subject: Re: ftp notes
Message-ID: <57894@pyramid.pyramid.com>
Date: 5 Feb 89 03:26:12 GMT
References: <9924@tness7.UUCP>
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 30

In article <9924@tness7.UUCP> mechjgh@tness7.UUCP (Greg Hackney ) writes:
>> I have found what I think is the problem with the FTP user agent not
>> understanding the "binary" command.  It turns out that the code is
>> _heavily_ dependent on the stack for argument passing - it uses a
>> dummy first argument as a pointer to the rest of the arguments in
>> variable-argument functions.  This code breaks on the Pyramid.

Old bug. Talk to RTOC for a fix.

The actual "bug" here is amusing. You can do VAX-style argument-list traversal
on a Pyramid, if all the arguments are integral scalars or pointers, and you
have no more than 13 arguments. This is because the register stack is memory
addressable. 

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.

This was the fix I used for FTP. varargs was too much work. :-) (I *did* put
a warning in the sources and RCS comments about an "ugly non-portable hack.")

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....

<csg>