[COFF] [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[segaloco via COFF]

On Monday, July 8th, 2024 at 3:14 PM, Paul Winalski <paul.winalski at gmail.com> wrote:

> [redirecting this to COFF]
> 
> On Mon, Jul 8, 2024 at 5:40 PM Aron Insinga <aki at insinga.com> wrote:
> 
> > 
> > When DEC chose an implementation language, they knew about C but it had
> > not yet escaped from Bell Labs. PL/I was considered, but there were
> > questions of whether or not it would be suitable for a minicomputer. On
> > the other hand, by choosing BLISS, DEC could start with the BLISS-11
> > cross compiler running on the PDP-10, which is described in
> > https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_CompilerBLISS-11 and DEC's Common BLISS had changes necessitated by different
> > word lengths and architectures, including different routine linkages
> > such as INTERRUPT, access to machine-specific operations such as INSQTI,
> > and multiple-precision floating point operations using builtin functions
> > which used the addresses of data instead of the values.
> > 
> > In order to port VMS to new architectures, DEC/HP/VSI retargeted and
> > ported the BLISS compilers to new architectures.
> 
> There have in general been two approaches to achieving language portability (machine independence).
> 
> One of them is to provide only abstract data types and operations on them and to completely hide the machine implementation. PL/I and especially Ada use this approach.
> 
> BLISS does the exact opposite. It takes the least common denominator. All machine architectures have machine words and ways to pick them apart. BLISS has only one data type--the word. It provides a few simple arithmetic and logical operations and also syntax for operating on contiguous sets of bits within a word. More complicated things such as floating point are done by what look like routine calls but are actually implemented in the compiler.
> 
> BLISS is also a true, full-blown expression language. Statement constructs such as if/then/else have a value and can be used in expressions. In C terminology, everything in BLISS is a lvalue. A semicolon terminates an expression and throws its value away.
> 
> BLISS is also unusual in that it has an explicit fetch operator, the dot (.). The assignment expression (=) has the semantics "evaluate the expression to the right of the equal sign and then store that value in the location specified by the expression to the left of the equal sign".
> 
> Supposing that a and b are identifiers for memory locations, the expression:
> 
> a = b;
> 
> means "place b (the address of a memory location) at the location given by a (also a memory location)". This is the equivalent of:
> 
> a = &b;
> 
> in C. To get C's version of "a = b;" in BLISS you need an explicit fetch operator:
> 
> a = .b;
> 
> Forgetting to use the fetch operator is probably the most frequent error made by new BLISS programmers familiar with more conventional languages.
> 
> DEC used four dialects of BLISS as their primary software development language: BLISS-16, BLISS-32, BLISS-36, and BLISS-64 the numbers indicating the BLISS word size in bits. BLISS-16 targeted the PDP-11 and BLISS-36 the PDP-10. DEC did implementations of BLISS-32 for VAX, MIPS, and x86. BLISS-64 was targeted to both Alpha and Itanium. VSI may have a version of BLISS-64 that generates x86-64 code.
> 
> -Paul W.

On the subject of "closer to the machine" non-assembly languages, were there any noteworthy languages that people actually wrote in (as opposed to intermediates used 99% of the time inside the machinery of compilers) that exposed up specific-but-widely-available machine features as extensions?

Where I'm going with this is for instance clearing a condition code in a status register.  Most machines with a status register give you a means to either directly interact with it (e.g. 68k ccr) or use individual operations to twiddle the bits (e.g. 6502 sec/clc).  Say I wanted, for whatever reason, in a language higher than assembly, have the ability to clear the CPUs idea of a carry bit.  Yeah, not every CPU may have an accessible representation of carry, so doing this in a language would certainly reduce the portability, but theoretically could be abstracted just enough to allow one single "clear carry" abstract operation to map to and'ing the right bitmask on 68k, running a clc on a 6502, and so on.  Granted, in C and other languages, this is usually achieved with inline assembly or callouts to some sort of assembly machdep type file, but what I'm wondering is if any language used predominantly by human programmers has ever tried to offer these sorts of things as first-class abstractions.

The same could be said about privilege-related things, such as providing in the language an abstract concept of exception/interrupt handling that steps between privilege levels.  Yeah, different CPUs may do that sort of thing quite differently, but if the preponderance of machines you're targeting with some bit of code implement a two-tier supervisor/user privilege model, being able to "write-once-run-anywhere" for this two-level model without knowing the particulars of the CPU's specific privilege escalation/deescalation mechanism could be helpful.

I do concede though that most folks working at that level *do* want to intimately provide their own machine-language handlers for that sort of thing for efficiency reasons, but if even just for prototyping, I could see a rough abstraction of things like status bit changes and interrupt/exception interaction being helpful at times.

- Matt G.