🚀 go-pugleaf

There's been a lot of chatter about multitasking on the ST, but no real
concrete proposals.  It seems that many of the people in the debate are
not aware of the difference between a multitasking system and a multi-user
system.

Multi-tasking does not imply multi-user.  A version of TOS that could do
multi-tasking need not have any memory protection hardware beyond what is
already in the basic ST.  Task swapping would not be required.  Context
switches would be relatively clean and efficient.  Many existing programs
would not work well as background tasks because they go directly to the
hardware or make assumptions about the "unused" memory, others would run
in the background without modification.  Even those which could not multitask
could be run as single tasks.  It may be useful to note that I've seen
multitasking systems on 8-bit processors with no MMU and less than 64kb
RAM, and that the original version of UNIX was developed on a machine
with even less RAM and no MMU.  5th Edition Unix was running on the
DEC LSI-11/02, which had no MMU and 58Kb of RAM total.

Changes to TOS for application driven multitasking might include the following:

  (This is not an exhaustive list.  I would think that programs that use the
  multitasking environment would have a different magic number, and an
  extended process header (which would make sense because of what the magic
  number actually is anyway), and the TOS program load code could determine
  if the task can be multitasked or not.  Older versions of TOS would not
  execute multitasking programs.)

 1)	An extended basepage which contains entries for various hard and
	soft exception vectors.  Notably, there should be a termination
	vector, divide by 0 vector, buss-error, address error, critical
	error, illegal/invalid instruction, break-point, etc.  A TOS call
	to set the vectors (Set Exception Vector) already exists, and
	could be modified to use the extended basepage.  The entries in
	the extended basepage vector table would have three reserved values:
	-1L means use the parent process value for this vector, -3L means
	use the system default routine for this vector, 0L means ignore
	this exception, any other even value is taken as the address of
	an exception routine to be jumped to in the case of the exception.
	All other odd values are reserved.

	This vector table would allow programs that set exception vectors
	to abort abnormally without fear of bringing the system down, and
	allow multiple programs to set exception vectors for when they are
	the active task.  The vector table could have more or different
	entries than are in the system table now, for example, a control-c
	vector, an I/O Timeout vector, a message-received vector, etc.
	
 2)	A new TOS call to send a signal to a process based on its ID.

 3)	A new TOS call to unschedule a process until it receives a signal.

 4)	An extensible stream device list, similar to the extensible
	block device list, allowing serial devices to be added and used
	in the same manner as the standard streams.

 5)	A new TOS call to schedule a signal to a process at some delta-time.

 6)	An extension of the Mshrink TOS call to conditionally grow an allocated
	block of RAM.

 7)	An extension to the Malloc command to return the size of the largest
	contiguous available block of RAM.

 8)	An extension to the TOS Pexec function to start a task and continue.

 9)	The ability for an interrupt handler to access the process context
	of a task.

 10)	Change TOS blocking I/O operations so that they reschedule rather
	than busywait.

 11)	Change TOS block device I/O operation so that they reschedule rather
	than busywait.

 12)	Add a mechanism to TOS to gain/release exclusive access to a stream.

I've not gotten into the changes to make the file system robust in a multi-
tasking environment or the changes to the GEM code that would be required.

This is just to get the ball rolling.  Let's see some constructive ideas
on what a TOS 3.0 might look like.  If we can get a good enough unified
collection of ideas, maybe the folks in Sunnyvale might use some of it.
If the ST commercial software development community publicly buys into
the ideas which may break lots of existing software, we might see some
real progress.
-- 
 _____________________________________________________________________________
    Daniel A. Glasser                           One of those things that goes
    uwvax!per2!dag                              "BUMP!!!(ouch)" in the night. 
 ---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------