Path: utzoo!attcan!uunet!snorkelwacker!mintaka!yale!cs.utexas.edu!wuarchive!decwrl!world!burley From: burley@world.std.com (James C Burley) Newsgroups: comp.lang.fortran Subject: Re: anyone using a PRIME????? Message-ID: Date: 20 Oct 90 13:37:38 GMT References: <41420@eerie.acsu.Buffalo.EDU> Sender: burley@world.std.com (James C Burley) Organization: The World Lines: 64 In-Reply-To: v087mxgb@ubvmsa.cc.buffalo.edu's message of 18 Oct 90 13:02:32 GMT In article <41420@eerie.acsu.Buffalo.EDU> v087mxgb@ubvmsa.cc.buffalo.edu (Shawn E Thompson) writes: Primes are very popular Fortran boxes, and very big in CAD. I understand (maybe incorrectly) that PrimOS was developed in Fortran...either way they are great Fortran boxes...... Early version of PRIMOS we written in Fortran and assembler. The Fortran was a 66 compiler, and no built-in I/O was used: it was just used to manage data structures (via EQUIVALENCE and COMMON, sigh), do computational stuff (the kind that gets done in OS kernels, i.e. little or no REAL), and call on assembly routines to get the real work done. In around 1980 they began rewriting parts of it and writing new parts of it in a PL/I subset called PL/P (an in-house compiler). The file system for Rev 19.0 was almost entirely in PL/P, as was the FAM II (File Access Manager, second incarnation) kernel support code (the second incarnation eliminated the FAM manager process, which was written in Fortran). More of the system evolved into PL/P instead of Fortran, especially at Rev. 19.4. After that I left the company, so I don't know what's happened since. But they used PL/P just the way they used Fortran: no built-in I/O etc. But of course PL/P offered more advanced data structuring and access and more elegant structuring facilities (better than even Fortran 77). To my knowledge, they never used their newer Fortran 77 compiler and companion PL/I compiler subset, PLI/G (used heavily for utilities starting in around '81) in actual OS kernel code; they weren't designed for kernel code. They did start moving towards using Modula II around 1985, both in the kernel and in utilities, but I get the impression that they then switched to C a few years later without having done much production code in Modula II. Primes are great Fortran machines, indeed. They're also great PL/I machines, because they were built on the Honeywell Multics model. (Actually, the early Primes, the 100, 200, and 300 were built on the Honeywell 516 (?) model, and the Multicisms arrived with the 400 and especially the 500, which were the beginnings of the entire 50 series and incorporated hardware-implemented virtual memory and process exchange/semaphores.) They're lousy C machines, because the neat procedure call mechanism built into the hardware for doing PL/I and security (rings of protection) fast actually interfere with doing the call-by-value demanded by C efficiently. They had proposals to create a new architecture to deal with these and other problems for years, but I don't know whatever came of all that (aside from the EXL machines, which I know nothing about except they can run UNIX in a more native fashion than the 50 series). Putting UNIX on the 50 series apparently was a major chore because of the difficulties with C. There are many reasons Prime 50 series machines are great for a lot of tasks. They were great machines, and this from someone who worked in the company long enough to know their problems. I still prefer them over VAXen and any other machines I know, even those other that (like VAX) have more "elegant" instruction sets and operating systems. For price/performance and the ability to just get things done and done fast, Primes sure were (and are?) hard to beat. Wish I could still work on them. Wish Prime itself had done something more with their incredibly superior platform in the late 70s than just do marketing -- they could have established really great networking products, compiler technology, operating systems features, graphic interfaces, REAL word processing (not the monstrosity they inflicted call OAS of whatever), and such, all projects with real potential that were killed by lack of courage in management (hard to be courageous when the company is making so much money) and which later proved, via other's efforts, to be extremely fertile ground despite the hardships in implementation dealt with by those making the efforts on machines other than Primes! End of flame. James Craig Burley, Software Craftsperson burley@world.std.com