usenet@cmx.npac.syr.edu (USENET) (10/06/89)
I have a compiler I wrote under UNIX, that uses code generated by YACC and LEX. Therefore, there are a good chunk of glabal data arrays (initialized). I want to get his working on the MACIIx. From: polar@wotan.top.cis.syr.edu (Paul R. Humenn) Path: wotan.top.cis.syr.edu!polar I have a MACIIx with 8 bloddy megabytes of memory, and it seems that I can't access it. I have plenty of functions and they have to go thru this "jump table". Please exuse my ignorance of this Mac. However, my SUN is a 68030 and I can access all kinds of data. With the MPW software, I can't even get past the Linker. Global data size exceeds 32K. That seems to be a problem but I'm not sure if it is the root of it. Now, I've read the manuals and all that stuff and I believe I've selected the right options for 32-bit addressing. I've played around pretty thoroughly with all the C compiler and Linker switches. I have about 37 C files with tons of functions that I try to link with the given libraries. Under Unix the executable is about 256K. I have rearragned the link command several ways (moved filenames around and different switches) and get different errors, but bacically all telling me some offset is out of range. These are the three errors: Error 50, Jump table offset is out of range Error 48, PC-relative edit, offset out of range Error 49, Computed Reference offset out of range Now, I suspect that this may have to do with the Libraries since most of the errors end up comming from or around there. I've used the -ss and -srt options. Again, I get different combinations of the above errors. Could it be that the Clibraries are not compiled with the -m -n options allowing 32-bit addressing, or is totally me!?! All I want to do is to compile and run my C code. I have a 68030 processor with 8 meg of memory, just like my SUN workstation, however .... It is the Mac operating system, trying to be backward compatiable with all those little macs? Should I: a. write smaller programs b. become a tricky Mac system hack to do relatively straight forward simple no nonsense, no tricks programming c. get a *real* operating system for this machine, like Mach, or (Oh god!) AUX. d. Give up. Please excuse my scarcasism, but I beleive I am looking at a very powerful mainframe-like piece of hardware, and it seems to behave like a PDP-8 or worse. I'm very frustrated. Can anyone out there lend some insight to my problem. Thanks a bunch, -Polar polar@top.cis.syr.edu
earleh@eleazar.dartmouth.edu (Earle R. Horton) (10/06/89)
In article <1937@cmx.npac.syr.edu> polar@top.cis.syr.edu (Polar Humenn) writes: ... >I have a MACIIx with 8 bloddy megabytes of memory, and it seems that I >can't access it. I have plenty of functions and they have to go thru >this "jump table". > >Please exuse my ignorance of this Mac. However, my SUN is a 68030 and >I can access all kinds of data. With the MPW software, I can't even get >past the Linker. Global data size exceeds 32K. That seems to be a problem >but I'm not sure if it is the root of it. ... Two solutions come to mind. a) Get Aztec C. It handles both large data and large code, costs $99 from MacWareHouse with the symbolic debugger ($65 without), works under the MPW Shell, and is K&R, not ANSI. It usually produces load time locatable code, but can produce position-independent code if you take all kinds of restrictive precautions in your source files. b) It looks as if your main problem is that you haven't specified segments for your .c files at compile time. The linker is trying to put everything into the "Main" segment and it just doesn't fit. A good way to start is to segment your program on a source file basis. This is real easy if you do it with the "-s" command line option to the compiler. c blob.c -o blob.c.o -s blob ... It is even easier to specify a default rule in your Makefile that does this. This is the preferred way to do it, in my opinion, since then you don't have to put the segment name in all your source files. Apple has already changed the method of doing this in the source file once, but they haven't changed "-s" yet. Segmenting on the basis of source file is perhaps not the most sophisticated approach to the problem, but it does have the effect of breaking up your code into chunks that are small enough for the linker to handle. As a first approach to getting that huge compiler to link, it can't be beat. Large segments often provide better performance. Once you get your program in a state where it will link, you can try to combine segments at link time using the "-sg" option to the linker. You don't have to recompile files to do this. This is all based on my experience with MPW C 2.0.2. MPW C 3.0 should be the same as far as code segments go, but is supposed to handle large data, another problem. Earle R. Horton