CompuServe Messages

#AmigaDOS Philosopy

#: 67662 S10/ProgrammingForum unknown
    14-May-87 13:09:15
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".