gay%CLSEPF51.BITNET@cunyvm.cuny.edu (David Gay) (05/23/88)
Let's try & clear this all up : 1) There are never any problems calling the shareable libraries (the interface is (& was recently) precisely described). They don't use any of the small, tiny, large ... you name it models. When you call them from C, you go through a stub (except if you use Lattice's pragmas) which transfers the arguments from the stack to the registers (*). In C: 2) The pointers are *always* 32 bits. 3) The differnt "models" are only used "internally" by the C compilers (that is, to refer to their own code & data). Thus the *C* libraries must come in several versions (in Lattice V4, you have short & long int's plus some rarely used ones which use "large" data internally). 4) The PC-relative/absolute code methods can be mixed freely. 5) absolute data modules can refer to all the data, "small" code only to that in the __MERGED hunk (in Lattice) 6) I repeat, all this only affects your C code, and in no way impedes access to the ROM. I hope this doesn't generate even more confusion :-) David Gay EPFL, Ecole Polytechnique Federale de Lausanne GAY@CLSEPF51.bitnet Switzerland Glorf ! Disclaimer: They don't even know I exist. I'm hiding away in the computer room. (*) I once followed a call to an intuition routine: this was what was happening: C calculates the parameters (in registers), stuffs them on the stack Calls the stub routine stub routine puts them in the registers, calls intuition In the rom, the parameters are put back on the stack (:-)) The actual routine is called ... and reads some of the stack into registers. Fun !
doug-merritt@cup.portal.com (05/25/88)
David Gay writes a nice clear summary of what's going on with small and large models, etc. He also says: > 6) I repeat, all this only affects your C code, and in no way impedes > access to the ROM. Possibly some of the confusion stems from the fact that you must pass long ints to Amiga library routines, whereas in small model, by default ints are short and so if you forget to cast them, you may well get gurus. For example: Print(s) char *s; { Write(output, s, (long) strlen(s)); } Without the 'long' cast, this would guru in small model, because the small model C library strlen() returns a short, not a long. Hence casting 'int' arguments to library functions to 'long' is a more portable style regardless of which compiler or model you yourself work in. Doug -- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug
toebes@sas.UUCP (John Toebes) (05/27/88)
In article <5880@cup.portal.com> doug-merritt@cup.portal.com writes: >David Gay writes a nice clear summary of what's going on with small >and large models, etc. >> 6) I repeat, all this only affects your C code, and in no way impedes >> access to the ROM. >Possibly some of the confusion stems from the fact that you must pass >long ints to Amiga library routines, whereas in small model, by default >ints are short and so if you forget to cast them, you may well get gurus. >For example: > Write(output, s, (long) strlen(s)); >Without the 'long' cast, this would guru in small model, because the small >model C library strlen() returns a short, not a long. >Hence casting 'int' arguments to library functions to 'long' is a more >portable style regardless of which compiler or model you yourself work in. > Doug The real answer is that the compiler should catch these errors through the use of prototypes. In this way, the code works REGARDLESS. All the extraneous casts make the code much more noisy and significantly less maintainable. Besides, there are a number of (non-Amiga ROM) functions that take INT instead of LONG. You then end up having to examine each function and figure out if it is really supposed to take an INT (not in ROM) or a LONG (in ROM). Plus this also prevents someone from writing a version of Write() to link in with a 16-bit int program which actually takes an INT for the mode argument. Of all the things that ANSI may have missed in producing a standard, prototypes are a certain win in the long run. I can say that without prototypes, BLINK would have taken SIGNIFICANTLY longer to develop. (Gee, maybe I am sounding like a broken record on the subject, but the amount of work to put prototypes into code is trivial and they gain so much). /*---------------------All standard Disclaimers apply---------------------*/ /*----Working for but not officially representing SAS or Lattice Inc.-----*/ /*----John A. Toebes, VIII usenet:...!mcnc!rti!sas!toebes-----*/ /*------------------------------------------------------------------------*/
doug-merritt@cup.portal.com (05/31/88)
John Toebes writes: > (Gee, maybe I am sounding like a broken record on the subject, but the > amount of work to put prototypes into code is trivial and they gain so > much). Yeah, function prototypes are wonderful; they catch lots of errors, and they fit perfectly into the spirit of the C language. Pity that they're not widely available enough yet to be able to consider them a truly portable construct. This will eventually change, but it'll take a while. Consider structure bit fields, structure assignment, and enums, all of which are still "new" in the sense that they're not 100% universally available, and are often buggy anyway, even though it's been quite some years now since they were added to the language. I avoid all three of these constructs when I write code intended to be as portable as possible. Therefore I would suggest not depending on function prototypes becoming universally available. Of course, simply having them supported by Manx as well as Lattice would be sufficient for 95% of the code written for Amiga's. Doug -- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug