home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / programm / 21156 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  2.9 KB
  1. Path: sparky!uunet!wupost!spool.mu.edu!agate!stanford.edu!apple!goofy!mumbo.apple.com!gallant.apple.com!seuss.apple.com!user
  2. From: absurd@apple.apple.com (Tim Dierks, software saboteur)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: Best method of avoiding code/data segment issues
  5. Message-ID: <absurd-100193205931@seuss.apple.com>
  6. Date: 11 Jan 93 05:09:13 GMT
  7. References: <1993Jan9.044328.19069@gn.ecn.purdue.edu>
  8. Sender: news@gallant.apple.com
  9. Followup-To: comp.sys.mac.programmer
  10. Organization: MacDTS Marauders
  11. Lines: 55
  12.  
  13. In article <1993Jan9.044328.19069@gn.ecn.purdue.edu>,
  14. jess@gn.ecn.purdue.edu (Jess M Holle) wrote:
  15. > 
  16. > I am in the process of getting a large chunk of C++ code from a
  17. > UNIX workstation (SGI) to compile on the Mac.  Although I have
  18. > not gotten everything to compile, I am getting relatively close.
  19. > My problem is that I want to avoid messing with code/data 
  20. > segmentation issues as much as possible.
  21. > 
  22. > What is the best way to do this? -model far? -br? -bigseg?  How
  23. > much do any of these affect code-size/performance (not too 
  24. > important)?  Any bugs/incompatibilities to watch for?
  25. > 
  26. > If it matters any, the final link will be based on a half dozen
  27. > libraries.  Some of these have been placed in named segments, but
  28. > most haven't and I'd rather not bother if I don't have to.
  29. > 
  30. > Thanks a lot (this newsgroup is a BIG help, thanks to all of you).
  31. > 
  32. > 
  33. > Jess Holle
  34.  
  35. -model far will remove almost all 16-based limitations from your
  36. MPW code.  I believe structures larger than 32K and local variables
  37. larger than 32K are not allowed, but I may be incorrect.  If you
  38. want everything to go into one segment, you can do so by adding
  39. "-sg Main" to your link command; this merges all segments into
  40. the Main segment; if your code doesn't actually ever unload a
  41. segment, this is probably better than loading a number of
  42. segments and leaving them loaded.
  43.  
  44. 32-bit everything degrades performance to a certain degree, although
  45. this can be reduced somewhat by restricting your code to running
  46. on 68020s or better; the 68000 doesn't have some useful 32-bit
  47. offset addressing modes, so some 32-bit addressing has to be done
  48. manually on the 68000; removing it as a destination makes more
  49. efficient constructs possible.
  50.  
  51. If you're only going to run on >= 68020, then -bigseg can help create
  52. large code segments, but all your external entry points must be in
  53. the first 32K because the jump table is still just 16-bit.  There
  54. should be little if any performance impact, because this is done
  55. entirely with a processor addressing mode.
  56.  
  57. -br will allow you large code resources on any processor; once again,
  58. all external references must be in the first 32K.  Jump islands
  59. make long jumps slightly slower, but not greatly so.
  60.  
  61. In summary, -model far is the only complete solution, but -br or
  62. -bigseg impact your code a little less and can be useful.  I don't
  63. know of any significant show-stopping problems with any of these
  64. options.
  65.  
  66. Tim Dierks
  67. MacDTS, but I speak for myself
  68.