9 Jul
2024
9 Jul
'24
5:18 a.m.
On Monday, July 8th, 2024 at 3:14 PM, Paul Winalski <paul.winalski(a)gmail.com>
wrote:
[redirecting this to COFF]
On Mon, Jul 8, 2024 at 5:40 PM Aron Insinga <aki(a)insinga.com> wrote:
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.
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.