Forum unknown
· Programming
AmigaDOS Philosopy
11 messages in this thread
OK, peeps, here is the new thread.
Larry, what the machine "really" does is interpret 1's and 0's; assembly is
just a convenient representation (with substantially more mnemonic value)
for humans. I know I'm being "picky", but pholosopy is that way. 'C' and
BCPL are other representations of "what is going on". And yes, I do look
at the generated code when the going gets sticky, even when it is MY
compiler that generated the code (perhaps I should say especially when).
I re-iterate, a BIG MISTAKE in AmigaDOS was the attempt to make the
Assembler interface easy at all. AmigaDOS' interface should have been
described only in some higher-level language (in this I agree with Peter).
I differ with Peter in that I don't need (or even want) the external
specification of the operating system to neccessarily written in whatever
language happens to be used to write the operating system.
Peter, Steve: …OS/9… "something slightly normal" "more acceptable"
judgment call gentlemen. To whom? I'm not an international expert, but I
assure you that they "do t'ings diff'rn't ov'r thar". Jeesh, they don't
even all speak English (well American, I don't speak English). Why Tripos,
'cuz they (MetaComCo) had it. why didn't whomever had OS/9 bid on the OS
project, or for that matter what is wrong with Hunter & Redy VRTX?
Peter "They don't give types of arguments and parameters", unfortunately
both BCPL and 'C' are typeless languages, now if they'd been really serious
they would have used Pascal, Modula, ADA. or something real like that, but
BCPL was invented a long, long, time ago…..in a galaxy far, far, away…
My personal preference, which all my "friends" are tired of hearing is
Pascal, it's not nearly so Wirthless as most people believe, but ISO
standard IS Wirthless for real-time (that's another thread).
Peter: array!index definitely takes getting used to, but it is also
structure!element -or- element!structure structurepointer!element -or- as
above it all depends on the declarations (before you complain LOUDLY there
are some interesting theoretical reasons making "structure.element,
structurepointer>element, and array[index] all appear the same….its
called the universal referent problem….lots of papers published on it).
Steve: "One language only"?? Yeah, I wish MetaComCo had released the BCPL
compiler for the Amiga (they DID for the ST). We (Metadigm) even offered
to finish the job, buy the compiler, something……but they wouldn't
twig. Anyway, we had ONE LANGUAGE once (Tower of Babel…or something) God
stepped in and look at the mess we've made of it. 'C' on the MAC doesn't
"fit" because of some badly mis-informed implementors of languages, and
then 'C' doesn't have a standard. I know….they're working on it (make it
look more like Pascal every day).
JUST FROM ME. I've watched a lot of machines come out (and the OS's with
them) over the years. I've never liked ANY OS when I first used it (except
for the one I was project manager on). We all react poorly when we have to
learn something new "The old way could do 'EVERTHING' God intended us to
do".
—–Horse Puckey—–
There are always different (and better….and worse) ways of doing anything
on a computer. Just 'cuz it ain't the way Mom made it doesn't mean it's
wrong. Would I have written the OS like AmigaDOS?? NO. Could I do a
better job?? I think so. Have I learned anything from the way AmigaDOS is
put together?? Absolutely. Was all of it bad?? NO. Could I HAVE written
an OS better than AmigaDOS?? At that time, probably not.
Vic,
Yes, interpreting 1s and 0s is exactly what it does, which is another way
of saying what I did, that the machine runs 68000 machine code. I maintain
though, that the closest human readable and interpretable representation of
that machine code is assembler. It tells you _exactly_ what is happening,
something that no higher level language can do. Lest you think that I am
denigrating higher level languages or in some way diminishing their value,
let me say that there is much validity in documenting in a higher level
language. I just don't think that it's valid to document the OS itself that
way, especially in light of the many and varied language preferences among
programmers.
You say that the biggest mistake was making it easy for assembly language
interface, yet it relly isn't any more difficukt to push values onto a
stack than it is to load them into registers when using assembly.
I would be more inclined to agree with you if you stated that there are too
many levels of overhead between the call itself and the actual routine, and
called that the biggest mistake. I would be perfectly happy to push my
values onto the stack, but would still wish to be spared the C syntax when
working with assembler. Tell me what to set up, where to JSR to, and what
to expect when control returns to my code. Let the C compiler people tell
you the name of the routine, what arguments to pass, and what order to do
it, likewise the Pascal/M2/LISP/FORTH/LOGO etc. compiler writers.
How did the C fans feel about the Mac being documented in Pascal-like
terms? How do the Modula-2 fans feel about the Amiga's C-like
documentation.
The bottom line is that the machine is documented the way it is due to an
arbitrary decision, and that decision has increased the difficulty for more
programmers than would have been the case if documented in "what is really
happening".
Regards, Larry.
Documenting in 'C' or Pascal is OK for assembly programming if the system
relies on stack based calls or traps. I don't think that having the docs
in Pascal is a bad idea … but if the assembly interface is different then
it can cause confusion.
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".
Larry, I understand your point of view, but VERY few assemblers have any
concept of TYPE. For that matter, neither does BCPL, and 'C' is only now
getting around to it. The AutoDocs (I think) presented the case rather
well. The function/procedure was written in 'C' with the register
designations put on the following line, directly under the arguments (and
under the return) example:
NAME
GetScreenData — Get copy of a screen data structure.
SYNOPSIS
Success = GetScreenData(Buffer, Size, Type, Screen )
D0 A0 D0 D1 A1
BOOL Success;
CPTR Buffer;
USHORT Size;
USHORT Type;
struct Screen *Screen;
FUNCTION
This function copies into the caller's buffer data from a Screen
structure Typically, this call will be used to find the size, title
bar height, and other values for a standard screen, such as the
Workbench screen.
To get the data for the Workbench screen, one would call:
GetScreenData(buff, sizeof(struct Screen), WBENCHSCREEN, NULL)
NOTE: if the requested standard screen is not open, this function
will have the effect of opening it.
INPUTS
Buffer = pointer to a buffer into which data can be copied
Size = the size of the buffer provided, in bytes
Type = the screen type, as specified in OpenWindow (WBENCHSCREEN,
CUSTOMSCREEN, …)
Screen = ignored, unless type is CUSTOMSCREEN, which results only in
copying 'size' bytes from 'screen' to 'buffer'
RESULT
TRUE if successful
FALSE if standard screen of Type 'type' could not be opened.
BUGS
SEE ALSO
OpenWindow()
The problem with a 'pure' assembler description is that we would know
that there were two address (A0 & A1) pointing to some kind of things, and
a couple of numbers (D0 & D1) which are size of thing A0 points to and type
of screen. This documentation says to get the address of the buffer into
A0, no preconceived notions as to how to do it: MOVEA.L BUFFER,A0 or
perhaps some complex expression (or array access)
On the other hand, I've seen 'programmers' who think that their variables
must be named the same as the examples. The problem I have with
documenting in assembler, is that it takes many many lines to show the call
whereas it generally only takes one line of HLL (H)igh (L)evel (L)anguage.
(Even though we both believe 'C' is a obfuscating LLL).
Larry, I understand your point of view, but VERY few assemblers have any
concept of TYPE. For that matter, neither does BCPL, and 'C' is only now
getting around to it. The AutoDocs (I think) presented the case rather
well. The function/procedure was written in 'C' with the register
designations put on the following line, directly under the arguments (and
under the return) example:
NAME
GetScreenData — Get copy of a screen data structure.
SYNOPSIS
Success = GetScreenData(Buffer, Size, Type, Screen )
D0 A0 D0 D1 A1
BOOL Success;
CPTR Buffer;
USHORT Size;
USHORT Type;
struct Screen *Screen;
FUNCTION
This function copies into the caller's buffer data from a Screen
structure Typically, this call will be used to find the size, title
bar height, and other values for a standard screen, such as the
Workbench screen.
To get the data for the Workbench screen, one would call:
GetScreenData(buff, sizeof(struct Screen), WBENCHSCREEN, NULL)
NOTE: if the requested standard screen is not open, this function
will have the effect of opening it.
INPUTS
Buffer = pointer to a buffer into which data can be copied
Size = the size of the buffer provided, in bytes
Type = the screen type, as specified in OpenWindow (WBENCHSCREEN,
CUSTOMSCREEN, …)
Screen = ignored, unless type is CUSTOMSCREEN, which results only in
copying 'size' bytes from 'screen' to 'buffer'
RESULT
TRUE if successful
FALSE if standard screen of Type 'type' could not be opened.
BUGS
SEE ALSO
OpenWindow()
The problem with a 'pure' assembler description is that we would know
that there were two address (A0 & A1) pointing to some kind of things, and
a couple of numbers (D0 & D1) which are size of thing A0 points to and type
of screen. This documentation says to get the address of the buffer into
A0, no preconceived notions as to how to do it: MOVEA.L BUFFER,A0 or
perhaps some complex expression (or array access)
On the other hand, I've seen 'programmers' who think that their variables
must be named the same as the examples. The problem I have with
documenting in assembler, is that it takes many many lines to show the call
whereas it generally only takes one line of HLL (H)igh (L)evel (L)anguage.
(Even though we both believe 'C' is a obfuscating LLL).
My point was that describing in Pascal (or even C) isn't too much of a pain
for assembly language programming IF everything is passed on the stack in
the order of the function arguments. If the passing is by registers ….
than it should be seperatly documented. Bill
My point was that describing in Pascal (or even C) isn't too much of a pain
for assembly language programming IF everything is passed on the stack in
the order of the function arguments. If the passing is by registers ….
than it should be seperatly documented. Bill
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".
Documenting in 'C' or Pascal is OK for assembly programming if the system
relies on stack based calls or traps. I don't think that having the docs
in Pascal is a bad idea … but if the assembly interface is different then
it can cause confusion.
Vic,
Yes, interpreting 1s and 0s is exactly what it does, which is another way
of saying what I did, that the machine runs 68000 machine code. I maintain
though, that the closest human readable and interpretable representation of
that machine code is assembler. It tells you _exactly_ what is happening,
something that no higher level language can do. Lest you think that I am
denigrating higher level languages or in some way diminishing their value,
let me say that there is much validity in documenting in a higher level
language. I just don't think that it's valid to document the OS itself that
way, especially in light of the many and varied language preferences among
programmers.
You say that the biggest mistake was making it easy for assembly language
interface, yet it relly isn't any more difficukt to push values onto a
stack than it is to load them into registers when using assembly.
I would be more inclined to agree with you if you stated that there are too
many levels of overhead between the call itself and the actual routine, and
called that the biggest mistake. I would be perfectly happy to push my
values onto the stack, but would still wish to be spared the C syntax when
working with assembler. Tell me what to set up, where to JSR to, and what
to expect when control returns to my code. Let the C compiler people tell
you the name of the routine, what arguments to pass, and what order to do
it, likewise the Pascal/M2/LISP/FORTH/LOGO etc. compiler writers.
How did the C fans feel about the Mac being documented in Pascal-like
terms? How do the Modula-2 fans feel about the Amiga's C-like
documentation.
The bottom line is that the machine is documented the way it is due to an
arbitrary decision, and that decision has increased the difficulty for more
programmers than would have been the case if documented in "what is really
happening".
Regards, Larry.