mcdonald@uxe.cso.uiuc.edu (01/31/88)
In the review of MPW C in the current issue of Byte, it is stated that a Mac program can't have a "code segment" longer than 32K, nor more than 32k of static data. I was considering using a Mac II for some of the research work I do. If this statement were true, a large number of my Fortran and C programs won't run. I thought that the 68020 had a full 32bit flat address space, i.e. no segments at all. This would seem to imply that I could write a program any size that will fit into memory; likewise for static (initialized) data. Lots of my programs have more than 32K in strings and initialized numeric data alone. The only experience I have had on a mac was in porting a fairly large Fortran program (using Microsoft Fortran, which was just plain wierd. It didn't HAVE static data at all. All data statements generated CODE!!!) If a MAC can't run ordinary Fortran or C programs without recoding, it is useless to me. (These Fortran programs all run fine on a stupid compiler we have for an FPS-164, which is EXACTLY fortran 77, no less, and most emphatically no more.) Doug McDonald (mcdonald @uiucuxe)
mcb@oddjob.UChicago.EDU (The One Holding The Iguana) (02/02/88)
In article <46100070@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >a Mac program can't have a "code segment" longer than 32K, nor more >than 32k of static data. I had thought that the 68020 had a full 32bit flat >address space, i.e. no segments at all. This would seem to imply that I >could write a program any size that will fit into memory; likewise for static >(initialized) data. > >Doug McDonald (mcdonald @uiucuxe) This has to do with 68000 addressing modes. For various reasons, the 680x0 is much more efficient when dealing with 16 bit displacements. This is to say that it's much faster to access data or make a program jump if you stay within a 16 bit address displacement. 16 bits is equivalent to +/- 32K, so the Macintosh requires that all program code be broken up into 32K blocks. For similar reasons, you have to stick with 32K of static data. This is not, in general, a big problem. If you're using some high-level language like C :-) or FORTRAN :-(, the effects of this are pretty much transparent. What you have to do is go through all of your source files, and periodically insert statements to the effect of "segment initializer", or "segment display_stuff", or whatever. the MPW manual has all the details, but assuming that your code comes in a number of reasonably sized files, this is a pretty trivial procedure. Static data is slightly more tricky. The easiest way to do this is probably to dynamically allocate the memory you need for static data using the memory manager, and then read the data in from a file. Here is a skeleton outline of approximately what you would do: instead of int my_big_array[50000]; write int *my_big_array, myFile; my_big_array = NewPtr(50000 * sizeof(int)); myFile = open("StaticData", INPUT); read(myFile, my_big_array, 50000 * sizeof(int)); close(myFile); after this, you can use my_big_array just the way you did before. You'll have to be virtuous about variable scope, error checking, and all the rest of it, but this shouldn't be a big problem. In my experience, it's well worth the extra effort- my stuff on a MacII pretty much keeps up with our SunIII/280 under unloaded conditions. When the Sun gets busy (or goes down), there's no comparison 8-). Hope this was helpful- email me if you have questions. -Matt -- Matt Bamberger "You think that because you understand _one_, 1005 E. 60th St., #346 you understand _two_, because one and one Chicago, IL 60637 makes two. But you must also understand 312-753-2261 _and_." -Sufi Master
shap@sfsup.UUCP (J.S.Shapiro) (02/02/88)
In article <46100070@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > > In the review of MPW C in the current issue of Byte, it is stated that > a Mac program can't have a "code segment" longer than 32K, nor more > than 32k of static data. Well, this is true and it isn't. The reason behind all of this is a limitation on the 68000 concerning indirect addressing. To get to any such things, the Mac compilers generate an addressing mode which amounts to (segment base) + offset, and on the 68000 you could only offset by 16bits * 4 bytes per word == 32k, consequently the limit. The addressing mode is called "Address Register Indirect with Displacement" Now before you panic, this is only a limit if you want to do relocatable code. It is possible to generate so-called "large model" code, and most of the current crop of C compilers do. Unfortunately, such code is not guaranteed to run under multifinder (read: probably wont) because it needs to be absolute addressed. Note also that on the m68020, the Address Register Indirect with Displacement addressing mode has been expanded to handle up to 32 bit displacements - the full addressing range. Unfortunately, when Apple defined the CODE resource they permitted only 16 bits for the offset entry. Like I said, the answer is "yes and no." In my opinion, it is time that Apple introduced a new code resource, COD2, that allowed the full 32 bit range. While this would not run on the non-68020 macs, the classes of problem for which people are buying Mac-II's demand it. It shouldn't be terribly hard to write a patch to the segment loader to handle this problem. Since you can have multiple code segments, there is no problem with that. My advice to you conerning static data is that you should put your static data in a resource and load it into a hand-allocated heap resource. Messy, but it will work. Jon
mcb@oddjob.UChicago.EDU (The One Holding The Iguana) (02/02/88)
In article <2738@sfsup.UUCP> shap@sfsup.UUCP (J.S.Shapiro) writes: >My advice to you conerning static data is that you should >put your static data in a resource and load it into a hand-allocated >heap resource. Messy, but it will work. > >Jon Ahhh... is this a good idea? On old macs with old systems, the Resource Manager doesn't like dealing with big resources (>32K). I don't know when (if ever??) this was changed- all I have handy is the promo edition of Inside Mac (vol. I, p. 30). Also, resources can't be manipulated with stdio calls. -Matt -- Matt Bamberger "You think that because you understand _one_, 1005 E. 60th St., #346 you understand _two_, because one and one Chicago, IL 60637 makes two. But you must also understand 312-753-2261 _and_." -Sufi Master
phssra@emory.uucp (Scott R. Anderson) (02/06/88)
In article <46100070@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >If a MAC can't run ordinary Fortran or C programs without recoding, >it is useless to me. (These Fortran programs all run fine on >a stupid compiler we have for an FPS-164, which is EXACTLY fortran 77, >no less, and most emphatically no more.) Not quite; for some obscure reason, FPS-164 fortran does have a #include facility; but that's about it for extensions. * Scott Robert Anderson * ** gatech!emoryu1!phssra * * * ** phssra@emoryu1.{bitnet,csnet} * * * * * ** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *