home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / programm / 3193 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  1.6 KB
  1. Path: sparky!uunet!think.com!bromley
  2. From: bromley@think.com (Mark Bromley)
  3. Newsgroups: comp.programming
  4. Subject: Re: first-year programming languages
  5. Date: 20 Nov 1992 15:33:06 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 20
  8. Distribution: na
  9. Message-ID: <1ej0fiINNapi@early-bird.think.com>
  10. References: <aelman.721693402@Xenon.Stanford.EDU> <dnebing-141192140340@m64-143.bgsu.edu> <1992Nov19.000628.18932@linus.mitre.org>
  11. NNTP-Posting-Host: luna.think.com
  12.  
  13. In article <1992Nov19.000628.18932@linus.mitre.org> crawford@boole.mitre.org (Randy Crawford) writes:
  14. >I'm not so ready to predict that computers in 2020 will so closely resemble
  15. >today's crop of assembly machines.  After all, hasn't assembly programming
  16. >pretty much disappeared from most software development in the past decade?
  17. >Ever try to outguess optimizing compilers on architectures like SPARC or 
  18. >PA-RISC?  Think you could better their scheduling/pipelining/register-window 
  19. >use by programming in assembly?  If so, you're a far better assembly programmer 
  20. >than I. 
  21.  
  22. I wouldn't say that assembly has disappeared in the last decade.  It is
  23. rare to find large programes totally implemented in assembler, but some
  24. speed critical sections of code are still implemented in assembler.
  25. Scheduling, pipelining, caches etc are not mysterious.  Given any
  26. reasonably short sequence of code, say on the order of a page, I would
  27. expect humans to be better than compilers when they are willing to expend
  28. the effort.
  29.  
  30. From first hand experience I can tell you that the SPARC compilers are not
  31. exactly omniscient.
  32.  
  33.