[TUHS] [COFF] SOSP 1973 [was Multics<->Unix Re: Re: History of cal(1)?

[Phillip Harbison via TUHS]

John Levine via TUHS wrote:
> Yup. Until the late 1960s computers had such widely different addressing and
> data architectures that it wouldn't have made sense to try to write portable
> system software. FORTRAN and COBOL programs could be fairly portable, but at a
> much higher level of abstraction than an operating system.
> ...
> The only attempt I know to put Unix on a machine that didn't have 8-bit
 > bytes was the BBN C70 with 10-bit bytes.  One of the programmers told
 > me that finding all the 8-bit assumptions in Unix applications was
 > very painful.

UNIVAC 1100 says hi.
- 36-bit general purpose A(ccumulator) registers.
- 36-bit and 72-bit floating point
- indeX registers split into 18-bit address (because who would ever
   need to address more than 256K words?) and 18-bit auto-increment
- 6-bit characters (Fieldata). ASCII support added later with 9-bit
   characters (not sure how they used thew extra bit)
- octal preferred here ;)

UAH had been a Univac shop since beginning with NASA and US Army
leftovers. This is probably why UAH waited until Sperry remarketed
the Computer Consoles Power 6 (aka Tahoe, not to be confused with
IBM Power 6). I installed UNIX, my homegrown clone of Emacs, and set
up netnews on our first UNIX system (uahcs1). I was not an employee,
just a proud alumnus and friend of the CS department chairman.

Meanwhile I was running Unisoft's port of UNIX System V.0 on my home-
built 68000 box with a mere 1 MB of memory and no demand paging hence
the need for my own mini-clone of Emacs (more like MINCE) that loaded
as fast as vi. It was dubbed "madhat" and was the first public access
netnews host in The Rocket City with a free news feed compliments of
Lindsey Cleveland at AT&T Atlanta Cable Works (akgua) until I migrated
the feed to uahcs1.

I worked on other 68K systems, both UNIX and embedded, but they were
all programmed in C. It was not much of a challenge once you made sure
your homegrown malloc (for embedded) always returned a long-aligned
block of memory. A coworker had tested his malloc on an NS16032 and
was confused when he got Address Error traps. He tried to convince
management that the 68000 was broken. While the MS16032 supported
unaligned access it did so at a huge performance penalty.

Our compiler (Green Hills) took care of other alignment issues as
long as your malloc behaved.

It helped if you used unsigned chars since the 68K MOVE instruction
did not sign-extend and required two instructions (EXT.W and EXT.L)
to extend to 32 bits. The 68010 and later 680x0 family added EXT.B
(extend byte to long word) but if you rolled your own libraries (for
embedded) why not avoid sign extension entirely?

-- 
Phil Harbison