Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!gatech!rutgers!uwvax!per2!dag From: dag@per2.UUCP (Daniel A. Glasser) Newsgroups: comp.sys.atari.st Subject: Towards a real, somewhat compatible multiTASKING TOS Keywords: TOS, Multitasking, constructive ideas and proposals, future versions Message-ID: <877@per2.UUCP> Date: 16 Aug 89 19:54:15 GMT Organization: Persoft Inc., Madison, WI Lines: 90 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-----------