Forum unknown
· Amiga at Work
#Modula Keyb.
9 messages in this thread
Larry, gonna disagre with you on this one. Assembler is "right" only for
documenting what a machine IS doing, not -repeat- NOT for documenting what
an operating system is going to do. As anyone who knows me will *gladly*
tell you I am NOT a UNIX ™ fan, but one thing they DID do right was to
document all of the calls in a language which a relative novice could read.
When I am reading a manual for the first I don't give a darn about all the
nitty-gritty details of how to call each and every system function (I sure
as heck don't care which registers have which arguments).
One of the VERY LARGE MISTAKES made with AmigaDOS, was the catering to the
Assembler writers who "need" to pass arguments in registers. Take a look
at what happens when a DOS call is made from 'C'. Push the arguments (in
reverse order) onto the stack, call the 'C' runtime library which loads up
the arguments from the stack into the "right" registers, gets the library
base into A6, then calls the jump vector; which pushes the "right"
registers back onto the stack to be processed by the BCPL code. What a
WASTE of time and space.
As for the pointers in BCPL, memory is viewed as overlapping arrays of
bytes, words, and longs. And memory_long[0] is followed by memory_long[1]
etc. Same for words and bytes (memory_byte[0] through memory_byte[3] are
in the same space as memory_long[0]). Now for the tricky part, a pointer
is the subscript for the item (byte, word, or long). That is, a pointer to
a byte is what you expect (and indeed need) on a 68000, but a pointer to a
word (16 bit thingie) would need to be shifted left once to be used on a
68000, but is indeed the "word number" of the word pointed to. Things are
similar on longs. Hope this clears things up, any questions and I'd be
happy to answer (my M-F 8-5 job has me maintaing .5 mega-lines of BCPL
multi-user, real-time operating system for a mini).
Incidently, BCPL was invented substantially before 'C' which was derived
from it. And Tripos pre-dates (I believe) UNIX (at least they are of the
same period (a`la 1976). UNIX is the registered trademark of Bell
Laboratories.
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.
But what it's really doing is running BCPL. I'll go along with Vic on this
one… if you're making calls in BCPL describe them as BCPL calls, then
document the BCPL calling sequence. If you're making everything look like
it's in 'C', then document them (completely) as 'C' calls and describe the
calling sequence in an aside. Write the manuals for the majority of the
users who are not assembly hacks or compiler writers.
In summation, I say document the *operating system* in terms of what it's
really doing, and leave the assembly for the hardware manual.
Peter,
I take it then that you think that Modula, Pascal, LISP, FORTH and Fortran
people should be happy that the OS is documented in C? I sure don't.
I disagree that the OS is _running_ BCPL. It is running 68000 machine code,
whose closest human readable analog is assembler. The fact that _some_ of
the system routines were written in BCPL only 'colours' the code in that
certain things tend to be done in particular ways, and the portions that
were written in C are likewise 'coloured' in the manner that C compilers
tend to colour code.
The OS is not "made to look like" anything except by those that wrote the
documentation. If a particular routine looks on the stack for its
arguments, then that's where they should be when you call it. I feel that
it really is up to the compiler writers to document the user interface for
their own language, in a manner that fits the language, and that their
actual interface code should not mess about pushing and popping, but go as
directly as possible to the state at which everything is set up for the
actual (machine code) call.
Peter,
I take it then that you think that Modula, Pascal, LISP, FORTH and Fortran
people should be happy that the OS is documented in C? I sure don't.
I disagree that the OS is _running_ BCPL. It is running 68000 machine code,
whose closest human readable analog is assembler. The fact that _some_ of
the system routines were written in BCPL only 'colours' the code in that
certain things tend to be done in particular ways, and the portions that
were written in C are likewise 'coloured' in the manner that C compilers
tend to colour code.
The OS is not "made to look like" anything except by those that wrote the
documentation. If a particular routine looks on the stack for its
arguments, then that's where they should be when you call it. I feel that
it really is up to the compiler writers to document the user interface for
their own language, in a manner that fits the language, and that their
actual interface code should not mess about pushing and popping, but go as
directly as possible to the state at which everything is set up for the
actual (machine code) call.
But what it's really doing is running BCPL. I'll go along with Vic on this
one… if you're making calls in BCPL describe them as BCPL calls, then
document the BCPL calling sequence. If you're making everything look like
it's in 'C', then document them (completely) as 'C' calls and describe the
calling sequence in an aside. Write the manuals for the majority of the
users who are not assembly hacks or compiler writers.
In summation, I say document the *operating system* in terms of what it's
really doing, and leave the assembly for the hardware manual.
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.
UNIX dates back to 1972. My own gripe with the Amiga manuals in general is
that they don't give you the types of arguments and parameters, beyond
"pointer". For example it's not immediately obvious that CreatProcess
returns a message port. C is based on B, which is basically BCPL with some
cosmetic fixes to the syntax: array[index] instead of array!index, for
example. Every time I browse through the BCPL book I'm sooooo thankful for
that.
UNIX dates back to 1972. My own gripe with the Amiga manuals in general is
that they don't give you the types of arguments and parameters, beyond
"pointer". For example it's not immediately obvious that CreatProcess
returns a message port. C is based on B, which is basically BCPL with some
cosmetic fixes to the syntax: array[index] instead of array!index, for
example. Every time I browse through the BCPL book I'm sooooo thankful for
that.