10 Mar
2016
10 Mar
'16
3:34 a.m.
According to Ken, the inspiration for ++ and -- came
from the PDP-7 hardware, not from previous languages.
The PDP-7 supported only ++i, where i had to be one
of only a few memory addresses. "For symmetry", Ken
says, he put all four operations in B. (And he did
not use the hardware autoincrement.)
Doug
10 Mar
10 Mar
3:43 a.m.
New subject: Documentation on B language?
Doug McIlroy scripsit:
According to Ken, the inspiration for ++ and -- came
from the PDP-7
hardware, not from previous languages. The PDP-7 supported only ++i,
where i had to be one of only a few memory addresses. "For symmetry",
Ken says, he put all four operations in B. (And he did not use the
hardware autoincrement.)
On the 12-bit PDP-8, the relevant addresses were 0010-0017; any indirect
reference through any such location was automatically preincremented.
However, they were hard to use in libraries, because allocation of this
incredibly scarce resource had to be manually managed, which meant in
effect that only the main program could use any of them, and because
PDP-8 programmers weren't in the habit of using them, they often were
simply ignored. It was easy enough to add an extra ISZ (increment and
skip if zero) operation before the indirection.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
Wer es in kleinen Dingen mit der Wahrheit nicht ernst nimmt, dem kann
man auch in grossen Dingen nicht vertrauen. --Albert Einstein on honesty
11 Mar
11 Mar
12:09 a.m.
New subject: Documentation on B language?
From the standpoint of a compiler writer, the increment
operators (and
later, similar operators like &=) were surprisingly painful, on
two
levels.
The first problem is that there were lots of nasty interactions between
these operators and function calls. Consider gems like:
f( ++i, ++i );
f( ++i, i++ );
f( i++, ++i );
f( i++, i++ );
The "natural" behavior depended critically on whether the stack grew
upwards or downwards. Add to this the delights that arose if i was an
external variable that was also referenced (or changed) within f. This
may seem like an unlikely event, but it happened all time when the macro
implementation of getchar was introduced.
The second problem was that most victims of the above had a lot of
difficulty, at least the first time, in understanding what the bug was and
tracking it down... And many considered the behavior they saw a compiler
bug (no mater what the documentation and/or the Standard said about
"undefined")...
3208
days inactive
3209
days old
2 comments
3 participants
participants (3)
-
Doug McIlroy -
John Cowan -
scj＠yaccman.com