CompuServe Messages

Vic, Glad to see we have a disagreement on this, as I do want to hear the "other side" of things. My position is basically that if a machine is documented in assembler, that the compiler writers have to understand anyway, it will allow them to do their job. That job, as I see it, is to write and _document_ the compiler, said documentation being a description of how to program the machine in a language that the programmer will understand. The programmer understands the language he has chosen, or is at least in the process of learning to understand it, so everyone should be happy. In the final stages of debugging a sticky, obscure problem, don't you look at the code generated to see what is going wrong? As for the incessant pushing and popping of values to the stack, I have some definite ideas on that as well. I feel that there is indeed a mismatch of parameter passing methods, not to mention having two different "stack" oops… "stack directions", BCPL and 68000. However, I also feel that the present C compilers are not very smart in their handling of system calls. Since things need to be in registers anyway, why not put them there in the first place? I realize that writing a compiler to do this is nearly impossible, but I'm sure that there are many cuts that could be made in the code generated. On the other hand, if all calls to the system routines were required to have their arguments passed on the stack instead of in registers, then it would still be "right" to document _the machine and OS_ in assembler, and leave the docs for the compiler interface to the compiler writers. Lastlt, we come to the biggest insult of all, the translation of assembler includes to a C-like syntax. Great pains have been taken to render simple, easy to read assembler syntax into a mess that rrequires you to go looking in a C manual to write assembler code. In summation, I say leave the C docs to the C people, the M2 docs to the M2 people, and document the machine in terms of what it's really doing. Regards, Larry.