C vs. FORTRAN
Ken Raeburn
raeburn at athena.mit.edu
Fri Jul 8 19:49:38 AEST 1988
In article <553 at philmds.UUCP> leo at philmds.UUCP (Leo de Wit) writes:
>In article <872 at garth.UUCP> smryan at garth.UUCP (Steven Ryan) writes:
>>Actually, the real discussion is why does C have such a crippled argument
>>list? It is possible to pass a list of argument descriptors. The descriptor
>>list can be staticcally created and the overhead is just a register load
>>of a relocated address.
>
>What's the big deal? You can do that already in C. Just pass a list of
>pointers to structs, they are equivalent to your 'descriptors'. Both
Some differences here: If the compiler automatically does it, the
programmer doesn't have to do the work, the source code doesn't look
ugly, and the programmer isn't given the chance to screw up.
The Multics PL/I compiler (well, probably all of the Multics
compilers) did this sort of thing; there were calls available to get a
handle on the argument descriptor vector, and (I think) include files
around describing the structure and enumerating some of the possible
types. I've never had to use this feature (except maybe indirectly via
debuggers), but the "overhead" involved was nothing that ever
concerned me; some extra space in the text section, and an instruction
or two at runtime. (When a subroutine call is involved, the overhead
of a register-load is probably not significant, for large procedures.
If the procedure is small enough that you'd worry about it, you
probably want to inline your procedure anyways.)
There are times when I've wished for something like this to be
available under C; even if the language doesn't use it, you could
detect (probably in stack traces from core files) some cases when the
wrong arguments are being passed. (Yes, I know, prototypes should
help with that too. But BSD's pcc doesn't do prototypes. On the
other hand, I use GNU CC -- which has a reasonable approximation of
dpANS-C -- as my default compiler anyways, so I'm trying to get in the
habit.)
How about a family of *printf routines that can detect type
mismatches? The compiler would be hard-pressed to do this if you can
specify the format string at runtime.... Or, for your use in
debugging incredibly hairy code with monster data structures, a
pretty-printer routine which figures out what type the argument is and
displays it appropriately?
>About the overhead: you forgot to mention assignment to the data
>elements; for instance an actual parameter that is an expression -
What has this to do with the static argument descriptor list? The
types will be known at compile-time; they can be stored in a static
array (in the text section of the program, if feasible); only one
(constant) address needs to be loaded someplace special at runtime.
>C has such a crippled argument list? I find it perfectly ok if you
>don't like C - that's all on your account - but if you shout 'C has bad
>this - C has bad that' you should argue that; things you take for
>granted could well be less self-evident for C programmers.
Well, the uses I've mentioned above may or may not seem like useful
features. There are a couple of other Multicians out there who may be
able to describe some uses of which I may be unaware. (I would have
liked to have had a few more years with Multics before ours went away.
It was, from my understanding, sort of a predecessor to UNIX, or at
least in development when UNIX work started, and I find a lot of
things done right in Multics that some of the UNIX systems I've heard
of are just getting around to thinking about maybe sorta trying to do
someday soon.... Of course, it does go both ways.)
> Leo.
~~ Ken Raeburn / raeburn at athena.mit.edu
systems programmer
MIT Project Athena
More information about the Comp.lang.c
mailing list