Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mhuxl!ihnp4!fortune!shah
From: shah@fortune.UUCP
Newsgroups: net.micro.68k
Subject: Re: Re: nargs - (nf)
Message-ID: <2149@fortune.UUCP>
Date: Sun, 1-Jan-84 23:03:11 EST
Article-I.D.: fortune.2149
Posted: Sun Jan  1 23:03:11 1984
Date-Received: Tue, 3-Jan-84 02:51:06 EST
Sender: notes@fortune.UUCP
Organization: Fortune Systems, Redwood City, CA
Lines: 52

#R:sii:-36300:fortune:6600009:000:2099
fortune!shah    Jan  1 18:50:00 1984

    `nargs' name is misleading as it really returns the size
of argument block (in units of sizeof (long)).  This is so
because you can have structs as arguments.  You can compute
the size of argument block without nargs but it is painful.
AND you, the user, has to know about how the compiler pushes
arguments on the stack.  A call to a version of createProc
that does not use nargs would look something like

    process = createProc(stackArea, stackSize, deathHandler,
			SIZE(arg1) + SIZE(arg2) + .. + SIZE(argn),
			foo, arg1, arg2, .. , argn);

	where SIZE(x) is
		(((sizeof(x)+LONGSIZE-1) / LONGSIZE)) * LONGSIZE)

	    where LONGSIZE is sizeof(long)

    Ughh!  OR you can restrict the argument types to be non-
structs!  OR you can always restrict total argument size to be
less than 2^N bytes -- wasteful and not easy to check.  OR you
can use a special value as the last argument to createProc and
restrict other arguments to not use this special value!  OR
you can use the printf idea of specifying argument type (and
hence size) in a string -- but how do you specify the size of
a structure?

    We did consider some of these ideas before choosing nargs
in favor of making the interface simpler and without any
restrictions on the number of arguments or their types.  It is
really unfortunate that nargs is not portable.

    I like nargs because it is an easy to use tool and with it
I can build easy to use tools.  On top of the co-routine
package we built a simulation kernel much like the one in
Concurrent Euclid.  Using this kernel we built a simple
simulator for the Fortune 32:16 bus to find out worst case DMA
latency etc.  Each level presented a simple interface to the
next one.  I think that was one of the major reasons for being
able to get our results in a short time.

    Ease of use is a very important attribute for software at
every level.  It does require you, the implementer, to look at
your program from its users' point of view.  By way of nargs
and the couple examples I wanted to draw your attention to this
belief.

					 -- Bakul Shah
					   fortune!shah