17 Aug
2024
17 Aug
'24
8:19 p.m.
On Aug 17, 2024, at 8:32 AM, Peter Corlett via cctalk
<cctalk(a)classiccmp.org> wrote:
...
Not to mention that K&R had experience with the PDP-7, which is an 18 bit word
oriented machine. And a whole lot of other machines of that era had word lengths
different from 16, and apart from the S/360 and the Nova most weren't powers of two.
The problem is the native register width keeps
changing with every cpu. C
was quick and dirty language for the PDP 11, with 16 bit ints. They never
planned UNIX or C or Hardware would change like it did, so one gets a
patched version of C. That reminds me I use gets and have to get a older
version of C.
They'd have had to be fairly blinkered to not notice the S/360 series which
had been around for years before the PDP-11 came out. It doesn't take a
particularly large crystal ball to realise that computers got smaller and
cheaper over time and features from larger machines such as wider registers
would filter down into minicomputers and microcomputers. But C also seems to ignore a lot of the stuff we
already knew in the 1960s
about how to design languages to avoid programmers making various common
mistakes, so those were quite large blinkers. They've never been taken off
either: when Rob and Ken went to work for Google they came up with a "new"
C-like language which makes many of the same mistakes, plus some new ones,
and it is also more bloated and can't even be used to write bare-metal stuff
which is one of the few things one might reasonably need C for in the first
place.
C, especially its early incarnations, could be called a semi-assembly language. For
example, you can tell that struct declarations originally amounted simply to symbolic
offsets (you could use a field name declared for struct a in operations on types of struct
b). And yes, ALGOL showed the way with a far cleaner design, and ALGOL extensions existed
to do all sorts of hard work with it. Consider the Burroughs 5500 series and their
software, all written in ALGOL or slightly tweaked extensions of same, including the OS.
...
Complex subroutine nesting can be done just fine on a CPU "optimised for"
running C. For example, you can synthesise an anonymous structure to hold
pointers to or copies of the outer variables used in the inner function, and
have the inner function take that as its first parameter. This is perfectly
doable in C itself, but nobody would bother because it's a lot of
error-prone boilerplate. But if the compiler does it automatically, it
suddenly opens up a lot more design options which result in cleaner code.
Absolutely. The first ALGOL compiler was written for the Electrologica X1, a machine with
two accumulators plus one index register, a one address instruction set, and no stack or
complex addressing modes. It worked just fine, it simply meant that you had to do some
things in software that other machines might implement in hardware (or, more likely, in
microcode). Or consider the CDC 6000 mainframes, RISC machines with no stack, no
addressing modes, and not just an ALGOL 60 but even an ALGOL 68 compiler.
On the other hand there was the successor of the X1, the X8, which adds a stack both for
data and subroutine calling, as well as "display" addressing modes to deal
directly with variable references in nested blocks up to 63 deep. Yes, that makes the
generated code from the ALGOL compiler shorter, but it doesn't necessarily make things
any faster and I don't know that such features were ever seen again.
paul