[COFF] [TUHS] Re: Hypothetical: Could MULTICS have been written in C, if available?

[Noel Chiappa via COFF]

{BCC'ing to TUHS, in an attempt to move to COff}

    > From: Steve Jenkin

    > could something like C have improved MULTICS or helped it's success in
    > the marketplace?

The biggest problem of Multics (i.e. the large system of code, as existing and
installed at about 100 sites) was i) (to echo John Levine) that it was tied
very strongly to Honeywell hardware, and ii) Honeywell management were total
bozos, and could/would not produce new, improved, cost-effective hardware.
See here:

  https://multicians.org/hill-mgt.html

and related links (e,g, the Palyn report) for a lot more about that. In
short, Multics' biggest problem(s), in the real world, were not technical, so
technical solutions would not have helped.


The 'tie to Honeywell hardware' existed at two levels.

First, at a high, conceptual level, Multics was (in the eye of a user) a
single-level memory system (_everything_ was an addressable segment), with
hardware support. Now, it's true that any Turing machine could emulate any
other, but the performance may be considerably slower (there's an example
below).

Second, at a low level, the Multics PL/1 code was crammed to the gills with
declarations like:

  dcl global_handle bit(36) aligned static;

with the word length of the machine in the source. (It's true that C has the
opposite prolem - one that's a real issue in writing networking code -
other than bit fields, C declarations don't let you be explicit about
data sizes.)


Multics PL/1 also had extensions (effectively) to support the Multics
high-level conceptual model.

One is that saying 'foo$bar(arg1, arg2)' called entry point 'bar' in segment
'foo'. Clearly, to do something similar in C, one could write:

  long_call("foo", "bar", arg1, arg2);

where 'long_call()' is an assembler routine that 'does the right thing' - but
that will necessarily be considerably slower than the original Multics/PL/1
equialent, which is a single subroutine-call instruction. If one wrote it 
somewhat differently, as:

  subr_pointr = long_get_subr_addr("foo", "bar");
  (*subr_pointr)(arg1, arg2);

then if one only did the call to long_get_subr_addr() once, it would only be
slowish the first time one called foo$bar. (That's the inter-segment code
syntax; I forget how data worked.)


Multics also makes considerable use of conditions (in the 'throw'/'catch'
meaning of that). One _can_ add conditions to C (I did it, for a compiler
with a recursive descent parser I wrote, and I know of another
implementation, using longjmp - mine used assembler versions of
'on()'/'signal()', using standard C subroutine call semantics, along with an
'enhanced' stack frame format [condition handlers stack, so that way I got
free unstacking of handlers on subroutine exit]), but it's not part of
'standard' C.


In short, it wouldn't be simple to use 'stock' C for Multics (for doing the
whole thing, including the OS and system tools, not just applications - the
way it used PL/1).

	Noel