[ATARI] Dadhacker: How the Atari ST almost had Real Unix

[Jesus Cea]

http://www.dadhacker.com/blog/?p=1383

Incluyo transcripción en beneficio de los archivos de la lista de
correo. No incluso los comentarios, que también son interesantes.

"""
How the Atari ST almost had Real Unix
Posted on January 17, 2011 by landon	

“Walkies!”

It was 4:00 in the afternoon, and time to walk to the dump, out past the
Sunnyvale sewage plant, and talk about hard problems.

I’ve had some of my best ideas while out walking. I’m 6’4″ with long
legs, and I walk fast. I find when my legs are occupied I can let things
sift through my head and sort of bounce around until they fall into
place. I have to leave the cell phone and music player and other
distractions behind or I won’t get work done. Without distractions, I
just get out there and let the ground travel past my feet, and things
get solved. At least it’s good exercise.

That, or just go out for a walk with cow-orkers and enjoy the day, and
bullshit about stuff.

The latest problem I was working out was how to run Unix on the Atari
ST. The Tramiels had somehow wrangled a license for AT&T’s
SVR-something-or-other version of Unix (might have been SVR3, but this
was in the bad old days when AT&T was actively fucking up Unix, and it
could have been just about any version, including SVR666). The license
was for a mind boggling, nay, jaw-dropping ten bucks a seat. The problem
was that the ST didn’t have any kind of memory management hardware, just
a raw CPU flinging real addresses at naked DRAM, and the machine’s
cheap-ass vanilla 68000 was incapable of recovering from a fault unless
you cheated.

[What’s that about Linux? Dear child, Linus was probably not out of
whatever they use for high school in Finland. All we had in the market
was 4.2bsd running on Vaxen, 68K-based Suns with a ton of hardware to
work around the 68000 limitation re faulting, and a whole running field
of wannabes that would sink without a trace in five years. Oh, and some
screwed up AT&T workstations with monochrome graphics and UIs that
curdled your eyeballs and left you wishing AT&T had simply stuck with
making phones.]

The hardware folks were convinced that grafting an MMU into the ST was
impossible; in theory you could still run something like Unix, but with
no memory protection and no way to easily grow and shrink a process’s
address space a straight-forward port of Unix would be glacial and prone
to crashing really badly. The hardware guys were mostly right; the 68000
wasn’t capable of handling a page fault (it didn’t save enough
information on its exception frames to restart all cases of a faulted
instruction). Motorola didn’t offer an MMU chip anyway (the 68020 didn’t
exist yet, and the sticker shock of its optional external MMU meant that
only Apple folks could afford it, and it was still optional on most Macs
for several years). Furthermore, the memory system of the ST wouldn’t
tolerate the delays that a traditional MMU would incur; the ST’s DRAMs
were being thrashed ten or fifteeen nanoseconds under spec (“You have to
understand,” said our hardware guys, “DRAMs are really analog devices,”
and I’m sure a DRAM designer somewhere felt cold and shivery all of a
sudden, and didn’t know why).

To run Unix effectively we needed some hardware that was very fast, that
was simple enough to put into a minor spin of the ST’s memory controller
with little project risk, and that would still provide some kind of
memory relocation and protection. The ability to have separate address
spaces to isolate processes would be good, too.

“If you can come up with something that takes about a gate delay, I’ll
put it in,” said John, the memory controller guy. He seemed dubious, but
willing to listen.

I went for a bunch of walks.

– – – –

In the early 80s, eastern Sunnyvale bordered southern San Fransisco Bay
with a landfill hill (a large, long mound maybe a hundred feet high),
and a sewage treatment plant just beyond. Beyond these were settling
ponds for the sewage, separated by a large number of wandering dikes
upon which were set miles upon miles of paths for walking. I never
exhausted the paths. It was easy to get your heart pumping and your legs
swinging and let your head fly off into some tough technical nut. I
never really noticed any smell; maybe once or twice. The winter rains
washed the stink out of the air.

There were birds out there by the thousands, and any number of rodents.
I saw an enormous heron once and realized why my parents had been so
excited to see them nest in a marsh we’d lived near in Ohio.

We could also get a good view of planes at Moffet Field. Occasionally a
U2 would take off, shaking the ground slightly as it roared into the
stratosphere to look (we were told) for pot fields in northern
California, saving the world for democracy.

Then the path would loop back, and I’d bounce some ideas off of people.
Eventually we got it.

– – – –

The MMUs I knew about did page table walks of a multi-level tree; those
multiple indirections implied complex, stateful and slow machinery.
There was no room in the ST’s memory controller for the caches required
to make a table-based system perform reasonably, even if the gate count
of table-lookup hardware had been possible. The ST was no VAX. We had to
pay dearly for chip area, schedules were tight, and DRAM timing was even
tighter. Nobody wanted to pay for a feature they’d never use.

Non-MMU-based systems used base-and-bounds; a favorite technique in
mainframes and minis from the 60s and 70s. We could get protection by
checking user accesses against limit registers, a pretty cheap
operation, but that wouldn’t get you relocation. To do that you had to
muck with the address bits, and do an addition.

The problem was, there wasn’t time to do an addition with the necessary
carry-propagation on every single address issue, not to mention the gate
count.

So how does a typical Unix process grow? The text and data are at the
bottom of the address space and don’t move; the bss follows those, and
grows up via the “brk.” The stack grows down. That’s it. Very simple,
very hippy 70s.

So imagine something really minimal, like replacing a bunch of address
lines with a chosen constant value for user-mode accesses. Leave
everything untouched for supervisor accesses. That’s it, that’s your
total relocation. It’s really simple to implement in hardware, just a
latch and some muxes to choose which address lines go through and which
get replaced.

For address space growth you have another register, a mask or a bit
count, that checks to see if some number of the issued upper address
bits are either all zero or all one. You start the stack at 0xfffffffe
and grow down. You start the bss low and grow up. A variable number of
bits in the middle of each address are simply substituted. If the upper
N bits aren’t all 0000…00 or 11111…11 then you generate a fault.

Now you have a system that both relocates addresses and handles growth
in two directions in powers of two. You use throwaway instructions to do
stack growth probing (dud sequences that don’t need to be restarted if
they fault), and that needs a little compiler work, but it’s not too
bad. Processes are tiled in memory at power-of-two addresses, so there’s
more physical copying going on than you probably like when stuff grows,
but again, it’s not too bad. Welcome to the world of
doesn’t-totally-suck, and probably runs rings around a PDP-11 despite
its limitations. AT&T SVR-N didn’t have paging anyway (like I said, they
should have stuck with phones).

– – – –

John Horton, the memory chip guy, actually did this hardware for the
Mega ST; I don’t know if it’s documented, or if he had to sneak it in or
not. I do know that it was not used for Unix in my time at Atari; the
deal with AT&T expired before the hardware existed, and frankly,
supporting Unix probably would have been a massive effort, and one that
the Atari software group would have been unable to adequately support. I
vaguely recall some Unix-a-like environments for the ST, but I pretty
much lost interest in the ST after I left Atari in 1987.

I recall talking about this scheme with John Gilmore, who took a kind
interest and asked some good probing questions. We had some great
conversations at some otherwise strained hacker dinners in Berkeley.
(I’ll talk about South Bay versus North Bay geeks some other time…).
"""

-- 
Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - https://www.jcea.es/    _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://mailman.jcea.es/pipermail/atari/attachments/20200308/84088d2a/attachment.bin>