🚀 go-pugleaf

In article <970@sas.UUCP> toebes@sas.UUCP (John Toebes) writes:
>  Given that the actual
>system functtions being called aren't changing and that we already follow the
>ANSI conventions, there doesn't appear to be any need for us to change
>the compiler/glue routines.  Note also, that the Amiga.lib glue routines
>shipped with the compiler is the EXACT library supplied by Commodore.

Last time I looked, Commodore was only providing a 32-bit-int version of
Amiga.lib.  If you are compiling with 16-bit ints, and pass two shorts
to a function that is documented and prototyped as
	extern void Draw(struct RastPort *, SHORT, SHORT);
the Amiga.lib stub will expect to be passed two LONGs, but the compiler
will pass two SHORTs!  It won't work.  This is what the people meant who
said that the library stubs will have to change.

I haven't looked, but I'll bet that Lattice's headers prototype such
routines with LONG args, contrary to the new RKM description.  This
works, of course, but could be confusing, and doesn't take care of
cases where prototypes are not used.  The Right Thing would be to have
an Amiga.lib for each possible "model" (int size, etc.).  To take this
to the extreme, in a model where pointers are 16 bits, relative to a
base register (do any Amiga compilers have such a memory model?), the
"Draw" glue should pop the 16-bit pointer arg, add it to the base
register, and pass the absolute 32-bit pointer to the graphics.library.
Similar modifications would be made to other args (if there are still
any Rom function arguments that are declared as "int", a 16-bit int
should be popped, sign-extended to 32 bits, and passed).

Most of these sorts of problems are leftovers from the original RKM
which didn't specify the "C" language type for most arguments.  For
example, only bits 0-4 of the first argument to AddIntServer() are
relevant, but the "standard" Amiga.lib expects a 32-bit int to be
passed.  Then after the Manx people "invented" 16-bit ints, they
stupidly went through the header files putting capital L's everywhere,
including changing INTB_VERTB to (5L), and now people think that the
first arg to AddIntServer() is supposed to be a LONG.  This should
have been declared "short" or "int" to begin with, and a separate
version of Amiga.lib made for use with 16-bit ints.  Now, if this
function's documentation is "corrected" and intNum is a SHORT or BYTE,
some source code won't compile correctly if it explicitly passes a
"long" as is required now with Aztec C (lattice too?).

(So, I haven't seen the new RKM and now I'm curious:  Somebody tell
us how the new RKM declares the AddIntServer arguments, for example.)
-- 
					-=] Ford [=-

"The number of Unix installations	(In Real Life:  Mike Ditto)
has grown to 10, with more expected."	ford@kenobi.cts.com
- The Unix Programmer's Manual,		...!sdcsvax!crash!kenobi!ford
  2nd Edition, June, 1972.		ditto@cbmvax.commodore.com