From mboxrd@z Thu Jan 1 00:00:00 1970 From: wes.parish@paradise.net.nz (Wesley Parish) Date: Thu, 05 Jun 2014 21:17:04 +1200 (NZST) Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') In-Reply-To: <20140605073112.GD10373@attic.nerdnet.nl> References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu> <20140602142446.GM18282@mercury.ccil.org> <20140605073112.GD10373@attic.nerdnet.nl> Message-ID: <1401959824.53903590d25f5@www.paradise.net.nz> 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 : > 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 >