On 5/9/24 15:10, Fred Cisin via cctalk wrote: The first versions of Pascal lacked any I/O specification. About a decade ago, I retrieved an early version of Pascal (source) written on the CDC 6000 from a batch of tapes from UIUC: (********************************************************* * * * * * COMPILER FOR PASCAL 6000 - 3.4 * * ****************************** * * * * * * RELEASE 2 MARCH 1976 * * * * * * * * CDC SCIENTIFIC CHAR SET VERSION * * (00B AND 63B ARE TREATED IDENTICALLY) * * * * AUTHOR% URS AMMANN * * INSTITUT FUER INFORMATIK * * EIDG. TECHNISCHE HOCHSCHULE * * CH-8006 ZUERICH * * * *********************************************************) Apparently, the collection had a listing, but not machine-readable source code. That turned up on one of my tapes, so I forwarded it on. You can see the whole shebang at http://pascal.hansotten.com/niklaus-wirth/cdc-6000-pascal-compilers/ I've written code in Pascal, as well as Modula-2. Never liked it--seemed to be a bit awkward for the low-level stuff that I was doing. --Chuck

On 5/9/24 16:30, Michael Thompson wrote: Broadly speaking, there were only three major CDC versions; the 1972 original, the 1975 rewrite, and the (I think) 1980s version. There were intermediate versions, of course. I think that the 1975 version was widely used as a reference for many other implementations. But now comes the question, "Does one design a machine to a language or a language to a machine?" If you take the former course, you have the problem of not being able to implement features that the language designers didn't imagine. In the latter case, you wind up with a language that isn't easily made portable. C, being a "use at your own peril, and by the way, we have inline assembly language features" represents the former, but with lots of latitude. And it requires a certain amount of skill to use effectively. But heck, at CDC, we were writing FORTRAN programs that used negative subscripts. Who remembers SYMPL or CYBIL? LLL had their own extended dialect of FORTRAN, (LRLTRAN) which didn't have a single dialect. Consider the following, which addresses the problem of a standard language not having the necessary hardware implementation. https://dl.acm.org/doi/pdf/10.1145/390015.808405 I was briefly immersed in this mess with F90 X3J3. IBM, DEC and other had their own idea of a vector language (e.g. VECTRAN) and didn't want to entertain the committee's proposals. Both threatened to pull out over this. How many programming languages are there (past and future)? The lists I can find are far from exhaustive. Note that the Pascal site I noted talks about CDC 6000 SCALLOP. Never heard of it--must have been a local ETH creation. --Chuck

On 5/10/24 06:44, Paul Koning wrote: There's a third class that I haven't (yet) mentioned. Design a machine to solve a particular problem or class of problems. Saxpy was such a machine; we have bitcoin ASICs and our latest AI ventures. What was the CM-1 programmed in? --Chuck

And SAGE. paul

Norsk Data had at least two programming languages designed in-house: NPL and PLANC. These had some fairly unusual features, reflecting the hardware. Sent from my iPhone

On 5/15/24 18:47, Ken Seefried via cctalk wrote: I left CDC at around the time that SCOPE 3.4 was being renamed NOS BE and KRONOS was becoming NOS. I remember attending a design meeting for the pager in what was to become NOS/VE. I asked the presenter if he'd conferred with any of the virtual memory pager talent that CDC had in-house. Blank stare. I informed him that the STAR-100 people had lived in that particular hell since about 1969--and that demand paging was not the way to run a shop. STAR had long-since switched to a working set algorithm. Even that wasn't enough. If one selected a large (65 KW) page size and set up certain vector instructions so that addresses crossed page boundaries, it was impossible to get the required pages into memory all at once. The system just sat there and thrashed.... --Chuck

I thought the CDC CYBER and 6000 series mainframes were great systems which performed admirably for what they were designed for. I liked COMPASS, SYMPL and NOS 1 and 2. I didn't do much work in CYBIL, but it was basically an enhanced version of PASCAL suitable for operating systems work. What is there not to like? These mainframes and the CDC 7600 outperformed every other machine until Seymour Cray released his own machines. On Thu, May 16, 2024 at 11:08 AM Ken Seefried via cctalk < cctalk(a)classiccmp.org&gt; wrote:

I worked on the run time support for the early versions of Pascal on the CDC 6000 series.  Depending upon the character set determining the end of line was a major pain.  There was a loop hole in the Pascal type system that allowed you to call any PPU program directly from Pascal.  It was not widely known, but it came in handy at times. On Thursday, May 16, 2024 at 01:52:12 a.m. EDT, Chuck Guzis via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: On 5/15/24 22:07, Tom Hunter via cctalk wrote: SYMPL was pretty new when I left the 6000 series behind.  Much of the code, but for some utilities was still assembly.  FORTRAN (FTN) was used for some simple things. I worked on Zodiac, which was a multi-CPU COBOL  (!) multithreaded multitask OS written for USAF--very unlike anything CDC has ever had.. Lots of ECS and oceans of 844 drives. Special Systems Division was a lot of fun back in the day.  Lots of variety before they started cycling down work at SVLOPS.  My final years at CDC Sunnyvale were with STAR, only to be resurrected in the 1980s with the ETA machines. I think the ROVER people were among the last people at SVLOPS, but I can't recall precisely. A little factoid is that the 6000 series was very good at running COBOL. --Chuck

