[TUHS] speaking of early C compilers

[TUHS] speaking of early C compilers

[Noel Chiappa]

    > From: Dave Horsfall <dave at horsfall.org>

    > What, as opposed to spelling creat() with an "e"?

Actually, that one never bothered me at all!

I tended to be more annoyed by _extra_ characters; e.g. the fact that 'change
directory' was (in standard V6) "chdir" (as opposed to just plain "cd") I
found far more irritating! Why make that one _five_ characters, when most
common commands are two?! (cc, ld, mv, rm, cp, etc, etc, etc...)

	Noel

[TUHS] speaking of early C compilers

[Dave Horsfall]

On Mon, 27 Oct 2014, Noel Chiappa wrote:

> > What, as opposed to spelling creat() with an "e"?
> 
> Actually, that one never bothered me at all!

It still annoys me, and it lives on in O_CREAT.  Then again, I once got 
annoyed with TBL's use of "center" [sic], and promptly implemented 
"centre" as well.

> I tended to be more annoyed by _extra_ characters; e.g. the fact that 
> 'change directory' was (in standard V6) "chdir" (as opposed to just 
> plain "cd") I found far more irritating! Why make that one _five_ 
> characters, when most common commands are two?! (cc, ld, mv, rm, cp, 
> etc, etc, etc...)

Especially when the syscall itself is chdir().  Perhaps "cd" was used for 
something else at the time?

-- 
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] speaking of early C compilers

[John Cowan]

Dave Horsfall scripsit:

> Especially when the syscall itself is chdir().  Perhaps "cd" was used for 
> something else at the time?

On the other hand, chdir is conceptually compatible with mkdir and rmdir,
both commands and system calls.  I note that MS-DOS and successors allow
md and rd as alternatives.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Andrew Watt on Microsoft:  Never in the field of human computing has so
much been paid by so many to so few! (pace Winston Churchill)

[TUHS] speaking of early C compilers

[John Cowan]

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 at 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....

[TUHS] speaking of early C compilers

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2429 bytes --]

> 
> 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141028/32e7ceb9/attachment.html>

[TUHS] speaking of early C compilers

[Ronald Natalie]

> On Oct 27, 2014, at 9:55 PM, Jason Stevens <jsteve at superglobalmegacorp.com> wrote:
> 
> Wow BSD on a supercomputer!  That sounds pretty cool! 
> 
> http://web.ornl.gov/info/reports/1986/3445600639931.pdf
> 
> From here it mentions it could scale to 16 process execution modules
> (CPU's?) 
> 
> while here http://ftp.arl.mil/mike/comphist/hist.html it mentions 4 PEMs
> which each could run 8 processes.
> 
> It still looks like an amazing machine.

The US Army (notably the Ballistic Research Laboratory) contracted to have this computer built to solve fluid dynamics problems.    Originally, it was going to be an analog computer, then a hybrid, then Burton Smith came up with this idea for a high power multiple-instruction, multiple data stream parallel processor.   The BRL one had four PEMs each could run 8 processes in parallel but it could hardware schedule up to 256 processes.    Each data memory location had in addition to the 64 data bits semaphore bits called the "full/empty bits."   Instructions were such like "STORE AND SET FULL" and "WAIT EMPTY AND LOAD" so the hardware would suspend your thread (called processes in the hardware) until something else twiddled the bit.

Mike Muuss had pretty much ran the JHU EE computer and was my mentor all while I was there.   My junion year he had taken a job at BRL.   I worked for him as a summer intern and then consultant while Bob Jesse and I ran the JHU EE computer our senior years.   I spent a year in the defense industry when Mike said "I've got this great job for you."

Apparently nobody gave any concern to software on the HEP, and of course Mike's answer is "Let's put UNIX on it!"    He'd done this in the past with some graphics systems (11/34 based with vector processors attached) that had been delivered as remotes for the central CDC machine that never worked.    He'd also upgraded the ANTS (University of Illinois ArpaNet Terminal Server) from its dedicated software to UNIX when long leaders came out on the Arpanet making the ANTS incompatible.

Mike, Robert Miles, and I spent weeks out at the Denelcor facility developing our prototype UNIX at night (amusingly sometimes the Denelcor employees would come in and hit enter on their terminals to find our software still running... HEP, TWO, THREE, FOUR... was the login prompt...we were working for the Army after all).
Amusingly our machine was set up in a big room with tape on the floor showing where the building pillar at BRL was located.     You can see that tape in some of the publicity shots around.    Back at BRL there was tape on the floor where the HEP cabinets went around the real building pillar.

First thing Mike did was adapt the portable C compiler to generate code for the thing.    Bob wrote the assembler I believe and me the loader.    I also ported the F77 front end to PCC over (for the benefit of our eventual scientist users of the thing).      Next, I set up UNIX on the PDP-11 front end the thing had.    Mike then wrote the software that worked the "low speed bus" that you used to boot the thing up (more on this later) and the configuration of the switch network that interconnected all the PEMs and memory, etc... for high speed memory access.

Mike did the process scheduling part of the kernel while I delved into the I/O issues (my specialty at the time).    Bob aided by Doug Kingston took care of porting over most of the user mode code.    Once the thing was limping along we came to a startling discovery.   The thing, which had 32 UNIBUSes tied into it's I/O system, could only start about 10 ios a second.   That's not going to work.    I sat down at the Aberdeen Golden Corral steakhouse (our common dinner haunt) with Burton Smith and we designed a new I/O system, literally on napkins.   We built it out of spare parts, a spare memory switch node and I contributed a PDP-11/34 I had laying around for a control processor.    Now instead of feeding I/O to the front end which then talked tot he I/O system unibusses all over the low speed bus (aptly named), The PDP-11/34 running my "Little Operating System" that I used for the BRL Gateways listed to the high speed active switch for data and mirrored it to the slaved unibuses.    Essentially, the PEMs could now run the actual UNIBUS device drivers with just a slight tweak to bounce the CSR's off the PDP-11/34 with what appeared to be just a memory access.

At this point the Army had woken up to the fact that the Air Force had supercomputers and even the Navy had supercomputers, and darn it they needed supercomputers.    As a result of the fact that we were a scientific organization with heavy computer expertise, we were slated to get the first two.   The first being an X-MP which the Army used emergency authority to grab the next one out of production (which I believe was slated to go to Apple).     Meanwhile at BRL we had turned the HEP over to production use but by then it was getting a little long in the tooth speedwise.   Despite being built out of all discrete 10800 ECL chips, the more traditional processors were beating on the door.    Denelcor was well on it's way to going out of business at this point.    The one big job we ran on this was Mike's raytraced movie  "a bullet's eye view of a tank."    The HEP allowed us 60:1 compute time on the RT (Took one minute to make 1 second of movie....which was pretty darned good back then scares me when I watch video games these days).    Shortly after we did that, they shut the thing down and replaced it with the X-MP.

There weren't that many HEPs built.   In addition to ours, the University of Georgia got a 2 PEM one in exchange Georgia was to develop the software for the thing.     Messerschmidt got one, I never heard what they did with it.   The NSA got one on lease I believe and after Denelcor went out of business, I hear they shipped the whole thing back and dumped it on the loading dock of whatever hapless person happened to be occupying the last known address of Denelcor.   I've still got one of the DENELCOR H1000 name plates that were supposed to be affixed to thing but never got installed.

As for the X-MP, some of you may remember the discussions that were gone around 1985 about whether a hacker with a Cray could break the Unix crypt routine.   I put in my proposal and essentially was granted unlimited CPU time on the X-MP to try to vectorize the crypt routine and perform an analysis (I was heavy into computer security by then).   My conclusion was that the Cray vector stuff wasn't well suited to breaking DES...a faster version of the HEP would have been ideal.   Somewhere I do have a picture of me peering out of the center of the X-MP CPU.

One of the last things I did at BRL was sit on the SSB to buy the Cray 2.    I put my signature to a $25 MILLION dollar procurement.   The biggest single year purchase I made in my Reagan years in the government (I had bought several smaller UNIX machines in previous years at around $2MM a piece).

[TUHS] speaking of early C compilers

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

On Tue, Oct 28, 2014 at 8:22 AM, Ronald Natalie <ron at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141028/347d6d63/attachment.html>

[TUHS] speaking of early C compilers

[Ronald Natalie]

> On Oct 27, 2014, at 10:06 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> yes:  http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci <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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141028/bdb6bd24/attachment.html>

[TUHS] speaking of early C compilers

[Clem Cole]

yes:  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 


> On Oct 27, 2014, at 9:09 PM, Dave Horsfall <dave at 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141027/2e8be232/attachment.html>

[TUHS] speaking of early C compilers

[Jason Stevens]

Wow BSD on a supercomputer!  That sounds pretty cool! 

http://web.ornl.gov/info/reports/1986/3445600639931.pdf

From here it mentions it could scale to 16 process execution modules
(CPU's?) 

while here http://ftp.arl.mil/mike/comphist/hist.html it mentions 4 PEMs
which each could run 8 processes.

It still looks like an amazing machine.

-----Original Message-----
From: Ronald Natalie
To: Noel Chiappa
Cc: tuhs at minnie.tuhs.org
Sent: 10/27/14 11:09 PM
Subject: Re: [TUHS] speaking of early C compilers

We thought the kernels got cleaned up a lot by the time we got to the
BSD releases.    We were wrong.
When porting our variant of the 4 BSD to the Denelcor HEP supercomputer
we found a rather amusing failure.

The HEP was a 64 bit word machine but it had partial words of 16 and 32
bits.   The way it handled these was to encode the word size in the
lower bits of the address (since the bottom three weren't used in word
addressing anyhow).    If the bottom three were zero, then it was the
full word.  If it was 2 or 6, it was the left or right half word, and
1,3, 5, and 7 yielded the four quarter words.  (Byte operations used
different instructions so they directly addressed the memory).

Now Mike Muuss who did the C compiler port made sure that all the casts
did the right thing.   If you cast "int *" to "short *" it would tweak
the low order bits to make things work.    However the BSD kernel in
several places did what I call conversion by union:  essentially this:

union carbide {
     char*  c;
     short* s;
     int*     i;
} u;

u.s  = ...some valid short* ...
int* ip = u.i;

Note the compiler has no way of telling that you are storing and
retrieving through different union members and hence the low order bits
ended up reflecting the wrong word size and this led to some flamboyant
failures.     I then spent a week running around the kernel making these
void* and fixing up all the access points to properly cast the accesses
to it.

The other amusing thing was what to call the data types.     Since this
was a word machine, there was a real predisposition to call the 64 bit
sized thing "int" but that meant we needed another typename for the 32
bit thing (since we decided to leave short for the 16 bit integer).
I lobbied hard for "medium" but we ended up using int32.   Of course,
this is long before the C standards ended up reserving the _ prefix for
the implementation.

The afore mentioned fact that all the structure members shared the same
namespace in the original implementation is why the practice of using
letter prefixes on them (like b_flags and b_next etc... rather than just
flags or next) that persisted long after the C compiler got this issue
resolved.

Frankly, I really wish they'd have fixed arrays in C to be properly
functioning types at the same time they fixed structs to be proper types
as well.     Around the time of the typesetter or V7 releases we could
assign and return structs but arrays still had the silly "devolve into
pointers" behavior that persists unto this day and still causes problems
among the newbies.

_______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] speaking of early C compilers

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

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] speaking of early C compilers

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2770 bytes --]

below

On Mon, Oct 27, 2014 at 4:35 PM, Ronald Natalie <ron at 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
c​ould 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141027/b833bad3/attachment.html>

[TUHS] speaking of early C compilers

[Ronald Natalie]

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.

[TUHS] speaking of early C compilers

[Nelson H. F. Beebe]

Norman Wilson writes today:

>> ...
>> -- Dennis, in one of his retrospective papers (possibly that
>> in the 1984 all-UNIX BLTJ issue, but I don't have it handy at
>> the moment) remarked about ch becoming chdir but couldn't
>> remember why that happened.
>> ...

The reference below contains on page 5 this comment by Dennis:

>> (Incidentally, chdir was spelled ch; why this was expanded when we
>>  went to the PDP-11 I don't remember)

@String{pub-PH                  = "Pren{\-}tice-Hall"}
@String{pub-PH:adr              = "Upper Saddle River, NJ 07458, USA"}

@Book{ATT:AUS86-2,
  author =       "AT{\&T}",
  key =          "ATT",
  title =        "{AT}{\&T UNIX} System Readings and Applications",
  volume =       "II",
  publisher =    pub-PH,
  address =      pub-PH:adr,
  pages =        "xii + 324",
  year =         "1986",
  ISBN =         "0-13-939845-7",
  ISBN-13 =      "978-0-13-939845-2",
  LCCN =         "QA76.76.O63 U553 1986",
  bibdate =      "Sat Oct 28 08:25:58 2000",
  bibsource =    "http://www.math.utah.edu/pub/tex/bib/master.bib",
  acknowledgement = ack-nhfb,
  xxnote =       "NB: special form AT{\&T} required to get correct
                 alpha-style labels.",
}

That chapter of that book comes from this paper:

@String{j-ATT-BELL-LAB-TECH-J   = "AT\&T Bell Laboratories Technical Journal"}

@Article{Ritchie:1984:EUT,
  author =       "Dennis M. Ritchie",
  title =        "Evolution of the {UNIX} time-sharing system",
  journal =      j-ATT-BELL-LAB-TECH-J,
  volume =       "63",
  number =       "8 part 2",
  pages =        "1577--1593",
  month =        oct,
  year =         "1984",
  CODEN =        "ABLJER",
  DOI =          "http://dx.doi.org/10.1002/j.1538-7305.1984.tb00054.x"
  ISSN =         "0748-612X",
  ISSN-L =       "0748-612X",
  bibdate =      "Fri Nov 12 09:17:39 2010",
  bibsource =    "Compendex database;
                 http://www.math.utah.edu/pub/tex/bib/bstj1980.bib",
  abstract =     "This paper presents a brief history of the early
                 development of the UNIX operating system. It
                 concentrates on the evolution of the file system, the
                 process-control mechanism, and the idea of pipelined
                 commands. Some attention is paid to social conditions
                 during the development of the system.",
  acknowledgement = ack-nhfb,
  fjournal =     "AT\&T Bell Laboratories Technical Journal",
  topic =        "computer systems programming",
}

Incidentally, on modern systems with tcsh and csh, I use both chdir
and cd; the long form does the bare directory change, whereas the
short form is an alias that also updates the shell prompt string and
the terminal window title.

I also have a personal alias "xd" (eXchange Directory) that is short
for the tcsh & bash sequence "pushd !*; cd .", allowing easy jumping
back and forth between pairs of directories, with updating of prompts
and window titles.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[TUHS] speaking of early C compilers

[scj]

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?"...

[TUHS] speaking of early C compilers

[Dan Cross]

An interesting digression....  A few years ago, the architects of MIT's
6.828 course ("Operating Systems Engineering") were unsatisfied with the
current stable of systems for teaching, so they did a re-implementation of
6th Edition in modern ANSI C (with a couple of GNU extensions for things
like assigning names to registers) targeting a multiprocessor x86.  It's an
interesting, accessible piece of work; a modern take on a classic.
http://pdos.csail.mit.edu/6.828/2014/xv6.html

        - Dan C.

On Mon, Oct 27, 2014 at 10:48 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Jason Stevens
>
>     > has anyone ever tried to compile any of the old C compilers with a
>     > 'modern' C compiler?
>     > ...
>     > How did any of this compile? How did this stuff run without
> clobbering
>     > each-other?
>
> As Ron Natalie said, the early kernels are absolutely littered with all
> sorts
> of stuff that, by today's standards, are totally unacceptable. Using a
> variable declared as an int as a pointer, using a variable declared as a
> 'foo' pointer as a 'bar' pointer, yadda-yadda.
>
> I ran (tripped, actually :-) across several of these while trying to get my
> pipe-splicing code to work. (I used Version 6 since i) I am _totally_
> familiar with it, and ii) it's what I had running.)
>
> For example, I tried to be all nice and modern and declared my pointer
> variables to be the correct type. The problem is that Unix generated unique
> ID's to sleep on with code like "sleep(p+1, PPIPE)", and the value
> generated
> by "p+1" depends on what type "p" is declared as - and if you look in
> pipe.c,
> you'll see it's often declared as an int pointer. So when _I_ wrote
> "sleep((p + 1), PPIPE)", with "p" declared as a "stuct file pointer", I got
> the wrong number.
>
> I can only speculate as to why they wrote code like this. I think part of
> it
> is, as Brantley Coile points out, historical artifacts due to the evolution
> of C from (originally) BCPL. That may have gotten them used to writing code
> in a certain way - I don't know. I also expect the modern mindset (of being
> really strict about types, and formal about coverting data from one to
> another) was still evolving back then - partly because they often didn't
> _have_ the tools (e.g. casts) to do it right. Another possibility is that
> they were using line editors, and maintaining more extensive source is a
> pain
> with an editor like that. Why write "struct file *p" wnen you can just
> write
> "*p"? And of course everyone was so space-concious back then, with those
> tiny
> disks (an RK05 pack is, after all, only 2.5MB - only slightly larger than a
> 3.5" floppy!) every byte counted.
>
>
> I have to say, though, that it's really kind of jarring to read this stuff.
>
> I have so much respect for their overall structure (the way the kernel is
> broken down into sub-systems, and the sub-systems into routines), how they
> managed to get a very powerful (by anyone's standards, even today's) OS
> into
> such a small amount of code... And the _logic_ of any given routine is
> usually quite nice, too: clear and efficient. And I love their commenting
> style - no cluttering up the code with comments unless there's something
> that
> really needs elucidation, just a short header to say, at a high level, what
> the routine does (and sometimes how and why).
>
> So when I see these funky declarations (e.g. "int *p" for something that's
> _only_ going to be used to point to a "struct file"), I just cringe - even
> though I sort of understand (see above) why it's like that. It's probably
> the
> thing I would most change, if I could.
>
>         Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141027/c06fe681/attachment.html>

[TUHS] speaking of early C compilers

[Norman Wilson]

Noel Chiappa:

> I tended to be more annoyed by _extra_ characters; e.g. the fact that 
> 'change directory' was (in standard V6) "chdir" (as opposed to just 
> plain "cd") I found far more irritating! Why make that one _five_ 
> characters, when most common commands are two?! (cc, ld, mv, rm, cp, 
> etc, etc, etc...)

In the earliest systems, e.g. that on the PDP-7, the change-directory
command was just `ch'.

Two vague memories about the change:

-- Dennis, in one of his retrospective papers (possibly that
in the 1984 all-UNIX BLTJ issue, but I don't have it handy at
the moment) remarked about ch becoming chdir but couldn't
remember why that happened.

-- Someone else, possibly Tom Duff, once suggested to me that
in the earliest systems, the working directory was the only
thing that could be changed: no chown, no chmod.  Hence just
ch for chdir.  I don't know offhand whether that's true, but
it makes a good story.

Personally I'd rather have to type chdir and leav off th
trailing e on many other words than creat if it let me off
dealing with pieces of key system infrastructure that insist
on printing colour-change ANSI escape sequences (with, so far
as I can tell, no way to disable them) and give important files
names beginning with - so that grep pattern * produces an error.
But that happens in Linux, not UNIX.

Norman Wilson
Toronto ON

[TUHS] speaking of early C compilers

[Dave Horsfall]

On Mon, 27 Oct 2014, Noel Chiappa wrote:

> So when I see these funky declarations (e.g. "int *p" for something 
> that's _only_ going to be used to point to a "struct file"), I just 
> cringe - even though I sort of understand (see above) why it's like 
> that. It's probably the thing I would most change, if I could.

What, as opposed to spelling creat() with an "e"?

-- 
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] speaking of early C compilers

[Ronald Natalie]

We thought the kernels got cleaned up a lot by the time we got to the BSD releases.    We were wrong.
When porting our variant of the 4 BSD to the Denelcor HEP supercomputer we found a rather amusing failure.

The HEP was a 64 bit word machine but it had partial words of 16 and 32 bits.   The way it handled these was to encode the word size in the lower bits of the address (since the bottom three weren't used in word addressing anyhow).    If the bottom three were zero, then it was the full word.  If it was 2 or 6, it was the left or right half word, and 1,3, 5, and 7 yielded the four quarter words.  (Byte operations used different instructions so they directly addressed the memory).

Now Mike Muuss who did the C compiler port made sure that all the casts did the right thing.   If you cast "int *" to "short *" it would tweak the low order bits to make things work.    However the BSD kernel in several places did what I call conversion by union:  essentially this:

union carbide {
     char*  c;
     short* s;
     int*     i;
} u;

u.s  = ...some valid short* ...
int* ip = u.i;

Note the compiler has no way of telling that you are storing and retrieving through different union members and hence the low order bits ended up reflecting the wrong word size and this led to some flamboyant failures.     I then spent a week running around the kernel making these void* and fixing up all the access points to properly cast the accesses to it.

The other amusing thing was what to call the data types.     Since this was a word machine, there was a real predisposition to call the 64 bit sized thing "int" but that meant we needed another typename for the 32 bit thing (since we decided to leave short for the 16 bit integer).     I lobbied hard for "medium" but we ended up using int32.   Of course, this is long before the C standards ended up reserving the _ prefix for the implementation.

The afore mentioned fact that all the structure members shared the same namespace in the original implementation is why the practice of using letter prefixes on them (like b_flags and b_next etc... rather than just flags or next) that persisted long after the C compiler got this issue resolved.

Frankly, I really wish they'd have fixed arrays in C to be properly functioning types at the same time they fixed structs to be proper types as well.     Around the time of the typesetter or V7 releases we could assign and return structs but arrays still had the silly "devolve into pointers" behavior that persists unto this day and still causes problems among the newbies.

[TUHS] speaking of early C compilers

[Dave Horsfall]

On Mon, 27 Oct 2014, random832 at 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)

[TUHS] speaking of early C compilers

[Noel Chiappa]

    > From: Jason Stevens

    > has anyone ever tried to compile any of the old C compilers with a
    > 'modern' C compiler?
    > ...
    > How did any of this compile? How did this stuff run without clobbering
    > each-other?

As Ron Natalie said, the early kernels are absolutely littered with all sorts
of stuff that, by today's standards, are totally unacceptable. Using a
variable declared as an int as a pointer, using a variable declared as a
'foo' pointer as a 'bar' pointer, yadda-yadda.

I ran (tripped, actually :-) across several of these while trying to get my
pipe-splicing code to work. (I used Version 6 since i) I am _totally_
familiar with it, and ii) it's what I had running.)

For example, I tried to be all nice and modern and declared my pointer
variables to be the correct type. The problem is that Unix generated unique
ID's to sleep on with code like "sleep(p+1, PPIPE)", and the value generated
by "p+1" depends on what type "p" is declared as - and if you look in pipe.c,
you'll see it's often declared as an int pointer. So when _I_ wrote
"sleep((p + 1), PPIPE)", with "p" declared as a "stuct file pointer", I got
the wrong number.

I can only speculate as to why they wrote code like this. I think part of it
is, as Brantley Coile points out, historical artifacts due to the evolution
of C from (originally) BCPL. That may have gotten them used to writing code
in a certain way - I don't know. I also expect the modern mindset (of being
really strict about types, and formal about coverting data from one to
another) was still evolving back then - partly because they often didn't
_have_ the tools (e.g. casts) to do it right. Another possibility is that
they were using line editors, and maintaining more extensive source is a pain
with an editor like that. Why write "struct file *p" wnen you can just write
"*p"? And of course everyone was so space-concious back then, with those tiny
disks (an RK05 pack is, after all, only 2.5MB - only slightly larger than a
3.5" floppy!) every byte counted.


I have to say, though, that it's really kind of jarring to read this stuff.

I have so much respect for their overall structure (the way the kernel is
broken down into sub-systems, and the sub-systems into routines), how they
managed to get a very powerful (by anyone's standards, even today's) OS into
such a small amount of code... And the _logic_ of any given routine is
usually quite nice, too: clear and efficient. And I love their commenting
style - no cluttering up the code with comments unless there's something that
really needs elucidation, just a short header to say, at a high level, what
the routine does (and sometimes how and why).

So when I see these funky declarations (e.g. "int *p" for something that's
_only_ going to be used to point to a "struct file"), I just cringe - even
though I sort of understand (see above) why it's like that. It's probably the
thing I would most change, if I could.

	Noel

[TUHS] speaking of early C compilers

[Clem Cole]

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 at 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141027/c3bdd524/attachment.html>

[TUHS] speaking of early C compilers

[Jason Stevens]

 Thanks for clearing that the whole members out of nowhere thing.

I had thought (ha ha) that since I don't have a working fork, I could just
rebuild CC as a native 
executable, and then just call apout for each stage, but I never realized
how interdependent
they all are, at least C0 to C1.

It's crazy to think of how much this stuff cost once upon a time.  

And now we live in the era of javascript pdp-11's
http://pdp11.aiju.de/

-----Original Message-----
From: Brantley Coile
To: Jason Stevens
Cc: tuhs at minnie.tuhs.org
Sent: 10/27/14 9:03 PM
Subject: Re: [TUHS] speaking of early C compilers

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 at 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] speaking of early C compilers

[Noel Chiappa]

    > From: random832 at fastmail.us

    > Did casting not exist back then?

No, not in the early V6 compiler. It was only added as of the Typesetter
compiler. (I think if you look in those 'Recent C Changes' things I sent in
recently {Oct 17}, you'll find mention of it.)

	Noel

[TUHS] speaking of early C compilers

[random832]

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] speaking of early C compilers

[Ronald Natalie]

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.

[TUHS] speaking of early C compilers

[Brantley Coile]

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 at 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] speaking of early C compilers

[Jason Stevens]

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.