Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utcsrgv.UUCP
Path: utzoo!utcsrgv!dave
From: dave@utcsrgv.UUCP (Dave Sherman)
Newsgroups: net.micro.68k
Subject: Re: again, nargs - (nf)
Message-ID: <3020@utcsrgv.UUCP>
Date: Mon, 2-Jan-84 08:36:15 EST
Article-I.D.: utcsrgv.3020
Posted: Mon Jan  2 08:36:15 1984
Date-Received: Mon, 2-Jan-84 08:44:51 EST
References: <3577@hp-pcd.UUCP>
Organization: The Law Society of Upper Canada, Toronto
Lines: 28

Nathan Myers asks why I don't fix the code instead of trying to use nargs.
Two reasons: (1) nargs is all over the place in the code, and I don't
really want to run about the whole thing looking for every reference to
every function called in this way; (2) in some places, the routine called
by nargs is an escape routine to handle interrupts, which will be called
with a single argument equal to the integer value of the signal which
triggered the call to the routine. Yes, I could get around it by having
SIGINT generate intr(), which calls escape(1, SIGINT), or by changing
all other invocations of escape() to use single arguments outside the
range 1-NUMSIG.... but if I can get a working nargs() it's MUCH simpler.
I have a complex CAI package which lets the students operate at any of
several levels, and there are multiple processes kicking around with pipes.
The things WORKS now, and I'd like to be able to port it without changing
things.

Nathan then asks whether "examining the stack frame" wouldn't be more
reliable than "looking at whatever butchery the optimizer produces".
That makes sense to me. Unfortunately, I know less than nothing about
the 68000 and its assembler or microcode. Anyway, I appreciate all the
contributions people have made, and I'll certainly try out the version
which was posted (I can live without the optimizer if that's all it takes.)
Thanks.

Dave Sherman
The Law Society of Upper Canada    (utcsrgv!lsuc!dave)
Toronto
-- 
 {allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!dave