It was a loop hole in the strong typing of Pascal, not the operating system itself.  You could set up a record structure that mirrored the communications area and then map this to location zero.  This was important for Pascal since it had no library mechanism, it was essentially a compile and go system.  The run time was tied to the particular version of the compiler, if the run time was updated you had to update the tables in the compiler.  This was somewhat similar to the run Fortran compiler, which also avoided using the loader.  The loader was a wonderful piece of software, but it was expensive, so for teaching programming it was avoided at all cost.  I wrote a relational database system in Pascal for the CDC 6000 using this approach for the low level I/O routines.  There were some wonderful things that you could do through the PPU programs. If you were using the FTN compiler for Fortran you could do all of this in COMPASS, but for Pascal that wasn't an option.  One of the fun things you could do is having multiple I/O operations occurring at the same time.  A fun game was to issue a read and write on the same memory location and see when they passed each other. On Thursday, May 16, 2024 at 04:04:05 a.m. EDT, Tom Hunter via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: I assume you refer to the "case ... of" construct in PASCAL record types which allowed you to arbitrarily "cast" - to use a C term - variables to any type you wanted and could be (ab)used to assign integers to pointers. The ability to call PP programs via RA+1 calls was not a loop hole, but a design feature of the CYBER/6600 operating systems like COS, KRONOS and NOS. It simply involved writing to the word in location 1 (RA+1) relative to the start of the segment of memory assigned to your program by the OS. The contents of the word were essentially the name of the PP program and some parameters - typically the address of a parameter block somewhere in your segment of memory. When the OS processed the request, it cleared location 1 (RA+1). This was the standard mechanism used to request OS functions like writing to a file etc. Higher level languages typically wrapped this in library functions (or macros when programming in assembler i.e. COMPASS), but if the language allowed negative array offsets and the ability to determine the address of the array, then it was trivial to explicitly call PPs via RA+1 calls (even more trivial using COMPASS). The OS periodically scanned the RA+1 words of each of several programs currently in memory (i.e. a program assigned to a "control point") and if the RA+1 contents were non-zero, then the OS allocated a free PP to the request and loaded and started the requested PP program into that PP and finally cleared the word at RA+1. You typically would expedite this by after writing the PP request to RA+1, execute an "exchange jump" instruction which stopped the user program from running and re-entered the OS to allow it to soon after process pending RA+1 requests. I hope this all makes sense. On Thu, May 16, 2024 at 3:28 PM Mark GREEN via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote:

I don't know if it does. The other issue is that there isn't as far as I know, an emulator that supports the 64 bit mode it needs. There is of course a (very solid) emulator for the classic 60 bit architecture, DtCyber. paul

It's taken a while for people to learn that languages need to be designed to match the environment where they are used. Language needed for rapid interaction can't be as verbose as regular programming languages. The Unix shell takes that notion to extremes (as does the ITS command handler, from what little I know of it -- and its ancestor the PDP-10 interactive debugger). One of my favorite examples of an interesting command language is the one on Burroughs mainframes, called WFL (work flow language). It looks vaguely like ALGOL, for the very good reason that is is compiled into executable code that is run to perform the various operations you ask for, by invoking the various applications as "forks" and executing flow control like "if" and looping statements. For ALGOL programmers, which was most of us on that system, it was a very comfortable setup. Oh yes, that was a batch system, so WFL would be on card decks, not banged into a terminal interactively. paul

On Thu, 9 May 2024, Paul Koning via cctalk wrote: One of the things that _I_ love about C is that it is easy to get it out of the way when you want to do something lower level. Rather than feeble type system, it could have had a requirement to explicitly "cast" anything being used as a "wrong" type. One of Alan Holub's books about C is titled "Enough rope to shoot yourself in the foot" Each language has its own specialty. And you need to find the one that fits you best. It used to be (and likely still is), that every computer science grad student created a new language. A requirement (usually UNSPOKEN) was that the compiler be able to compile itself. That the language compiler is written (actually normally RE-written) in that language and compiled by that compiler. That certainly seems to bias things towards languages that are well suited for writing compilers! If you were to create a language that was specializzed for something completely different, and poorly suited for writing compilers, then it would not be respected. -- Grumpy Ol' Fred cisin(a)xenosoft.com

On Thu, May 9, 2024, 6:10 PM Paul Koning via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: The other joke is that C++ lets you shoot off the 27 identical legs you didn't know you had... Warner

On Thu, May 9, 2024 at 6:31 PM Paul Koning via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: HP chose Pascal as their system programming language when they came to rewrite the HP 3000's MPE Operating System onto PA-RISC to produce MPE/XL in the mid 80s. It had many extensions to solve the inherent limitations of standard Pascal, like the ability to have formal parameters which could receive actual values of any type, extensive pointer support, well-defined variant records, etc., etc. It remained the most popular language for writing low-level code inside HP and for customers as well, even after C became available. C (including GCC when we got POSIX support) was more commonly used to port open source stuff to the machine. We sold an early client-server retail POS system with a Classic MPE 3000 talking to HP-150 IIs over serial ports, which was written in PASCAL/V on the 3000 and Microsoft Pascal on the HP-150s. Even this earlier Pascal had sufficient extensions to get done what you needed to do without issue.