mcdonald@aries.scs.uiuc.edu (Doug McDonald) (09/25/90)
We have a problem: we have a CD ROM disk that has a lot of data on it that we need. Far too much to copy to a hard disk (well over a gigabyte). The only CD ROM reader we have is for a Mac. We therefore would like to run the programs that use this data on the Mac. (This is a Mac IIci with 4 megabytes.) We already have the source code for the programs. It compiles and runs fine on PCs and Unix boxes (using a tiny subset of the data copied to a hard disk.) I tried compiling this on the Mac with a borrowed copy of Lightspeed C and it failed. These are large programs - a couple of megabytes of global data and several very large subroutines (that compile to somewhere between 50 and 125 kbytes of code on varying computers). Lightspeed C apparently thinks it is too big. One program has about 85K of compiled-in static data. Are there other C compilers for the Mac that will do this? We would like near-total ANSI C compatibility (you can forget trigraphs and locale support :-) ), but it must support full stdio stuff including console IO, and a command line would be nice. Basically, we just want the Mac to look like a normal computer. We don't have any use for or desire to worry about any Mac specific things. (Price is important - we can buy a CD ROM reader for our 386 PC for $700, and then it would be trivial.) Doug McDonald
francis@arthur.uchicago.edu (Francis Stracke) (09/27/90)
In article <1990Sep24.184845.12502@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > [...] >I tried compiling this on the Mac with a borrowed copy of Lightspeed C >and it failed. These are large programs - a couple of megabytes >of global data and several very large subroutines (that compile to >somewhere between 50 and 125 kbytes of code on varying computers). >Lightspeed C apparently thinks it is too big. Damn straight, it's too big! Macs use a variety of segmenting that puts each segment of your program into its own code resource (if you don't know, don't worry). No resource can be bigger than 32K (theoretically--I've seen some sound resources get around it somehow--but it's probably tricky and risky enough that no compiler would do it, especially with work-arounds available-- see below). No subroutine can be spread across more than one segment (reasonable, no?). Therefore, no subroutines over 32K. What you need to do is break up those subroutines, so that their pieces come out less than 32K each, then put pieces into separate segments. What are you doing with routines that big, anyway? What's the point of structure? BTW: the reason resources aren't supposed to be over 32K is that their sizes are expressed as integers (maxint=32767).
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (09/27/90)
In article <1990Sep26.225549.17792@midway.uchicago.edu> francis@arthur.uchicago.edu (Francis Stracke) writes: >In article <1990Sep24.184845.12502@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >> >[...] >>I tried compiling this on the Mac with a borrowed copy of Lightspeed C >>and it failed. These are large programs - a couple of megabytes >>of global data and several very large subroutines (that compile to >>somewhere between 50 and 125 kbytes of code on varying computers). >>Lightspeed C apparently thinks it is too big. > >Damn straight, it's too big! Macs use a variety of segmenting that puts each >segment of your program into its own code resource (if you don't know, don't >worry). No resource can be bigger than 32K (theoretically--I've seen some >sound resources get around it somehow--but it's probably tricky and risky >enough that no compiler would do it, especially with work-arounds available-- >see below). No subroutine can be spread across more than one segment >(reasonable, no?). Therefore, no subroutines over 32K. > >What you need to do is break up those subroutines, so that their pieces come out >less than 32K each, then put pieces into separate segments. No way Jose - I'm not about to try that sort of crap. I did once try it and I still thank God that I already owned lots of stock in a company that sells Aspirin :-(. >What are >you doing with routines that big, anyway? That what it takes to express the logic of the program. Haven't you ever seen an expression that takes 20 lines? Some of these things might have 300 expressions that big. Ever seen a subroutine that calls sin or cos 5000 times? I have. > >BTW: the reason resources aren't supposed to be over 32K is that their sizes are >expressed as integers (maxint=32767). Guess I'll just have to fork over for a CD-ROM reader for my PC - It happily generates subroutines over 100 kilobytes long. Doug McDonald
keith@Apple.COM (Keith Rollin) (09/27/90)
In article <1990Sep26.225549.17792@midway.uchicago.edu> francis@arthur.uchicago.edu (Francis Stracke) writes: >In article <1990Sep24.184845.12502@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >> >[...] >>I tried compiling this on the Mac with a borrowed copy of Lightspeed C >>and it failed. These are large programs - a couple of megabytes >>of global data and several very large subroutines (that compile to >>somewhere between 50 and 125 kbytes of code on varying computers). >>Lightspeed C apparently thinks it is too big. > >Damn straight, it's too big! Macs use a variety of segmenting that puts each >segment of your program into its own code resource (if you don't know, don't >worry). No resource can be bigger than 32K (theoretically--I've seen some >sound resources get around it somehow--but it's probably tricky and risky >enough that no compiler would do it, especially with work-arounds available-- >see below). No subroutine can be spread across more than one segment >(reasonable, no?). Therefore, no subroutines over 32K. > >What you need to do is break up those subroutines, so that their pieces come out >less than 32K each, then put pieces into separate segments. What are >you doing with routines that big, anyway? What's the point of structure? > >BTW: the reason resources aren't supposed to be over 32K is that their sizes are >expressed as integers (maxint=32767). Francis, Go to jail, do not collect $200. Your conclusion was correct (that the limit on code segments and procedures is generally 32K), but your reasons are wrong. First of all, there is no theoretical reason why resources cannot be larger than 32K. Looking on page I-129 of IM, you'll see in the middle of the page that resource lengths are stored as 4 bytes - a long int. However, if you flip the page to I-130, you'll see a line describing a 3 byte entry. This three byte entry is an offset to the resource being referenced. This limits the size of your resource fork to around 16Meg. Hence, the largest resource you can have is actually a function of how many resources you have. If you have only one, then you should be able to get it pretty close to 16Meg (yes, you, too, can try this at home on your 16Meg Macintosh). So where did this lore of resources being 32K or smaller come from. It's because of a bug in the 64K ROMs. As I recall, there were problems with handling resources in the even 32K banks (i.e. 32K-64K, 96K-128K, etc.). However, this was fixed over 4 years ago with the 128K ROMs. (The details of this could be off a little, but I think that's the gist of it. Feel free to correct me if I'm wrong.) On the other hand, there is still a practical limit of 32K on CODE resources, which hold your program's object code. This is because of a limitation in the 68000. Code in the Macintosh architecture needs to be relocatable, which means no absolute address. This leaves us with being able to use only PC-relative address modes for branching. And the only PC-relative address modes use 16-bit signed offsets. This gives a range of 32K in either direction. This is what gives us our limitation of 32K in CODE resource (the code at the beginning of the segment has to be guaranteed to reach a procedure at the end). Similarly, we have our limitations on global variable space and jump table size. Both of these are reference with the A5 register. The global variable space comprises the 32K below A5, and the jump table takes up the 32K above A5. Now, some of this can be worked around by the enterprising hacker, but not by the faint of heart. But for those of you with the patience and the bucks, MPW 3.2 will go a long way towards abolishing those limits for once and for all. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
d88-jwa@dront.nada.kth.se (Jon W{tte) (09/28/90)
In article <1990Sep26.225549.17792@midway.uchicago.edu> francis@arthur.uchicago.edu (Francis Stracke) writes: >Damn straight, it's too big! Macs use a variety of segmenting that puts each >segment of your program into its own code resource (if you don't know, don't >worry). No resource can be bigger than 32K (theoretically--I've seen some >sound resources get around it somehow--but it's probably tricky and risky >What you need to do is break up those subroutines, so that their pieces come > out less than 32K each, then put pieces into separate segments. What are >you doing with routines that big, anyway? What's the point of structure? Such nonsense ! Resources can be as big as you like. Sizes are longints and have been since version 2 of the system (or something thereabout) It's just that the 64k ROMs had a few bugs in them... CODE resources and ststic/global data can't be larger than 32k because the compiler uses 16-bit offsets (much faster and more efficient) I believe there is a version of MPW C (3.1 ?) that lets you make it generate 32bit references, and thus get around the limits. (16bit offsets are made because all code on the mac is relocatable) h+ Jon W{tte, Stockholm, Sweden, h+@nada.kth.se
morse@currituck.cs.unc.edu (Bryan Morse) (09/28/90)
>Guess I'll just have to fork over for a CD-ROM reader for my PC - >It happily generates subroutines over 100 kilobytes long. Since when? What compiler and how in the world does it do it?