As a followup to discussions on this thread about hardware
architectures, some of you may be interested in this new letter
published today:
Letters to the editor: Hennessy and Patterson on the roots of RISC
Comm. ACM 61(10) 6 (2018)
https://doi.org/10.1145/3273019http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf
The short two-paragraph letter is from Fred Brooks, noted computer
architect, author, and computer scientist.
-------------------------------------------------------------------------------
- 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(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
> From: Dan Cross
> particular in sites with lots of users like universities and
> production-focused corporate groups
The existence of /usr, /usr/bin, /etc, /lib, etc dates back to the Research
group at Bell, so I don't think we can look to these other environments for an
explanation.
> "Hmm. Well, we've got space in /usr: create /usr/bin
I seem to recall reading (don't recall where, OTTOMY) an explanation for the
creation of /usr/bin, and I think it was performance related; IIRC the issue
was that they wanted to keep the directory size down (both for disk block
caching, and search time, reasons). Or maybe that was later on, and it was
originally created for 'user-maintained' ancillary programs (another vague
memory)?
> The more intriguing possibility from the antiquarian point of view is
> whether someone coined "/home" and then THAT led to the rise of the "home
> directory" nomenclature.
My memory is that the term "home directory" predates /home - perhaps on other
OS's such as TOPS-20, but I don't have time to research that. (I did look
quickly in the Multics docs, and it has 'working directory', i.e. current dir
- but it refers to the home dir as 'original WD', i.e. the WD at the time of
login.)
Noel
> From: Jon Forrest
> Another reason why the home directory part of /usr was made into /home
> is because after doing so, it was possible to mount /usr read-only, and
> supply it from a server.
The real issue is that /usr contained stuff which wasn't true 'user data' -
e.g. /usr/bin. The reasons for that must have seemed good at the time it
started, but it was IMO a mistake. (Disgression about partitions, physical
packs, etc elided for now.)
Noel
> Did the 5150 have a UNIX available anywhere near its launch date? I know
> that it had DOS, CP/M-86, and the UCSD p-System relatively early on. It's
> not clear to me whether Xenix ever supported the original PC; were there
> other early porting efforts?
The first version of Venix-86 ran on the PC/XT, almost a 5150, in May 83. It was V7 based. I think it was the first Unix on a PC.
Heinz Lycklama (who did Unix LSX and MX at Bell labs in the 70’s) did PC/IX about a year later, based on Sys III. This was marketed by IBM.
Based on the early Xenix porting chart here http://seefigure1.com/2014/04/15/xenixtime.html , a PC/XT version of Xenix appeared around the same time as PC/IX. However, if the chart is correct there may have been Xenix versions for other 8086-based machines a year before that. Note that in this chart the “Xenix 2.0” and “Xenix 3.0” labels refer to MS internal versions, i.e. these numbers are not to be confused with the marketing labels IBM PC Xenix 2.0 and 3.0.
These versions are a hole in the TUHS archive (unless they are in the confidential archive). It would be wonderful if MS would open up pre-1984 Xenix on the occasion of Unix 50th. These builds would well illustrate the broad Unix portability, which was unique at the time.
Paul
> From: Arthur Krewat
> Also, granted, to this day you can still use only 8-bits of a register:
Yeah, but that's not totally useless; lots of byte-organized data out there in
the world, e.g. ASCII strings. 16-bit data, less so, although there is some in
networking protocols (checksums, ports, etc - although the checksums you
_compute_ using bigger chunks).
(Not a defense of the x86 instruction set, mind!)
Noel
Its register windows have spilled out into the SCRAP heap of history.
But to its credit, the SPARCSTATION represents PANTISOCRACY with NO RACIST PAST.
It ROASTS CATNIP for SATANIC SPORT with no PARTISAN COST.
It can create a CAT SOPRANIST with a CASTRATO SNIP.
-Don
Should have copied the list...
-----Original Message-----
From: William Pechter <pechter(a)gmail.com>
To: Henry Bent <henry.r.bent(a)gmail.com>
Sent: Wed, 26 Sep 2018 11:59
Subject: Re: [TUHS] SPARC is CRAPS spelled backwards.
There was Xenix-86 which ran on the AT&T 6300, and IBM PC/XT. I ran it on an 8MHz NEC V30 cpu on the 6300. I would love to install it on my Panasonic Sr. Partner but lost the install key.
-----Original Message-----
From: Henry Bent <henry.r.bent(a)gmail.com>
To: TUHS main list <tuhs(a)minnie.tuhs.org>
Sent: Wed, 26 Sep 2018 11:45
Subject: Re: [TUHS] SPARC is CRAPS spelled backwards.
On Wed, 26 Sep 2018 at 02:21, Peter Jeremy <peter(a)rulingia.com> wrote:
>
> An 8-bit memory bus means half as many RAM chips and buffers. Keep in mind
> that the IBM 5150 was intentionally crippled to ensure it didn't compete
> with
> IBM's low-end minis.
>
Did the 5150 have a UNIX available anywhere near its launch date? I know
that it had DOS, CP/M-86, and the UCSD p-System relatively early on. It's
not clear to me whether Xenix ever supported the original PC; were there
other early porting efforts?
-Henry
> From: Tony Finch
> This paper has a nice survey of instruction set densities
And the winner is.... the PDP-11!
I'm not too surprised by this; back in the days of core memory (and limited,
at that - the first PDP-11's came standard with ... 8KB of memory :-), having
the denset possible code had real savings.
Noel
> From: Paul Winalski
> In general, a CISC instruction set encoding can express the same
> algorithm more compactly than a RISC instruction set.
I have often pointed to memory bandwidth as one of the key factors in the
evolution of CISC and RISC. When it was low, compared to CPU speeds (most of
the core era), CISC made sense. When it increased (with DRAM), RISC made more
sense, because it allowed CPUs to run faster (via simpler instructions).
Caching made the picture a little more complex; and today, with the incredible
mismatch between memory speeds and CPU speeds, caching dominates, whether you
have RISC or CISC.
Noel
