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

Tue May 26 13:27:15 AEST 2026

[taking a break from the humongous reply I'm writing to the "troff.org"
thread]

At 2026-05-25T19:52:01-0700, Adam Thornton via TUHS wrote:
> On Mon, May 25, 2026 at 6:52 PM Larry McVoy via TUHS <tuhs at tuhs.org>
> wrote:
> > I have a son who is more about theory, he's a math guy.  I nudged
> > him towards programming, he of course went to python.  I nudged him
> > towards C and he came back with the best statement ever that I have
> > gotten from him: In C, you can feel the machine.  Yes, Travis, yes
> > you can.  That's part of what makes C great.
> >
> But in this day and age, *can* you?  You can feel the machine if that
> machine is a PDP-11.  But with a modern pipelined SMP architecture,
> with prefetch and speculative execution and all that stuff...I don't
> think any human *can* feel the machine anymore.
> 
> And I kind of mourn that, which is why I do retrocomputing and why my
> heart will always belong to the 6502, but...while C is an accurate
> match for what's going on in a single-processor system without any
> fancy caching, is it really "feeling the machine" anymore?

I agree.  I grew up with the somewhat fancier (read: more complicated)
Z80 and 6809.  It was pretty neat how we could take real-time
programming for granted because the processors were wholly
deterministic.  You could count T-states and you'd be right.  No
pipelines, no caches, no hardware multiplier that took a variable number
of T-states to retire the instruction.

When I started my formal education I was terrified of ever taking an
analysis of algorithms class because I knew the 80386, which I strongly
disliked, was a much more complicated processor than the ones I grew up
on.  I had a gigantic sense of dread because I thought we were going to
be held responsible for predicting on exams the T-state counts the
machine would take to retire a whole C function's worth of instructions.

A EE major gently informed me that that was in fact crazily hard to do
with modern processors, and they didn't behave deterministically anyway,
because caches.  (The 386 was superscalar but most or all of its
successors were, as I recall.)  With misconception dispelled, cyclomatic
complexity and Big-O notation proved to be a huge relief, and the
subject came to more closely resemble the rest of my engineering
education: look first at the lowest-order terms!

Doug pointed out to me in a conversation a while back that early C was
deterministic in the way simple CPUs were.  that.  I then got to point
out that it may well have been...up until the language added structure
copying by assignment.

(Real 8-bit microcomputer grognards will notice that I've fibbed a
little by not mentioning the Z80's LDIR and LDDR instructions and their
counterparts that dealt with I/O ports.  It'd be a fair point, but I
don't remember ever using them in my callow youth.  I might have been
working from examples written for the 8080, which lacked those
instructions.  I don't remember using the alternate register set either,
which seems crazily negligent to me now.)

> Note: I like C.  I like Go even more.  I have not had to use Rust in
> anger yet so I don't really know it.  90% of my day job is Python, and
> the rest is mostly TypeScript.  I'm not arguing this from a Luddite
> perspective, I'm just saying that it has been quite some time since
> "what the processor is actually doing" crossed the "human ability to
> understand it in detail" threshold.  Or at least, *my* human ability.

This seems like a good time for me to flog one of my favorite pieces.

https://spawn-queue.acm.org/doi/10.1145/3212477.3212479

> I'm not often the smartest bear in the room, but I'm usually not the
> dumbest either.

Your observation some time ago about "the secret" being that "no one
reads the literature" is enough to convince me that you seldom open the
office door with the goat behind it.  ;-)

And since someone mentioned Ada, my favorite language that I've never
done real work in...I think that if you took Ada 83 and simply removed
the tasking subsystem from it--not because it's bad but because it added
weight to the language runtime and because its concurrency model is
simply not one the bulk of the industry converged on, even if it was
(AIUI) a better fit for hard real-time and high-assurance
systems--you'd have a language that would compare favorably to Seventh
Edition C and even ANSI C89--except, I think, for line-oriented
teletype-style I/O.  For some reason, the Ada Committee got literally a
bit too precious about the page, and insisted that the output channel
maintain a concept of pagination.  That's a poor fit with Doug's
pipeline paradigm, and adds needless complexity.

But I suspect that even with those modifications, no C programmer in the
1980s would have defected to Ada.

Mysterious sigils good; intelligible variable names bad.

Have a "bflag"ged day!

Regards,
Branden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20260525/3b081109/attachment.sig>