tll@nntp-server.caltech.edu (Tal Lewis Lancaster) (06/21/91)
cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) writes: >In article <1991Jun17.161534.323@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >>You will save yourselves a lot of time by going with gcc or Matt's DICE. >>Sadly IMOO Lattice/SAS C with human coders in mind and not as intermediate >>object coders. SAS and Aztec can not handle calls to other functions >>greater than 32K in the same object file! Also beware of the limitations >>on SAS's macros. Also watch out for SAS's scanf() most un-UNIX like. >You could save yourself a lot of time by reading the documentation. The >Lattice compiler will certainly call other functions more then 32K away, >you just have to tell it that you don't want the short addressing mode >enabled. (which it is by default because another set of programmers >kept bitching about how big the code generated by the Lattice compiler >was because they didn't know you could turn _on_ short addressing, either >way, people who read the documentation don't seem to run into this stuff) This is not true. Lattice/SAS and Manx compilers can not support function calls more than 32K away in the same object file!!! If you attempt it under SAS you will be visited by a CXERR: 29. I have confirmed these limitations with both companies! >Also you should read the section on large macros, which describes the >limits and why you might want to use lc1b rather than lc1 if you have >large macros, and last but not least, if you normally programmed on a >SystemV UNIX machine you would not have been suprised at all by the >behaviour of scanf in the Lattice library. It is more accurate to say >that the Lattice scanf is most un-BSD like. Admittedly, I'm heavly influenced from BSD. However, I thought that their scanfs() were similar. I have always treated them as if they were in my code and they work okay on both BSD and SystemV. >-- >--Chuck McManis Sun Microsystems >uucp: {anywhere}!sun!cmcmanis BIX: <none> Internet: cmcmanis@Eng.Sun.COM >These opinions are my own and no one elses, but you knew that didn't you. >"I tell you this parrot is bleeding deceased!" Tal Lancaster
ben@epmooch.UUCP (Rev. Ben A. Mesander) (06/23/91)
In article <1991Jun21.164424.3364@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) writes: [...] >>Also you should read the section on large macros, which describes the >>limits and why you might want to use lc1b rather than lc1 if you have >>large macros, and last but not least, if you normally programmed on a >>SystemV UNIX machine you would not have been suprised at all by the >>behaviour of scanf in the Lattice library. It is more accurate to say >>that the Lattice scanf is most un-BSD like. > >Admittedly, I'm heavly influenced from BSD. However, I thought that their >scanfs() were similar. I have always treated them as if they were in my code >and they work okay on both BSD and SystemV. I don't think it's BSD or USG behavior to dereference null pointers, but SAS's scanf does do this sometimes. It also writes to location zero. Use the source, Luke, and grab a different scanf from somewhere. SAS is a pretty darn good Amiga C compiler, an excellent debugger, but the library has some cruft in it. -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
Jay@deepthot.cary.nc.us (Jay Denebeim) (06/26/91)
In article <1991Jun21.164424.3364@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: > >This is not true. Lattice/SAS and Manx compilers can not support function >calls more than 32K away in the same object file!!! If you attempt it under >SAS you will be visited by a CXERR: 29. I have confirmed these limitations >with both companies! > RTFM! Don't use the small memory model if you need modules bigger than 32K. I won't mention that its silly to have modules that big, I assume you're just doing that as a test. Anyone working on serious code makes the modules small so that they're easy to work with. > >Tal Lancaster -- |_o_o|\\ |. o.| || The Jay Denebeim | . | || Software | o | || Distillery | |// Address: UUCP: mcnc.org!deepthot.uucp!jay ====== Internet: jay@deepthot.cary.nc.us BBS:(919)-460-7430 VOICE:(919)-460-6934
tll@nntp-server.caltech.edu (Tal Lewis Lancaster) (06/27/91)
Jay@deepthot.cary.nc.us (Jay Denebeim) writes: >In article <1991Jun21.164424.3364@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >> >>This is not true. Lattice/SAS and Manx compilers can not support function >>calls more than 32K away in the same object file!!! If you attempt it under >>SAS you will be visited by a CXERR: 29. I have confirmed these limitations >>with both companies! >> >RTFM! Don't use the small memory model if you need modules bigger than >32K. I won't mention that its silly to have modules that big, I assume >you're just doing that as a test. Anyone working on serious code >makes the modules small so that they're easy to work with. I am NOT using the small memory model, I am using the large memory model. If, I was generating the C code, then yes my modules would be smaller so they would be easier to maintain. But I am using C as an intermediate language and the code isn't meant for human consumption. And so I am needing to genterate object code on the order of 80K for each module. Now eventually, when I am ready to support the SAS compiler, I will have to do a major rewrite of my compiler to generate <32K modules. But, this will have to wait until I have the source for the compiler in its native language. So mean-while I have to use gcc (and pretty soon DICE) to compile my intermediate code because nothing else will. The down side is now I have a 1.2M executable that I am unable source level debug because neither gcc nor DICE have one. >> >>Tal Lancaster >-- > |_o_o|\\ > |. o.| || The Jay Denebeim > | . | || Software > | o | || Distillery > | |// Address: UUCP: mcnc.org!deepthot.uucp!jay > ====== Internet: jay@deepthot.cary.nc.us > BBS:(919)-460-7430 VOICE:(919)-460-6934 Tal Lancaster
lrg7030@uxa.cso.uiuc.edu (Loren J. Rittle) (06/28/91)
In article <1991Jun27.160657.3571@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >I am NOT using the small memory model, I am using the large memory model. If, >I was generating the C code, then yes my modules would be smaller so they >would be easier to maintain. But I am using C as an intermediate language and >the code isn't meant for human consumption. And so I am needing to genterate >object code on the order of 80K for each module. Now eventually, when I >am ready to support the SAS compiler, I will have to do a major rewrite of my >compiler to generate <32K modules. But, this will have to wait until I >have the source for the compiler in its native language. So mean-while >I have to use gcc (and pretty soon DICE) to compile my intermediate code >because nothing else will. The down side is now I have a 1.2M executable that >I am unable source level debug because neither gcc nor DICE have one. I believe SAS/C will handle C source files that generate more than 32K of object code. The problem is *functions* that generate more than 32K of object code! I have the same problem in Amiga f2c. I really hope this problem is fixed in the next rev. of the compiler. I have sent some mail to Jay re: this problem, hopefully he can report more information about the situation. >>>Tal Lancaster >> |. o.| || The Jay Denebeim >Tal Lancaster Loren J. Rittle -- ``NewTek stated that the Toaster *would* *not* be made to directly support the Mac, at this point Sculley stormed out of the booth...'' --- A scene at the recent MacExpo. Gee, you wouldn't think that an Apple Exec would be so worried about one little Amiga device... Loren J. Rittle l-rittle@uiuc.edu
ben@epmooch.UUCP (Rev. Ben A. Mesander) (06/28/91)
In article <Jay.7803@deepthot.cary.nc.us> Jay@deepthot.cary.nc.us (Jay Denebeim) writes: >In article <1991Jun21.164424.3364@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >> >>This is not true. Lattice/SAS and Manx compilers can not support function >>calls more than 32K away in the same object file!!! If you attempt it under >>SAS you will be visited by a CXERR: 29. I have confirmed these limitations >>with both companies! >> > >RTFM! Don't use the small memory model if you need modules bigger than >32K. I won't mention that its silly to have modules that big, I assume >you're just doing that as a test. Anyone working on serious code >makes the modules small so that they're easy to work with. Who pissed dioxin in your Post Toasties? RTFM indeed. With the large code model, SAS still sometimes has trouble with code more than 32K away in a single object file, especially if a single function is larger than 32K. I don't code this way, but the GNU people do in GNU chess, and it's pretty easy to generate such code with a tool like f2c given typical FORTRAN programming habits. -- | ben@epmooch.UUCP (Ben Mesander) |CNEWSMUSTDIECNEWSMUSTDIECNEWSM| | ben%servalan.UUCP@uokmax.ecn.uoknor.edu |USTDIECNEWSMUSTDIECNEWSMUSTDIE| | ...!chinet!servalan!epmooch!ben |CNEWSMUSTDIECNEWSMUSTDIECNEWSM|
tll@nntp-server.caltech.edu (Tal Lewis Lancaster) (06/29/91)
lrg7030@uxa.cso.uiuc.edu (Loren J. Rittle) writes: >I believe SAS/C will handle C source files that generate more than 32K of >object code. The problem is *functions* that generate more than 32K of >object code! I have the same problem in Amiga f2c. I really hope this >problem is fixed in the next rev. of the compiler. I have sent some >mail to Jay re: this problem, hopefully he can report more information >about the situation. I can't say about the 32K functions problem. But it is a fact that because of the way SAS/C does in-object file addressing the compiler can NOT handle a FUNCTION call to another FUNCTION in the SAME module if that call is >32K from said function. SAS has said it would take at least a year to them to make the changes to fix this. That was what they said 6 months ago and as far as I know there are no plans to do so. I believe it will ever be implemented, especially since there are no programmers specifically working on the future development of the SAS/C. >>Tal Lancaster >Loren J. Rittle >-- >``NewTek stated that the Toaster *would* *not* be made to directly support > the Mac, at this point Sculley stormed out of the booth...'' --- A scene at > the recent MacExpo. Gee, you wouldn't think that an Apple Exec would be so > worried about one little Amiga device... Loren J. Rittle l-rittle@uiuc.edu Tal Lancaster
riley@theory.TC.Cornell.EDU (Daniel S. Riley) (06/29/91)
In article <1991Jun28.175340.24275@nntp-server.caltech.edu>, tll@nntp-server.caltech.edu (Tal Lewis Lancaster) wrote: >That was what they said 6 months ago and as >far as I know there are no plans to do so. I believe it will ever be >implemented, especially since there are no programmers specifically working >on the future development of the SAS/C. There aren't? Where did you come by this startling bit of intelligence? Last I heard, they seemed quite active working on SAS/C version 6. Surely Doug Walker must be doing something to earn his keep... -- -Dan Riley (riley@theory.tc.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University