#AmigaDOS Philosopy
14-May-87 13:09:15
Sb: #67656-#AmigaDOS Philosopy
Fm: John Draper 76703,4322
To: Aegis Development 76067,2500
This message turned up in search, but its forum couldn’t be identified from the original transcript, so it may not be linked into its thread.
Assembly and Pascal interfaces are always "different" as are assembly and C
interfaces.
I suddenly get the feeling that we may be discussing entirely different
things here, and that it might be wise to clear up a few meanings. When I
speak of an interface, and the documentation of it, I mean the way you are
required to do things, and how it is presented to the programmer.
As an example, let's look at the difference between the descriptions of a
simple call requiring two arguments. The C function will be documented as
to the name of the function, the number, type, and order of the arguments,
and the returned value. This is fine for C programmers, as all they need do
is code the function in the standard way according to the syntax and
conventions of the language. Since the C compiler itself uses code to set
things up prior to the call, the C programmer need never know what is
happening on that level.
In an assembly program, however, one needs to know not only the number and
type of the arguments and the return value, but also where these things
need to be, no matter whether they are required to be in registers or on
the stack, in a fixed address area, a structure, or wherever. The function
in question, if documented in C terms, tells the assembler programmer
nothing about the additional things she needs to know.
Since the C compiler writer defines the C interface by virtue of the code
in the scanned library, and since these definitions are completely
arbitrary, (there is nothing to stop the compiler writer from changing the
order of the parameters, and in some cases even their type), then it should
be up to the compiler writer to document the syatem as seen from the C
programmer's point of view. Same goes for M2, LISP, whatever.
The documentation for the OS itself, however, is another matter altogether.
The interface, on the lowest (leagl, approved, sanctioned) level, requires
values to be set up prior to the actual call, in very6 specific places, and
to leave this undocumented, or documented on a higher level, is, to my way
of thinking, unforgivable. Documentation of the type I propose is good
Anyway, documentation in assembler terms is good for a wider range of
programmers than is documentation in higher level languages. The various
compilers were obviously written by people who know assembler, as someone
had to write the interface routines. Thos using the compilers have the
option of looking at the interface code to determine if things are set up
correctly for the call, or can use a debugger to check the actual values
passed, a task made far more roundabout and difficult when one has to take
extra steps to find out just where and what the arguments should be.
It is interesting to note that the Inmos computers are documented solely in
OCCAM, a high level language. Assembler programming on those machines is
being actively discouraged. I can see the point of this, but no such
statements have been made by CBM, and in fact they themselves provided an
assembler, so I think it only fitting that the machine be documented in
terms of the lowest sanctioned level "allowed".