[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[brantley@coraid.com (Brantley Coile)]

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 at 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 at ieee.org>:
> 
>>> 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 at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuh s
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs