Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!amiga!cbmvax!ditto From: ditto@cbmvax.UUCP (Michael "Ford" Ditto) Newsgroups: comp.sys.amiga.tech Subject: Re: Prototypes & the default promotions (was about the new RKM stuff.. Keywords: C calling conventions Message-ID: <6300@cbmvax.UUCP> Date: 16 Mar 89 04:25:14 GMT References: <8903111954.AA04828@jade.berkeley.edu> <15802@oberon.USC.EDU> <970@sas.UUCP> Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto) Organization: Commodore Technology, West Chester, PA Lines: 51 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