home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / compiler / 1269 < prev    next >
Encoding:
Text File  |  1992-07-29  |  2.8 KB  |  62 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!gatech!destroyer!sol.ctr.columbia.edu!eff!world!iecc!compilers-sender
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: Pros and cons of high-level intermediate languages
  5. Reply-To: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  6. Organization: Computer Science, University of Melbourne, Australia
  7. Date: Sat, 25 Jul 1992 10:21:32 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-07-090@comp.compilers>
  10. References: <92-07-068@comp.compilers> <92-07-086@comp.compilers>
  11. Keywords: storage, C, question
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 47
  14.  
  15. acha@CS.CMU.EDU (Anurag Acharya) writes:
  16.  
  17. >Wish list:
  18. >
  19. >1. label variables. Any kind of label variables with any resonable
  20. >restrictions
  21. >
  22. >   (statically scoped, no jumping to inside blocks etc.). This would
  23. >   greatly facilitate compilation of both functional languages and parallel
  24. >   languages. It would also facilitate parallelizing compilers for other
  25. >   languages. To this, add a C compiler that does not limit the size
  26. >   of individual functions and you are close to using C as an assembly
  27. >   language
  28.  
  29. If you are willing to restrict yourself to gcc 2.X then I think that you
  30. will find what you need here. gcc 2.X supports label variables and
  31. reportedly has no limits on function size. Beware though, that many
  32. optimizers (and I think gcc falls in this category) use algorithms that
  33. are O(n^2) time & space or worse, where n is the length of a function, so
  34. you may find that even though there are no arbitrary hard limits,
  35. compilation becomes unacceptably slow.  (In the worst case, the compiler
  36. thrashes itself to death for a few hours before running out of virtual
  37. memory :-( ).
  38.  
  39. >2. A portable way of looking at the stack. Supporting  garbage collection
  40. >   and call/cc (user-level continuations) would be easier if one could 
  41. >   traipse up and down the C stack. Currently, such schemes are machine and
  42. >   compiler dependent. 
  43.  
  44. >3. Some form of global register assignment. Some annotation scheme that
  45. >   allows me to indicate to the C compiler that I would like a particular
  46. >   global variable to be stuck in a register (may be a particular register
  47. >   if I am willing to give up portability).
  48.  
  49. Again, if you are willing to restrict youself to gcc 2.X then this
  50. facility is provided. Unfortunately you *have* to specify which particular
  51. register, so porting will require a bit more work with #if's and so forth.
  52. [You could specify that for machine X, use register A1, for machine Y, use
  53. register SI, for any other machines don't use a register - that way the
  54. code will port easily to any machine, and the extra work is only required
  55. if you want it to be efficient.]
  56.  
  57. -- 
  58. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  59. -- 
  60. Send compilers articles to compilers@iecc.cambridge.ma.us or
  61. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  62.