29 Apr
2016
29 Apr
'16
10:19 a.m.
From: Diane Bruce
PL/M wasn't bad either.
I forgot about PL/M...
Telephone companies preferred deterministic behaviour
from their code
and operating systems.
Not just telco's. Many (most?) people doing stand-alone applications want
this, or something close to it.
There are many warts in C I would remove if I had the
power to. ;)
Eh, don't we all.
My favourite peeve: in cloning BCPL, they left out 'valof/resultis'. That
made certain kinds of macros really, really ugly...
C is a high level PDP-11 assembler to this day. (auto
increment and
decrement)
This myth persists, but it's wrong. B (the typeless predecessor to C) on the
PDP-7 had them, before the PDP-11 existed, as DMR attests:
People often guess that they were created to use the auto-increment and
auto-decrement address modes provided by the DEC PDP-11 on which C and Unix
first became popular. This is historically impossible, since there was no
PDP-11 when B was developed.
The document that's excerted from:
http://www.bell-labs.com/usr/dmr/www/chist.html
might be of interest here, since it contains a section ("Whence Success?")
containing his take on why C was a success (e.g. "it evidently satisfied a
need for a system implementation language efficient enough to displace
assembly language, yet sufficiently abstract and fluent to describe
algorithms and interactions in a wide variety of environments").
Noel
29 Apr
29 Apr
11:05 a.m.
C is a high
level PDP-11 assembler to this day. (auto increment and
decrement)
This myth persists, but it's wrong [...] as DMR attests: [...]
9 May
9 May
8:42 p.m.
Mouse wrote:
Note that PDP-11 autoincrement and autodecrement exist
only when
operating on pointers that are being indirected through, and even then
only when the pointers are in registers. C ++ and -- work fine on
things other than pointers, and on pointers when not indirecting
through them.
Maybe users of C and C++ don't bother, but those user who write
in assembler for the PDP-11 will often take advantage of the ability
of the autoincrement (and on rare occasions the autodecrement)
properties of the instructions set to add (and rarely subtract) 2 and
sometimes 4 within a given register:
TST (R3)+
CMP (R3)+,(R3)+
CMP (R2)+,(R3)+
rather than
ADD #2,R3
ADD #4,R3
ADD #2,R2 / ADD #2,R3
Naturally, the original value MUST be even and the original value
in R3 can't be the address of an area in the IOPAGE which could
then result in an address exception. These opportunities occur
more often that would be expected and many users took advantage
of a tiny reduction in the size of a program, especially in the early
days when core storage was severely limited.
Jerome Fine
29 Apr
29 Apr
1:03 p.m.
On Fri, Apr 29, 2016 at 01:19:34PM -0400, Noel Chiappa wrote:
;)
Indeed.
;)
Yes I knew this. ;) Pity they didn't get it right the first time.
I've had to fix some crufty old code in my time.
Still adding char to C I'd consider a PDP-11'ism.
From: Diane
Bruce
PL/M wasn't bad either.
I forgot about PL/M... Telephone companies preferred deterministic
behaviour from their code
and operating systems.
Not just telco's. Many (most?) people doing stand-alone applications want
this, or something close to it. There are many warts in C I would remove if I had
the power to. ;)
Eh, don't we all.
My favourite peeve: in cloning BCPL, they left out 'valof/resultis'. That
made certain kinds of macros really, really ugly...
Yep.
C is a high level PDP-11 assembler to this day.
(auto increment and
decrement)
This myth persists, but it's wrong. B (the typeless predecessor to C) on the
PDP-7 had them, before the PDP-11 existed, as DMR attests:
People often guess that they were created to use the auto-increment and
auto-decrement address modes provided by the DEC PDP-11 on which C and Unix
first became popular. This is historically impossible, since there was no
PDP-11 when B was developed.
The document that's excerted from:
http://www.bell-labs.com/usr/dmr/www/chist.html
might be of interest here, since it contains a section ("Whence Success?")
I've read this many times. ;)
containing his take on why C was a success (e.g.
"it evidently satisfied a
need for a system implementation language efficient enough to displace
assembly language, yet sufficiently abstract and fluent to describe
algorithms and interactions in a wide variety of environments").
I loved that it started out as a Fortran compiler that failed.
"After a rapidly scuttled attempt at Fortran,..."
In that era one had to have a highly optimized Fortran. ;) I remember
people writing text editors in Fortran and I saw one debugger
written in Fortran. It's a good thing it was rapidly scuttled.
Noel
Diane
--
- db at FreeBSD.org db at db.net http://www.db.net/~db
2919
days inactive
2930
days old
3 comments
4 participants
participants (4)
-
db＠db.net -
jhfinedp3k＠compsys.to -
jnc＠mercury.lcs.mit.edu -
mouse＠Rodents-Montreal.ORG