home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / pdp11 / 667 < prev    next >
Encoding:
Internet Message Format  |  1992-09-13  |  2.7 KB
  1. Path: sparky!uunet!wupost!spool.mu.edu!yale.edu!jvnc.net!rutgers!spcvxb.spc.edu!terry
  2. From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
  3. Newsgroups: vmsnet.pdp-11
  4. Subject: Re: UNIX for 18-bit pdp-11:s...
  5. Message-ID: <1992Sep13.223340.3860@spcvxb.spc.edu>
  6. Date: 14 Sep 92 02:33:40 GMT
  7. References: <9209130203.AA63508@hal.gnu.ai.mit.edu>
  8. Organization: St. Peter's College, US
  9. Lines: 41
  10.  
  11. In article <9209130203.AA63508@hal.gnu.ai.mit.edu>, petrilli@gnu.ai.mit.edu (Chris Petrilli) writes:
  12. > On anything less than a high-end PDP (ie. 11/70, 11/84, etc..) I think
  13. > RSX is a much better route.  Even RSTS would be a better choice than
  14. > Unix.  I have payed with various Unix implementations on the 22bit
  15. > machines, and while usable, I just don't think that it's going to cut
  16. > it for most people.  I guess working on a 50+MIPS RS/6000 spoils me,
  17. > but I still enjoy playing with older machines.  However, the problems
  18. > come about in that V7 and early BSD (pre 4.2) are not well supported
  19. > any more by PD code, much less good compilers.
  20.  
  21.   22-bit addressing and I/D are pretty much a must these days for _any_ multi-
  22. user PDP-11 operating system. While (for example) RSTS/E V10.0 will still run
  23. on an 11/34 w/ 128Kw and no FP, a _lot_ of work was done by the developers to
  24. make it fit. And the definition of "fit" is: RSTS, no loaded overlays, 1 RTS
  25. and 1 user at swap max.
  26.  
  27.   I run both RSTS/E and 2.11BSD Unix on PDP-11's. I'm the other half of the
  28. "sms and tmk PDP-11 Unix conspiracy". We have real people running real code on
  29. the PDP-11 Unix.
  30.  
  31.   With a few man-years of effort, PDP-11 Unix could be reworked to support
  32. ANSI C, programs up to 4Mb, functions up to 64Kb, and data of up to 64Kb per
  33. element (char foo[65535]). Steve and I have discussed this and we agree that
  34. it's doable, and we've even designed it at the top level. However, it's not
  35. obvious that anyone would commit to doing the work, or to running the result
  36. of the project (for many of them, the current implementation is just fine).
  37.  
  38. > My experience with the C compiler that is on the PDP is pretty bad.
  39. > Last I recall, not only does it have quite a few bugs but it also
  40. > generates pretty bad code.  I don't want to discourage anyone, just
  41. > tell them what they are getting themselves into.
  42.  
  43.   Which C compiler? DECUS C, DEC's PDP-11 C, or the 2BSD C? DECUS C has a bunch
  44. of quirks and is stuck at "classic C". DEC's PDP-11 C is a lot less buggy, but
  45. doesn't optimize as well as it could. 2BSD C is good enough to compile the en-
  46. tire 2BSD OS and utilities. I've actually done a complete compile of _every-
  47. thing_ on 2BSD, twice.
  48.  
  49.     Terry Kennedy        Operations Manager, Academic Computing
  50.     terry@spcvxa.bitnet    St. Peter's College, Jersey City, NJ USA
  51.     terry@spcvxa.spc.edu    +1 201 915 9381
  52.