5 Jun
2014
5 Jun
'14
5:26 p.m.
I ported Unix to the 68000 in the early 1980's and I did what I assume AmigoDOS did;
getting a page fault for anything but a stack frame access was fatal to the process. In
other worlds, no paging-in a process. The problem for paging was handling side effects
from auto increment or decrement access modes. If the faulting instruction used one of
those modes, the 68000 didn't provide enough information to do what we did on
PDP-11's and simulate the faulted instruction. Nor could it automatically restart
the instruction, which was done in the 68010. A process had to be loaded completely
before being swtch'ed to, just like in 32v.
This left only the fault resulting from the stack meeting to grow. To solve for that
problem, we solicited help from the compiler. The function prologue of every function
would fetch the farthest used word from the frame pointer. In most cases this would do
nothing. For a frame that needed more stack allocated, this would cause a page fault. We
looked at the instruction at the faulted program counter, verified it was a "grow
me" instruction, allocated more core and put the process back on the run queue. The
result of the instruction was ignored, so we didn't need to have the kernel restart
it or simulate it.
This method wasn't original to me. It was common practice at the time. I assume this
the technique used by AmigaDOS.
Sent from my iPad
On Jun 5, 2014, at 5:33 AM, "Wesley Parish"
<wes.parish(a)paradise.net.nz> wrote:
Which of course raises the question: how did AmigaDOS manage context switches
and the like for its brand of multitasking? I know BYTE explained it in the
early 1990s, but I threw away all my BYTEs a couple of decades ago, and don't
remember the details.
Thanks
Wesley Parish
Quoting Arno Griffioen <arno.griffioen(a)ieee.org>:
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
On Mon,
Jun 02, 2014 at 10:24:48AM -0400, John Cowan wrote:
Ronald Natalie scripsit:
> Still with all it's flaws, on the 286 and later UNIX actually did
run in
> protected mode, something it took ages for
DOS/Windows (one can
argue
> backwards compatibility with the early
processors) or Apple (no
excuse
> here, the early Macs were 68000's which
had protection) to pick up
upon.
The original Mac 128K was a 68000 processor, and IIRC memory
protection
didn't arrive until the 68020.
As mentioned by others the 68010 could, with additional external
hardware,
support memory management.
The original 68000 (and 8-bit data bus 68008) did already have the full
32
bit instruction and data support of the complete family, but for MMU use
it
lacked one critical feature in the fact that it did not push enough
page-fault
information on the stack to re-start an instruction in case of an
(externally
signalled) page-fault.
So even if you interfaced external MMU logic then a basic 68000 was
still in
trouble when a page fault occurred as it could not 'start over' the
faulted instruction.
The 68010 added the correct stack frames to be able to restart a
faulted
instruction and also added the first small performance enhancement in
the
form of a 'loop mode' where the CPU could basically cache a small loop
and execute this without incurring addtional memory wait cycles.
As a result the '010 was usually used in various *NIX machines of the
era like some SUN2's and various machines (one-offs or low production)
from other brands.
Eg. I still have a machine in my collection which is from a small local
production run that utilises an '010 with a custom, but quite
rudimentary,
MMU based on some simple logic chips and it used to run SVR2. Very
slowly
as it had a whopping 1 Mbyte of RAM and the MMU could give you a virtual
memory size of 4 Mbyte.
I did port MINIX to it and added memory management/protection support to
the kernel. Ran a lot faster :)
With the release of the '020 Motorola delivered their own full-blown
(but
still external) MMU in the shape of the MC68851
Many non-UNIX '020 based machines of the era did not have the MC68851 on
board at all (eg. most Apples from the time) as it was relatively
expensive
and could incur extra memory latency/cycles being an external unit.
With the '030 Motorola finally moved the MMU onto the same die as the
CPU
(reducing the latency and cost) and it became more prevalent on more
platforms (although the cheaper 68EC030 was available without an MMU and
used in many machines)
Bringing this back to UNIX, I used to do some local supporting work at
CBM for
the Commodore UNIX'es that were Amiga, and of course M68k based.
The official Amiga 2000 '020 turboboard (or one of the A2500UX'es like I
have
at home :) ) does have both the MC68851 MMU and the MC68881 FPU and
these
were used for a, mostly in-house at CBM, SVR3.2 based UNIX version.
AmigaDOS of course also ran fine on it, but did not use the MMU.
The later, general release, SVR4 UNIX version was desgined to run on
the
'030 based A3000UX'es, although it still ran on the '020+MMU cards in
their
limited (4Mb) DRAM.
Bye, Arno.
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuh s