[Info-vax] Dave Cutler Speaks

[John Dallman]

In article <ugtsms$12u2v$3 at dont-email.me>,
clubley at remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> No, Pillar. We have plenty of language choices for higher-level
> programming, but we have what is a monoculture of one language when
> it comes to low-level programming.

/Fairly/ low-level programming. I was obliged to modify some ARM64
assembler source in early October, which does stuff that cannot be
expressed in C. It was something of a special case: test cases for an
error handler, which deliberately set off ARM64 security features, to
ensure that the error handler can recognise and report them correctly.
This required abuse of the calling convention, which you can't write in
portable C. 

> If Pillar had been adopted by DEC for use in production systems, 
> DEC's position in the marketplace at the time would have given the 
> industry a viable option to C.

It would have been an alternative, assuming that DEC did not keep the
language proprietary, but I'm not sure it would have been widely taken up.
I've been reading the Pillar manual from Bitsavers, and it does not come
over as an attractive language to a C programmer. It has many good things,
but some of the bad ones are quite bad.

It's a language specifically designed for 32-bit PRISM, rather than for
portability across a range of architectures. C and UNIX's strengths in
portability go back to the 1970s. After the initial implementation of
UNIX on the 16-bit PDP-11. Bell Labs ported it to the Interdata 8/32,
which had an architecture loosely based on the IBM/360. They picked it
because it was so different from the PDP-11. 

It's Pascal-based, but with something of a PL/1 feel. It looks
cumbersome and complicated; one of C's virtues to those used to it are
that it's pretty terse. There's a lot of compulsory UPPERCASE, and some
dubious choices in the type system:

* WORD is 16 bits and LONGWORD and QUADWORD are based on that. None of 
  these types have defined arithmetic. 
* Fixed sizes for INTEGER, LARGE_INTEGER, REAL and DOUBLE.
* No unsigned integer types that you can do calculations with. 
* Making POINTER the same size as LONGWORD, limiting it to 32 bits. 

That means you can do address calculations in LARGE_INTEGERs, but you
have to convert them back to LONGWORDs and it's more cumbersome than
unsigned 32-bit arithmetic. The language specification would need
revising for a 64-bit machine, and another integer type would be needed
for 64-bit address arithmetic. 

It also has arithmetic exception rules that are hard to implement on some
architectures: "Arithmetic instructions that do not detect overflow will
be generated unless range checking is enabled at compile time," On x86,
the trapping of floating-point overflow is controlled at run-time by
flags in a control register. If those have to be preserved and set each
time a Pillar module is entered, there will be a speed penalty. 

The BOOLEAN handling, in contrast, is perfectly sound. 

There are length-counted strings, but they have weirdnesses, like the
length value stored with them being a /signed/ 16-bit integer: what does
a negative value mean? There are variable-length arrays, but they are
limited to block scope, and there's no associated storage arrangement
AFAICS. Overall, the type system is not well designed for getting the
most out of hardware. 

The BIND and ENVIRONMENT declarations are weird ways of avoiding the use
of pointers, and ENVIRONMENT seems to be meant for event handlers. The
DEFINE declaration acts kind of like a macro, but I'm not sure what it is
meant for. 

The string functions would need re-working for character sets large than
8 bits, but Pillar predates Unicode, so this is not a culpable flaw. 

The pointer operations are weaker than those of C, and under-specified.
They don't specify any kind of scaling for integers added and subtracted
to pointers. In C, for example, adding 1 to a pointer to int increases
the pointer's value by the size of an int. If that isn't meant to exist,
it makes pointers /less/ safe than in C, because it's easy to produce
misaligned ones. 

The rule about modifications to IN-qualified procedure arguments (that
they're errors with unpredictable results, which the compiler cannot
always recognise and report) is just daft in a language that is meant to
be secure. The error is repeated for OUT parameters, where the effect of
assigning to them is dependent on system conventions, spoiling
portability. The parameter passing mechanisms are complicated in general,
and the same code can do different things on different OSes, spoiling
portability. 

Pillar is certainly a better language for writing most of an OS than
Macro-32 or Bliss, but I'm really dubious that it would have competed
effectively with C outside DEC, or that software written in it would be
intrinsically secure. It would likely have different characteristic
security bugs from C, but it would have them. 


An interesting detail in the specification is OZIX, the UNIX subsystem
for PRISM/MICA: 
<https://www.computerhistory.org/collections/catalog/102750715>.


John