home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / mac / programm / 12815 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.1 KB
  1. Path: sparky!uunet!darwin.sura.net!jvnc.net!rutgers!micro-heart-of-gold.mit.edu!news.media.mit.edu!news.media.mit.edu.!sro
  2. From: sro@media.mit.edu (Shawn O'Donnell)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: A few more suggestions for THINK C
  5. Message-ID: <SRO.92Jul21221949@media-lab.media.mit.edu>
  6. Date: 22 Jul 92 03:19:49 GMT
  7. References: <SJE.92Jul20180620@xylos.ma30.bull.com>
  8. Sender: news@news.media.mit.edu (USENET News System)
  9. Distribution: comp
  10. Organization: M.I.T. Media Laboratory
  11. Lines: 31
  12. In-Reply-To: sje@xylos.ma30.bull.com's message of 20 Jul 92 18:06:20
  13.  
  14. >   4) There should be some kind of autosegmentation option with the
  15. >   project window.  Why should a deveoper fiddle with moving project
  16. >   entries around?  It would be much nicer if THINK C could just generate
  17. >   code segment partitioning without human intervention.  How hard is it
  18. >   to count to 32 KByte?  After all, the compiler already keeps track of
  19. >   this information.
  20.  
  21. There's more to it than simply counting to 32 kByte, but it is an
  22. interesting suggestion.  The reason they let mere humans move code
  23. from code block to code block is that they were hoping we might come
  24. up with a better-than-random assignment.  In a better-than-random
  25. assignment, your Mac won't be swapping code segments in and out of
  26. memory with each function call.  Functions that frequently call other
  27. particular functions should reside in the same block, if possible.
  28.  
  29. THINK C might be able to make a reasonable first guess at which
  30. functions should live with which other functions, but you can't tell
  31. ahead of time which functions will be calling which other functions.
  32. (The only way you'd know is if your program is independent of user
  33. input or operates on no more than one data set...)
  34.  
  35. What would be useful is if THINK C would log code swaps for you 
  36. while you're developing the code.  Then, if you notice that there
  37. is a lot of unrest on the heap, you can consider reassigning 
  38. project entries from one segment to another.  It may already do
  39. this.  
  40.  
  41. Pardon my ignorance if THINK C already has such a function.  Better
  42. tell me now what it is.  
  43.  
  44. --Shawn
  45.