GIGUERE@WATCSG.BITNET (Eric Giguere) (03/12/89)
In article <15751@oberon.USC.EDU>Marco Papa writes: >Actually things are not as bad as they look, simply because every >implementation of the 'C' langage has to respect the following rule, >excerpted from page 186 of K&R: > >"Any actual argument of type float are converted to double before the call; >any of type char or short are converted to int;" > ^^^^^ ^^^ This is one reason why you shouldn't be using the 1st edition of K&R anymore as the "final" reference document. With Lattice 5.0 out now and Manx 5.0 out in a few months, the ANSI standard will be de rigueur. Let me quote Section 3.3.2.2 of the draft Standard (Dec 7, 1988): "If ... the called function ... does not include a prototype, the integral promotions are performed on each argument and arguments that have type float are promoted to double." but then: "If ... the called function ... includes a prototype, the arguments are implicitly converted, as if by assignment, to the types of the corresponding parameters." So if a prototype is in scope, the default argument promotions are NOT performed. In the following example the first call passes an int and the second a short: extern void f(); /* no parameter information */ short s = 0; f( s ); /* short gets promoted to int */ extern void f( short ); short s = 0; f( s ); /* short stays as short */ One of the major changes the Committee made was to make the Standard Library "invariant" to the default promotions -- i.e., any functions that previously expected a char or short were redefined to expect an int so that the presence or absence of a prototype would make no difference. Prototypes can be nasty at times. However, when Manx 5.0 comes out, proper use of prototypes will solve the 16- vs. 32-bit int problem quite nicely. Eric Giguere Computer Systems Group, University of Waterloo BITNET: GIGUERE@WATCSG Other: giguere@watcsg.UWaterloo.CA UUNET : watcsg!giguere@uunet.UU.NET
papa@pollux.usc.edu (Marco Papa) (03/13/89)
In article <8903111954.AA04828@jade.berkeley.edu> GIGUERE@WATCSG.BITNET (Eric Giguere) writes: |In article <15751@oberon.USC.EDU|Marco Papa writes: ||Actually things are not as bad as they look, simply because every ||implementation of the 'C' langage has to respect the following rule, ||excerpted from page 186 of K&R: || ||"Any actual argument of type float are converted to double before the call; ||any of type char or short are converted to int;" || ^^^^^ ^^^ | |This is one reason why you shouldn't be using the 1st edition of K&R |anymore as the "final" reference document. With Lattice 5.0 out now |and Manx 5.0 out in a few months, the ANSI standard will be de rigueur. |Let me quote Section 3.3.2.2 of the draft Standard (Dec 7, 1988): | | "If ... the called function ... does not include a prototype, | the integral promotions are performed on each argument and | arguments that have type float are promoted to double." | |but then: | | "If ... the called function ... includes a prototype, the | arguments are implicitly converted, as if by assignment, | to the types of the corresponding parameters." | |So if a prototype is in scope, the default argument promotions are NOT |performed. You're quite right, BUT MANX 5.0 is way way down the line, AND a lot of "current" programs do assume that the argument promotion is performed (which has a lot of implications like sign extension, etc...). As you mention, the ANSI standard ensured that 'old' programs that assumed the "argument promotion" be performed will still behave like K&R, UNLESS function prototypes have been added. MANX 5.0 (as well as Lattice 5.0) library stubs will clearly be different from the current release. The reason I am saying that MANX 5.0 is way down the line is that they are still asking on BIX what "features" programmers would like to see in MANX 5.0 (as you probably know MANX 4.x will not be released). So you should assume that you'll have to work with MANX 3.6 for quite some time. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
toebes@sas.UUCP (John Toebes) (03/16/89)
In article <15802@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >You're quite right, BUT MANX 5.0 is way way down the line, AND a lot of >"current" programs do assume that the argument promotion is performed >(which has a lot of implications like sign extension, etc...). As you >mention, the ANSI standard ensured that 'old' programs that assumed the >"argument promotion" be performed will still behave like K&R, UNLESS >function prototypes have been added. MANX 5.0 (as well as Lattice 5.0) ???????????????????????? >library stubs will clearly be different from the current release. Perhaps I am missing something here, but since Lattice C V4.0, we have been supplying prototypes and #pragma statements for calling all the system functions. These work with both short integers and long integers as well as conforms to the current ANSI proposed standard. 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. > >The reason I am saying that MANX 5.0 is way down the line is that they are >still asking on BIX what "features" programmers would like to see in MANX >5.0 (as you probably know MANX 4.x will not be released). So you should >assume that you'll have to work with MANX 3.6 for quite some time. >-- Marco Papa 'Doc' /*---------------------All standard Disclaimers apply---------------------*/ /*----Working for but not officially representing SAS or Lattice Inc.-----*/ /*----John A. Toebes, VIII usenet:...!mcnc!rti!sas!toebes-----*/ /*------------------------------------------------------------------------*/
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (03/16/89)
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
papa@pollux.usc.edu (Marco Papa) (03/16/89)
In article <970@sas.UUCP| toebes@sas.UUCP (John Toebes) writes: |In article <15802@oberon.USC.EDU| papa@pollux.usc.edu I write: ||[ stuff deleted] ||"argument promotion" be performed will still behave like K&R, UNLESS ||function prototypes have been added. MANX 5.0 (as well as Lattice 5.0) | ???????????????????????? ||library stubs will clearly be different from the current release. ^^^^^^^^^^^^^^^ |Perhaps I am missing something here, but since Lattice C V4.0, we have |been supplying prototypes and #pragma statements for calling all the system |functions. These work with both short integers and long integers as well |as conforms to the current ANSI proposed standard. Sorry, John. The "current release" referred ONLY to MANX, not to Lattice. I am fully aware that right now Lattice is fully ANSI compliant and therefore can avoid all the problems of argiument promotion. The phrase should have been something like this: " MANX 5.0 library stubs will clearly be different from the current MANX 3.6 release. Lattice C already supports function prototypes in their current 5.0 release". I apologize for the confusion. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
chas@gtss.gatech.edu (Charles Cleveland) (03/16/89)
In article <6300@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes:
)
)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.
If you include the proto header files for system functions in Lattice, then
you automatically include the #pragmas that make the stubs in Amiga.lib
irrelevant. Since the stubs are irrelevant, they don't have to change.
Of course you can, with a suitable #define, cause the compiler to ignore
the pragmas and use the Amiga.lib stubs instead while still retaining the
prototypes, but if you've got a reason for doing this you better understand
the stub routines (as you point out).
)
)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
I haven't looked either, but I'll bet they say SHORT.
--
"Our vision is to speed up time, eventually eliminating it." -- Alex Schure
Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332-0430
UUCP: ...!gatech!gtss!chas INTERNET: chas@gtss.gatech.edudsking@pyr.gatech.EDU ( David King) (03/17/89)
In article <393@gtss.gatech.edu> chas@gtss.UUCP (Charles Cleveland) writes: >In article <6300@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: ... >)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 > >I haven't looked either, but I'll bet they say SHORT. Well, guys, a quick look through the Includes and the Lattice manual shows that the winner is... Michael. Charles had the right idea, which in fact was what I thought the answer was....When I saw the answer at first I thought that it was because the #pragma libcall only specifies the register to move the value to. Now I think it was done for compatability the code you compile using Amiga.lib will behaive exactly the same as the #pragma libcall'ed code. However, that doesn't seem quite right, so my final guess is that the pragmas were created using fd2pragma, and fd files have no concept of parts of a register. John? -David >-- >"Our vision is to speed up time, eventually eliminating it." -- Alex Schure > >Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332-0430 >UUCP: ...!gatech!gtss!chas INTERNET: chas@gtss.gatech.edu -- David King - a "Real Role-Player" (tm) Georgia Insitute of Technology, Atlanta Georgia, 30332 uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!dsking ARPA: dsking@pyr.gatech.edu
paolucci@snll-arpagw.UUCP (Sam Paolucci) (03/17/89)
In article <15884@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes:
->Sorry, John. The "current release" referred ONLY to MANX, not to Lattice.
->I am fully aware that right now Lattice is fully ANSI compliant and
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
->therefore can avoid all the problems of argiument promotion. The phrase
->should have been something like this:
I would just like to clarify that currently there are NO FULLY ANSI
COMPLIANT compilers on the Amiga! Lattice currently is substantially
closer to it than Manx, but there are still many places where Lattice
is still not compliant. To emphasize this fact even the Lattice compiler
defines __STDC__ to be 0. I have already notified Lattice of some
places where the compiler is not compliant. Others I have not reported
to them yet.
->-- Marco Papa 'Doc'
--
-+= SAM =+-
"the best things in life are free"
ARPA: paolucci@snll-arpagw.llnl.govtoebes@sas.UUCP (John Toebes) (03/23/89)
In article <7621@pyr.gatech.EDU> dsking@pyr.UUCP ( David King) writes: > Charles had the right idea, which in fact was what I thought >the answer was....When I saw the answer at first I thought that it was >because the #pragma libcall only specifies the register to move the value to. >Now I think it was done for compatability the code you compile using >Amiga.lib will behaive exactly the same as the #pragma libcall'ed code. >However, that doesn't seem quite right, so my final guess is that the pragmas >were created using fd2pragma, and fd files have no concept of parts of a >register. > > John? > David King - a "Real Role-Player" (tm) Well, a little history of it all is in order. All of the files in the proto subdirectory shipped with the Lattice compiler were done by first using an AWK script on the .fd files and then editing the results by hand. At the time I did them, many of the routines were not documented at all as far as parameters go and I resorted to a combination of reading RKM, Autodocs, Mortimer's book, and one other that I can't remember. In a surprisingly large number of cases all the sources did NOT agree and I had to rely upon intuition (and my relentless beta testers) to get them correct. The prototypes were designed to work with Amiga.lib stubs regardless of the option you used for compiling the code so there aren't any SHORTS in the prototypes. fd2pragma was written after the prototype files were prepared so it didn't play in the picture. Does this clear up the situation? /*---------------------All standard Disclaimers apply---------------------*/ /*----Working for but not officially representing SAS or Lattice Inc.-----*/ /*----John A. Toebes, VIII usenet:...!mcnc!rti!sas!toebes-----*/ /*------------------------------------------------------------------------*/