Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!snorkelwacker!apple!sun-barr!newstop!sun!imagen!atari!portal!portal!cup.portal.com!ts
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.sys.mac.hardware
Subject: Re: Why no VM on a 68K? (was: Re: Why 68000?)
Message-ID: <27247@cup.portal.com>
Date: 23 Feb 90 10:52:45 GMT
References: <1990Feb11.154304.19943@smsc.sony.com> <3919@hub.UUCP>
  <10223@hoptoad.uucp> <1990Feb15.155556.5319@uncecs.edu>
  <19472@dartvax.Dartmouth.EDU> <502@taniwha.UUCP> <6341@ncar.ucar.edu>
Organization: The Portal System (TM)
Lines: 27

I wonder if we have the computing equivalent of an urban legend
going here?  When I first heard of this, the story said it was
a Masscomp machine that did this.  But it was always someone
who had heard about it who told this, never someone who had
used the machine.

This was in 1983.  Now in 1990 people are saying it was Sun, or
even that everyone was doing it.

By the way, not all instructions cause problems with bus error
on a 68000.  If you can arrange your code so that the instructions
that have problems never get a fault, you can do VM.

For example, most of the 68k Unix systems around 1984 were swapping
systems.  However, they wanted to dynamically allocate the stack.
To allow for this, the C compilers would generate a TST instruction
of the form "TST -N(A7)" at the start of functions, with N chosen
so that a location deeper on the stack than this function needs
for local variables and return addresses will be accessed.

If the stack needs to be grown, a bus error will be generated.

The bus error handler is able to check and determine that it was this
instruction that caused the bus error, and is able to then grow the
stack and resume the program.

						Tim Smith