landon@Apple.COM (Landon Dyer) (05/26/88)
> ... The MPW implementation is pretty > much the same as the UNIX implementation, except the *stupid* compiler > and the *stupid* linker will not allow more than 32k of global data. > ... > > I didn't realize this until trying to link Flex, but a maximum of > 32k for global data in a real program is *stupid* (imagine the word > *stupid* in bold, italic, shadowed style of the system font, size 24). > Get with it, Apple. The Mac architecture uses the 32K "below" A5 to hold global data. 16-bit register-relative references are much cheaper than any kind of 32-bit reference, which probably made a big difference in what would fit into the 128K RAM available on the original Mac. The current compilers generate 16-bit A5-relative references to global data. The code generation imposes the 32K limit; the linker doesn't have much to do with it. The Pascal and C compilers in the Beta release of MPW 3.0 will have options to generate 32-bit A5-relative references to global data. Since the 68000 doesn't have a corresponding addressing mode, several instructions must be generated for each data reference. It's rather expensive, but it may help you get ported software off the ground. Again: If you have more than 32K of global data, chances are that you're doing something wrong. -Landon -- I speak for me.
earleh@eleazar.dartmouth.edu (Earle R. Horton) (05/27/88)
In article <11064@apple.Apple.Com> landon@Apple.COM (Landon Dyer) writes: >> ... The MPW implementation is pretty >> much the same as the UNIX implementation, except the *stupid* compiler >> and the *stupid* linker will not allow more than 32k of global data. >> ... >> >> I didn't realize this until trying to link Flex, but a maximum of >> 32k for global data in a real program is *stupid* (imagine the word >> *stupid* in bold, italic, shadowed style of the system font, size 24). >> Get with it, Apple. > s/\*stupid\*/PRIMITIVE/g >The Mac architecture uses the 32K "below" A5 to hold global data. >16-bit register-relative references are much cheaper than any kind of >32-bit reference, which probably made a big difference in what would >fit into the 128K RAM available on the original Mac. Which Apple no longer supports. >The current compilers generate 16-bit A5-relative references to global >data. The code generation imposes the 32K limit; the linker doesn't >have much to do with it. The linker generates the offset. The compiler generates the addressing mode, and a request for an offset. Both are in cahoots to support a style of programming which only self-abusive ***** can enjoy. >The Pascal and C compilers in the Beta release of MPW 3.0 will have >options to generate 32-bit A5-relative references to global data. >Since the 68000 doesn't have a corresponding addressing mode, several >instructions must be generated for each data reference. It's rather >expensive, but it may help you get ported software off the ground. The 68000 has a total of eight address registers. A properly written compiler would optimize things so that the entire address calculation did not have to be done every time. Compilers are capable of performing a degree of optimization which, judging from the quality of code generated by Apple products, you are not aware of. If long addresses are so expensive, why does my real-time signal averager program, which works on an *** 8086 *** and is written in Intel FORTRAN, work so well? The answer is that although the compiler uses long addresses exclusively, it only calculates the full address when it has too. Another, possibly cynical, answer is that the Intel FORTRAN compiler is expensive. MPW C has the habit of loading all the registers which it can with automatic variables. If, instead, it made more imaginative use of address registers, a segmented data model could be used, much like the segmented code model which you now have. Example: Subroutine makes heavy use of global array x[]. Compiler generates code which calculates base of array x[], and stuffs the address in A2. All references to x[offset] are now referenced off of A2. The programmer uses shorts as array indices if he wants fast code, longs if he wants to make x[] large. The compiler uses the short mode if the array index is a short, and uses the long mode otherwise. It is not that hard to segment data, call DEC and ask them how they do it. The MPW linker now supposedly can optimize Object Pascal. Wouldn't it be nice if the linker could optimize long addressing, so that the compiler could use it? > >Again: If you have more than 32K of global data, chances are that >you're doing something wrong. MY_TYPE *x,*y,*z,.............,*last_array; main() { x = (MY_TYPE *)malloc(<size>); y = (MY_TYPE *)malloc(<size>); z = (MY_TYPE *)malloc(<size>); . . . last_array = (MY_TYPE *)malloc(<size>); if (x == nil || y == nil || z == nil ... ... || last_array == nil){ exit(); } This is what the first 25 lines of code in Flex for MPW now look like. The compiler and linker have enough information between them so that a properly written _RTInit() could do this for me. You may have heard the term "application loader" before. An application loader is an operating system or run time library extension which reads code for an application program into memory, allocates space for static data used by the program, RECONCILES ADDRESS REFERENCES NOT DONE BY A LINKER, and initializes data as necessary. You are asking me to write part of the loader for my application programs myself, and I just don't think that that is my job. To summarize, there are a number of techniques which could be used to make programs which run under the current Macintosh operating system capable of handling more than 32k of global data, and in a manner which is totally transparent to the programmer. Properly written compilers and linkers would make the expense of long addressing minimal, and would only use it where necessary. I don't merely want to "get ported software off the ground" as you say, I want to have GENERAL PURPOSE SOFTWARE available in this environment. The annoyance of having to go through a well-written program, and allocate storage for every array in it, really burns me up. The IBM PC programmers would not put up with this ****, and I don't think we should have to either. Sooner or later, people are going to get over the cuteness of the Macintosh graphical user interface, and are going to try to put these machines to work. The more difficulties you remove from the goal of getting this done, the more machines you will sell. Get with it, Apple. ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************
wetter@tybalt.caltech.edu (Pierce T. Wetter) (05/28/88)
> >The current compilers generate 16-bit A5-relative references to global >data. The code generation imposes the 32K limit; the linker doesn't >have much to do with it. > Actually according to the object code description, the linker does have a lot to do with it, in fact, its the one the generates the references. Pierce ---------------------------------------------------------------- wetter@tybalt.caltech.edu Race For Space Grand Prize Winner. ----------------------------------------------------------------- Useless Advice #986: Never sit on a Tack.