home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / prime / 2660 < prev    next >
Encoding:
Text File  |  1992-12-23  |  2.1 KB  |  47 lines
  1. Newsgroups: comp.sys.prime
  2. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!darwin.sura.net!jvnc.net!primerd.prime.com!j.cook
  3. From: j.cook@primerd.prime.com (C. James Cook)
  4. Subject: Re: X Windows on 50-Series
  5. Message-ID: <1992Dec23.102858@primerd.Prime.COM>
  6. Organization: Prime Computer R&D
  7. References: <1h9e2jINNkht@werple.apana.org.au>
  8. Date: Wed, 23 Dec 1992 15:39:27 GMT
  9. Lines: 36
  10.  
  11. markd@werple.apana.org.au (Mark Delany) writes:
  12.  
  13. > Tell me something. I can understand the philosophical differences
  14. > regarding (say) Module II vs PLP, but I really struggle to understand
  15. > why all that energy went into both SPL *and* PLP. I found the
  16. > differences vastly more annoying than useful.
  17. > 
  18. > At the time people were vehement, but surely much of the argument was
  19. > nits which could have been solved?
  20.  
  21. The PLP vs SPL debate never became a war.  There were strong arguments based
  22. mostly on questions of optimization.
  23.  
  24. PLP was written by Russ Barbour in the late 70's as a project to enable him
  25. to do a Master's Degree project.  SPL is based on the PL1 subset-G compiler
  26. with some full PL1 additions (either do/while or do/until) plus some Prime
  27. extensions, but minus PL1 I/O.
  28.  
  29. PLP produced better code than SPL.  However, the PLP compiler has bugs and
  30. suffers maintainability problems (remember: these products are not supported
  31. for customer use). PLP also suffers from symbol table limits.  SPL is much 
  32. more maintainable, has an essentially unlimited symbol table, and has had a
  33. lot of work in the optimizer and code generator.  (Some day I have to run
  34. one last code size comparison).
  35.  
  36. > On a tangent, you may want to see the old discussions re 64-bit
  37. > addressing in comp.arch, one suggestion was that every data bit in the
  38. > universe would be potentially visible in one huge address space! The
  39. > mind boggles really.
  40.  
  41. If you are a 50-series instruction set guru, you will notice the three word
  42. pointer format first defined with the P400 in the 70's has the capability to 
  43. address down to the bit level.  One wonders how far in this direction the 
  44. architects or instruction set designers might have headed if things had been 
  45. different...
  46.  
  47.