27 Oct
2014
27 Oct
'14
10:32 a.m.
has anyone ever tried to compile any of the old C compilers with a 'modern'
C compiler?
I tried a few from the 80's (Microsoft/Borland) and there is a bunch of
weird stuff where integers suddenly become structs, structures reference
fields that aren't in that struct,
c01.c
register int t1;
....
t1->type = UNSIGN;
And my favorite which is closing a bunch of file handles for the heck of it,
and redirecting stdin/out/err from within the program instead of just
opening the file and using fread/fwrite..
c00.c
if (freopen(argv[2], "w", stdout)==NULL ||
(sbufp=fopen(argv[3],"w"))==NULL)
How did any of this compile? How did this stuff run without clobbering
each-other?
I don't know why but I started to look at this stuff with some half hearted
attempt at getting Apout running on Windows. Naturally there is no fork, so
when a child process dies, the whole thing crashes out. I guess I could
simulate a fork with threads and containing all the cpu variables to a
structure for each thread, but that sounds like a lot of work for a limited
audience.
But there really is some weird stuff in v7's c compiler.
27 Oct
27 Oct
1:03 p.m.
Early C allowed you to use the '->' operator with any scaler. See early C
reference manuals. This is the reason there is one operator to access a member of a
structure using a pointer and another, '.', to access a member in a static
structure. The B language had no types, everything was a word, and dmr evolved C from B.
At first it made sense to use the '->' operator to mean add a constant to
whatever is on the left and use as an l-value.
You will also find that member names share a single name space. The simple symbol table
had an bit in each entry to delineate members from normal variables. You could only use
the same member name in two different structs if the members had the same offsets. In
other words, it was legal to add a member name to the symbol table that was already there
if the value of the symbol was the same as the existing entry.
Dennis' compilers kept some backward compatibility even after the language evolved
away from them.
This really shows the value of evolving software instead of thinking one has all the
answers going into development. If one follows the development of C one sees the insights
learned as they went. The study of these early Unix systems have a great deal to teach
that will be valuable in the post Moore's law age. Much of the worlds software will
need to a re-evolution.
By the way, did you notice the compiler overwrites itself? We used to have to work in
tiny spaces. Four megabytes was four million dollars.
Sent from my iPad
On Oct 27, 2014, at 6:42 AM, Jason Stevens
<jsteve(a)superglobalmegacorp.com> wrote:
has anyone ever tried to compile any of the old C compilers with a 'modern'
C compiler?
I tried a few from the 80's (Microsoft/Borland) and there is a bunch of
weird stuff where integers suddenly become structs, structures reference
fields that aren't in that struct,
c01.c
register int t1;
....
t1->type = UNSIGN;
And my favorite which is closing a bunch of file handles for the heck of it,
and redirecting stdin/out/err from within the program instead of just
opening the file and using fread/fwrite..
c00.c
if (freopen(argv[2], "w", stdout)==NULL ||
(sbufp=fopen(argv[3],"w"))==NULL)
How did any of this compile? How did this stuff run without clobbering
each-other?
I don't know why but I started to look at this stuff with some half hearted
attempt at getting Apout running on Windows. Naturally there is no fork, so
when a child process dies, the whole thing crashes out. I guess I could
simulate a fork with threads and containing all the cpu variables to a
structure for each thread, but that sounds like a lot of work for a limited
audience.
But there really is some weird stuff in v7's c compiler.
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
1:34 p.m.
Yep, the kernel was littered with funky memory constants using -> to point at various
registers. Probably the most ubuiqtous was
#define PS 0177776
struct {
int integ;
};
yielding the PS->integ access to the Processor Status Register.
1:40 p.m.
On Mon, Oct 27, 2014, at 09:34, Ronald Natalie wrote:
Yep, the kernel was littered with funky memory
constants using -> to
point at various registers. Probably the most ubuiqtous was
#define PS 0177776
struct {
int integ;
};
yielding the PS->integ access to the Processor Status Register.
Is there any reason this is superior to *(int *)0177776 [and e.g.
#define integ(x) (*(int *)(x))]? Did casting not exist back then?
2:04 p.m.
Cast became part of Typesetter C IIRC - so V6 and before does not support
casting and a number of other "modern" C features.
Again you need to think about the time. C, BLISS, PL/360 et al were being
developed to replace writing in raw assembler. So supporting assembler
style idioms that allowed you to get the raw addresses like PS or specific
registers were natural and also remember the optimizers are still in their
infancy.
i.e.
while (SOME_HW_REG_BASE_ADDR->some_sub-register&SOME_MASK) {
... do something/spin etc .. ...
}
would be a two assembler instruction loop and a natural type of thing a
programmer we want to do,
The idea of things like "const" etc we use today - just did yet exist
As side note from those times, the BLISS compiler's optimizer (which was
much more sophisticated than the C compilers) got so good that idioms that
test constants like that were removed as . So Wulf created "code
comments" (aka today's PRAGMAs) to inform the compiler that the writer of
the code knew what they were doing and to "just do it." If you look at CMU
kernel code from things like Hydra and other kernels of time - you will see
a the code comment: "BOH" - meaning "Buzz Off Hobbes" - the nasty shot
at
my friend Steve Hobbes. Bill student, who did much of the BLISS optimizer.
On Mon, Oct 27, 2014 at 9:40 AM, <random832(a)fastmail.us> wrote:
On Mon, Oct 27, 2014, at 09:34, Ronald Natalie wrote:
Yep, the kernel was littered with funky memory
constants using -> to
point at various registers. Probably the most ubuiqtous was
#define PS 0177776
struct {
int integ;
};
yielding the PS->integ access to the Processor Status Register.
Is there any reason this is superior to *(int *)0177776 [and e.g.
#define integ(x) (*(int *)(x))]? Did casting not exist back then?
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
3:04 p.m.
On Mon, 27 Oct 2014, random832(a)fastmail.us wrote:
Is there any reason this is superior to *(int
*)0177776 [and e.g.
#define integ(x) (*(int *)(x))]? Did casting not exist back then?
Type casts? In a compiler/linker that supported e.g.:
int abort 4;
...
abort();
Thou jests...
--
Dave Horsfall (VK2KFU) "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)
5:09 p.m.
Casts were invented as part of the port of Unix to the 32-bit Interdata.
The early Unix system manuals actually printed the structure declarations
for things like directory inodes in the manual -- there were no header
files. This meant a massive amount of work when we wanted to use
different structures for the 32-bit system. To make matters worse, many
system calls returned -1 as an error indication, and on the Interdata
loading an integer from location -1 gave an unrecoverable machine fault
(!). As a final blow, the lack of type checking between pointers and
structure members made it very hard to catch old code at compile time.
The cast syntax, arguably one of the ickiest parts of C syntax, was
invented in desperation -- we needed the feature, and there was no good
syntax proposal. I blush to admit that the one Dennis chose is one that I
suggested, largely because (unlike some of the others) it was easy to
implement in Yacc.
We hacked a version of Lint to force structures whose physical declaration
locations were different to appear to be different structures, even if
they were identical. Then, as header files were introduced, we could find
all the user-level structure declarations that were copied from the man
pages and fix them. This was extremely valuable, and allowed a summer
intern from Princeton to convert most of the user-level programs to V7 in
a summer.
As an aside, one of the hairiest pieces of code I ever wrote was the part
of PCC that handled structure declarations--it had to understand the "old
style anything goes" syntax, but if the compiler decided that there was
some attempt to use the new semantics, it changed modes and retroactively
complained about possible type mismatches. The code was festooned with
assertions, most of which were very short (memory being precious) -- one
or two words like "junk" or "garbage". When compiling the V7 file
system,
Ken managed to totally confound my code by declaring a structure that had
an array whose dimension was computed using a sizeof of another structure
declared inside of the sizeof. He came to me one afternoon with a strange
expression on his face and asked "Hey Steve, what is a gummy
structure?"...
8:35 p.m.
The original UNIX system calls returned error by setting the CARRY ("C") bit on
the PSW.
It was the little wrapper to make them C callable that mapped that to -1. Yes, there was
much cleanup going to
Version 7 to get rid of using -1 with pointers in lieu of the null pointer. The
original argv list was terminated with a -1
as well.
Not that loading from *(int*) 0 was ever a good idea. On the PDP-11, you got
garbage...specifically the first few instructions of the program,
the first of which was "setd" and if you did "printf("%s\n", 0),
you got something like "p&P6" printed out.
Some idiot decided in the split I/D mode (and later on the VAX) to put a ZERO at location
zero. This led to a lot more sloppy coding.
We moved to the Gould SEL machines and like your machine, the default was to get a trap on
*(int*)0 as there was nothing mapped there.
We subsequently added a flag to the a.out format that changed this behavior (called
"braindamaged vax compatibility mode") to map a zero
at zero for the few programs we only had in binary form and we couldn't fix their
errant behavior.
The cast syntax, arguably one of the ickiest parts of C syntax, was
invented in desperation -- we needed the feature, and there was no good
syntax proposal. I blush to admit that the one Dennis chose is one that I
suggested, largely because (unlike some of the others) it was easy to
implement in Yacc.
Yep, the problem was that the book said that a cast was to perform the same operation as
assigning a value to an
invented temporary of the cast type. This of course, didn't fully explain it in the
case of some cast behavior. C++
had to devolve the C cast into FIVE different kinds of cast to make it sane.
9:34 p.m.
below
On Mon, Oct 27, 2014 at 4:35 PM, Ronald Natalie <ron(a)ronnatalie.com> wrote:
The original UNIX system calls returned error by
setting the CARRY ("C")
bit on the PSW.
I've forgotten that factoid. I remember running into issues with it
because the CMU 11/40E had special CSV/CRET
microcode which we could not use on the 11/34. I've forgotten all the
hacks we had associated with the system calls.
I do remember, when we moved the CS systems' to EE 11/34 have to unwind a
whole ton of that. When tjk brought a UNIX/TS based kernel from MH to us
we had reintegrate. I've forgotten all the details now, I just remember
many, many hours cleaning things up
Some idiot decided in the split I/D mode (and later on the VAX) to put a
ZERO at location zero. This led to a lot more sloppy coding.
When we did Magix for the the Tek Magonlia, we cheated and put zeros
there. But as got smarter and better (like Masscomp and Stellar), we have
two versions of the C runtime - "production mode" and "development
mode."
In one, we made sure there was a RO page of zeros @ location 0, so we
could take the traps and try to clean things up. If I recall correctly,
Bourne Shell and ADB were two of the worst offenders. I also seem to
remember the original V7 library code was riddled with those bugs ( in
particular I seem to remember that malloc/free code), which is why it was
such a problem - you own code could be clean, but you brought in a library
and got in trouble.
The other things for those days, that has not yet been brought up was the
famous "NUXI" problem. The PDP-11 byte swapping was idemic in the code.
When the first ports to system that were not the same "endianess" came
about - you would find strange things in memory.
Clem
Clem
The cast syntax, arguably one of the ickiest parts of C syntax, was
invented in desperation -- we needed the feature, and there was no good
syntax proposal. I blush to admit that the one Dennis chose is one that
I
suggested, largely because (unlike some of the
others) it was easy to
implement in Yacc.
Yep, the problem was that the book said that a cast was to perform the
same operation as assigning a value to an
invented temporary of the cast type. This of course, didn't fully
explain it in the case of some cast behavior. C++
had to devolve the C cast into FIVE different kinds of cast to make it
sane.
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
28 Oct
28 Oct
1:09 a.m.
On Mon, 27 Oct 2014, Clem Cole wrote:
[...] because the CMU 11/40E had special CSV/CRET
microcode which we
could not use on the 11/34.
The 40E had microcode whilst the vanilla 40 didn't? I thought only the 60
was micro-programmable; I never did get around to implementing CSV/CRET on
our 60 (Digital had a bunch of them when a contract with a publishing
house fell through).
The other things for those days, that has not yet been
brought up was
the famous "NUXI" problem. The PDP-11 byte swapping was idemic in the
code. When the first ports to system that were not the same
"endianess" came about - you would find strange things in memory.
Reminds me of the time when I used 2-char constants in case statements; my
boss yelled at me.
--
Dave Horsfall (VK2KFU) "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)
2:06 a.m.
yes: http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=comp…
I had a 60 running v7 years later. we also toyed with adding CSV/CRET but never did it
because we got an 11/70
On Oct 27, 2014, at 9:09 PM, Dave Horsfall
<dave(a)horsfall.org> wrote:
On Mon, 27 Oct 2014, Clem Cole wrote:
[...] because the CMU 11/40E had special CSV/CRET microcode which we
could not use on the 11/34.
The 40E had microcode whilst the vanilla 40 didn't? I thought only the 60
was micro-programmable; I never did get around to implementing CSV/CRET on
our 60 (Digital had a bunch of them when a contract with a publishing
house fell through).
The other things for those days, that has not yet
been brought up was
the famous "NUXI" problem. The PDP-11 byte swapping was idemic in the
code. When the first ports to system that were not the same
"endianess" came about - you would find strange things in memory.
Reminds me of the time when I used 2-char constants in case statements; my
boss yelled at me.
--
Dave Horsfall (VK2KFU) "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
12:22 p.m.
On Oct 27, 2014, at 10:06 PM, Clem Cole
<clemc(a)ccc.com> wrote:
yes: http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=comp…
<http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci>
I had a 60 running v7 years later. we also toyed with adding CSV/CRET but never did it
because we got an 11/70
Problem with the 60 was it lacked Split I/D (as did the 40's). We kind of relied
on that for the kernels towards the end of the PDP-11 days,
We struggled with the lack of I/D on the 11/34 and 11/23 at BRL but finally gave up when
TCP came along. We just didn't have enough segments to handle all the overlaying
needed to do. I recycled all the non split-I/D machines into BRL GATEWAYS.
Of course, there was the famous (or imfamous) MARK instruction. This thing was sort of a
kludge, you actually pushed the instruction on the stack and then did the RTS into the
stack to execute the MARK to pop the stack and jump back to the caller. I know of no
compiler (either DEC-written or UNIX) that used the silly thing. It obviously
wouldn't work in split I/D mode anyhow. Years later while sitting in some DEC
product announcement presentation, they announced the new T-11 chip (the single chip
PDP-11) and the speaker said that it supported the entire instruction set with the
exception of MARK. Me and one other PDP-11 trivia guy are going "What? No mark
instruction?" in the back of the room.
12:42 p.m.
On Tue, Oct 28, 2014 at 8:22 AM, Ronald Natalie <ron(a)ronnatalie.com> wrote:
Problem with the 60 was it lacked Split I/D (as did
the 40's).
A problem was that it was 40 class processor and as you says that means it
was shared I/D (i.e. pure 16 bits) - so it lacked the 45 class 17th bit.
The 60 has went into history as the machine that went from product to
"traditional products" faster than any other DEC product (IIRC 9 months).
I'm always surprised to hear of folks that had them because so few were
actually made.
I've forgotten the details nows, but they also had some issues when running
UNIX. Steve Glaser and I chased those for a long time. The 60 had the HCM
instruction sequences (halt a confuse microcode) which were some what
random although UNIX seemed to hit them. DEC envisioned it as a commercial
machine and added decimal arithmetic to it for RSTS Cobol. I'm not sure
RSX was even supported on it.
Clem
1:03 p.m.
I've forgotten the details nows, but they also had some issues when running UNIX.
Steve Glaser and I chased those for a long time. The 60 had the HCM instruction sequences
(halt a confuse microcode) which were some what random although UNIX seemed to hit them.
DEC envisioned it as a commercial machine and added decimal arithmetic to it for RSTS
Cobol. I'm not sure RSX was even supported on it.
Ah, RSTS...the Really Sh-ty Timesharing System. An amusing UNIX story on that one.
Hopkins EE department was a RSTS shop running primarily the Basic Plus interpreter which
was the core of some classroom courses (especially the Freshman course: Modeling and
Simulation). When the the guys found out about UNIX they lobbied the department faculty
to switch to UNIX and they were told they could provided that Basic Plus continued to
run.
Amusingly, if you read the DEC processor handbook, it says the TRAP instruction is
designed to invoke system calls. UNIX did this of course. Amuslingly, the DEC
operating systems, including RSTS, used EMT to invoke system calls. The book says this
was put there to allow emulating other OSs. Well this made it relatively easy.
Basic Plus was calling EMT so they just had to catch the EMT traps and emulate the few
RSTS calls that Basic Plus needed to make. JHU/UNIX was born. It was a Version 6 UNIX
(which original system administrator John Day decided that 6.06 was a great version number
and he kept it through many software updates). Mike took over and stared advancing the
numbers again.
We also had an 11/40 (lacking memory management) running miniUnix. They also ran
miniUNIX in the Biomedical engineering lab on an LSI-11/03. I upgraded that lab to
11/23 running full up UNIX later on.
You may recall that the UID was stored in a (unsigned) char in those days. This was
problematic when you had a student body of a couple of thousand. The solution was a
kludge: "JHU Ownership." If your GID was over 200, both your UID and GID
were considered when computing identity. Obviously, newgrp was disabled for those
accounts and I spent many an hour trying various combinations of setuid/gid bits and
setuid/gid calls to see if there were any way to abuse that.
10:02 p.m.
Ronald Natalie scripsit:
Amusingly, if you read the DEC processor handbook, it
says the TRAP
instruction is designed to invoke system calls. UNIX did this
of course. Amuslingly, the DEC operating systems, including RSTS,
used EMT to invoke system calls. The book says this was put there
to allow emulating other OSs. Well this made it relatively easy.
Unless I have utterly forgotten, EMT was to be used by DEC and TRAP
by users. Since Bell Labs was a user, they used TRAP (I asked ken --
I think it was ken, definitely not Ken -- about this). Of course,
DEC didn't anticipate that any user would write an operating system!
On RSTS/E as opposed to RSTS, both EMT and TRAP went to the user
executive. To reach the kernel, you did EMT 377 followed by another
EMT, but EMT 377; EMT 377 was vectored back to the user as an EMT 377.
That's what allowed RSTS/E to host other OSes that used EMT.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
Nobody expects the RESTifarian Inquisition! Our chief weapon is
surprise ... surprise and tedium ... tedium and surprise ....
Our two weapons are tedium and surprise ... and ruthless disregard
for unpleasant facts.... Our three weapons are tedium, surprise, and
ruthless disregard ... and an almost fanatical devotion to Roy Fielding....
3467
days inactive
3468
days old
14 comments
8 participants
participants (8)
-
Brantley Coile -
Clem Cole -
Dave Horsfall -
Jason Stevens -
John Cowan -
random832＠fastmail.us -
Ronald Natalie -
scj＠yaccman.com