MULTITASKING AND THE AMIGA by Peter McKellar [Ed: Peter is a Consultant Systems Programmer in large IBM mainframe environments. He's also put together a MultiTasking Theme Disk pulling together material from various sources on this very important topic, including Pete Goodeve's IPC standards - see the end of the article. Many thanks, Pete.] XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX People are often confused by the term "multitasking". This article will attempt to explain some terms for the novice. If you are an experienced user there may also be a few points for you. Multitasking Comparison. It doesn't take a genius to see that the Amiga is a far superior machine to an IBM PC or clone. We all know that an Amiga is better than a MAC or ATARI, both on price and performance. But what is it that makes the Amiga really shine? Obviously, its multitasking capability alone makes it stand out from the opposition. PC users claim that "MEMORY RESIDENT" programs permit them to run more than one thing at a time. MAC users also claim that their machines permit more than one program to run at a time. The ATARI user, whilst closest of all, claims multiple execution is possible. This is not true. Multitasking, in the full meaning of the word, does not occur. None of these others can boast the power of the Amiga's true multitasking environment. The term, "memory resident", simply means that a program has been preloaded into memory. This means that it is occupying memory, lying dormant until branched to by a key-stroke. When this occurs the previously executing program loses control until another key-stroke combination is used. An apt analogy would be to a large program with procedures that are branched to when certain keys are hit. The only difference is that various parts of the program are sold by different suppliers. Memory management becomes a problem when so many users want to share only 640K. All the pro- grammers must agree upon where their code will reside. The unfortunate truth is that most suppliers don't. System crashes result when programs don't agree. You often see suppliers giving the cryptic instructions: "LOAD ME LAST" The basis for this is to ensure that memory doesn't get corrupted and that branch vectors are installed correctly. The MAC also relinquishes control of the CPU to another task when the user "clicks" on another icon, thereby selecting it for execution. Everything else stops while the currently active task takes over, even if this task is awaiting input from the keyboard or serial port, or patiently sitting back while your slow old printer grinds out another line or two from the buffer. The ATARI is similar to the AMIGA in that multiple tasks can coexist and it does share some of the CPU cycles throughout different functions. This is done on a fixed time, rotational, basis. But tasks don't have a priority based scheduling system like the AMIGA. I haven't undertaken a study of the ATARI, but I believe that the AMIGA supports a far more extensive lot of operating system calls. I can't deny it - I'm just an AMIGA BIGOT!!! In theory, the new OS/2 system, for IBM PCs does offer some sophisticated multitasking capabilities. But let's face it, there isn't any software around that uses any of the features. It costs a fortune and won't run on less than one and a half meg. That's the first release of OS/2, the full blown version, with graphics and all, will require 4 megabytes - just for the operating system (pretty hot, eh?). The full-featured version is not yet available. It's actually tied up in litigation from APPLE, and nobody is writing software for it until the court case is decided. As the case is simply a stalling action brought by APPLE, to cripple IBM's release of OS/2, it could possibly be dragged on for years. In the meantime, this is an opportunity for the AMIGA to slip through and top sales over both. The AMIGA operating system is far superior to all of the systems now avail- able. Its system displays the same techniques of multitasking that can be seen on high-end work stations right through to large mainframes. The only real difference lies in the ability to recover from catastrophic errors. The AMIGA Operating System is likely to invoke Mr. Guru if you don't follow the rules properly. MULTITASKING OVERVIEW. As microprocessors become faster and faster, multitasking becomes more and more important. Even with the superb custom chips installed in the AMIGA, I/O speed is a major contraint. It is wasteful for the CPU to be idle as it waits for input or output operations to complete. Any service that relies on some physical action (eg driving the electron guns that display text and graphics on the screen, or reading a disk) takes thousands of times longer to complete than the execution of programs within the CPU. It even takes longer to execute instructions that operate on RAM, rather than the data registers located on the microprocessor chip. Multitasking allows the processor to INITIATE one of these time-consuming activities (eg write to the disk) then promptly forget about it. It can now move on to more productive activities, like playing a game, calculating pi to a million places, compiling a program, balancing your accounts and any other tasks that require your attention and computing power. Each time one of these other tasks no longer requires CPU cycles, someone else gets a chance to use the processor. More important tasks may also gain access to the CPU by forcing an interrupt. But how does the Operating System achieve such harmony, such a blissful and orderly sharing of resources? By careful design and hardware support. Commodore have a priority-based task dispatching technique. This is possible only if the software is well written and documented so the user (in this case, the programmer) can access required services (eg, read). The hardware must also permit interrupts, which stop the currently active task and allow the Operating System to reassign control of the CPU to a more deserving task. The ability to interrupt a task makes this a "pre-emptive" Operating System. Only a task with a higher priority than the currently executing task can usurp control from the present task. Tasks in the system with the same priority as that currently executing will still get to use the processor. Tasks of the SAME priority get to equally share CPU on a rotational basis. The operating system forces a time interval interrupt to ensure that one task doesn't hog the chip. If it wasn't for multitasking, the CPU would be idle for the greater part of its existence. Multitasking allows the user to regain most of the power otherwise lost. When higher priority tasks are waiting for resources other than CPU, lower priority tasks can execute. They will be interrupted and put on hold by those higher priority tasks when their wait condition is no longer outstanding (eg their I/O has completed). When the higher priority task again waits, the lower priority task again gains control. The same happens time and time again. INTERRUPTS. The term "interrupt" has been mentioned several times so far. Maybe I need to clarify just what an interrupt is, and how they work. Interrupts are first supported in the hardware of the Motorola 68000 microprocessor chip. The 68000 recognises any number of interrupts, but only seven priority levels are recognised. Priority becomes important when multiple interrupts are in effect. An example of when this will occur is when an interrupt is received from an external device (say a disk drive indicating it is ready to transmit data) and a program has tried to do a divide by zero. The system must be able to distinguish who to service first, the program or the drive. The Amiga's Operating System provides further discrimination with interrupts. In conjuction with the Peripheral Interface Adapter chip, (the 8520), and one of the custom chips, the 4703, up to 16 interrupt levels are provided. The table below shows these. 4703 CPU Pseudo Name Priority Priority Purpose NMI 7 15 Non-Maskable Interrupt INTEN 6 14 Special (Copper) EXTERN 6 13 8520B, external level 6 DSKSYNC 5 12 Disk Byte RBF 5 11 Serial Input AUD1 4 10 Audio Channel 1 AUD3 4 9 Audio Channel 3 AUD0 4 8 Audio Channel 0 AUD2 4 7 Audio Channel 2 BLIT 3 6 Blitter Done VERTB 3 5 Vertical Blank COPER 3 4 Copper PORTS 2 3 8520A, external level 2 TBE 1 2 Serial Output DSKBLK 1 1 Disk Block Done SOFTINT 1 0 Software Interrupts In our example, the standard CPU's seven priorities could have resolved the conflict. A DSKSYNC would have been received at priority "5" and the zero divide would have generated a level 1 priority interrupt, ie SOFTINT. But what if the COPPER and the BLITTER both generated an interrupt during a vertical blanking period interrupt? Purists would recognise that this is an improbable, if not impossible situation, but serves only as an example. It does however demonstrate the neccessity of the extended interrupt priorities provided by the AMIGA's Operating System. DISPATCHING. Now that we realise what the custom chip's role is in assigning priorities, who will get dispatched first ? A task can be in one of 6 states , they are : 1. Running 2. Ready for execution 3. Waiting on an external event 4. Just added to the ready queue 5. Being removed from the Task queue 6. Awaiting special exception processing Items 4,5 and 6 are transient states and will not be discussed , The system maintains 2 queues of tasks that are not presently running. The first is sorted on priority and contains "ready tasks", those available to be dispatched. The second queue is a list of all tasks awaiting an external event (eg the completion of I/0). These are not held in priority order. When an interrupt is generated (for example,when the I/O completes to a device), the queues are re-examined. The task that was on the "not ready" queue, but whose I/O just completed, is requeued onto the "ready tasks" queue. This queue is then scanned from the head of the queue. As this queue is sorted into priority order, the highest priority task will be found first. This will be dispatched. The exception to this comes when a pre-specified "quantum" of time has expired. When this happens, the next task of the same priority gets a chance to execute. This time-slicing will continue, amongst the highest priority tasks, until a higher priority task is placed at the head of the "ready tasks" queue. Priorities can range between -128 (the lowest) to +127 (the highest). System tasks vary between -20 and +20. Zero priority should be used by user applications unless a special interaction with system tasks is required. USING MULTITASKING Multitasking can fall into one of 3 broad catergories. 1. Stand alone processes 2. Processes generated by another process 3. Tasks generated by processes or other tasks STAND ALONE PROCESSES are what you generate if you run a batch file or command under CLI, or cause another window to be opened under WORKBENCH. A more common example would be having a clock active in your title bar, doing a background print of a file, and doing a directory list to your console. This serialization of resouces may also require the program to wait (eg wait for keyboard input, letter by letter, of a command). More waits will occur if both your directory listing, and your file print, need to use the disk drive at the same time. This is a far more efficient way to use your machine than if you were to do each task in turn. The actual elapsed time will be much less - who says there's no such thing as a free lunch? I guess the only real cost is in CPU cycles required to service the dispatching cycle, maintaining the queues, and serializing access to physical devices like the disk drives. These are all pretty meager costs compared to the savings. The more observant readers will have noticed that I used two terms before, TASK and PROCESS. These are both features of multitasking but they work at different levels of the operating system. Tasks work at a much lower level that Processes. Tasks are unable to perform DOS functions (eg producing output) and so a process may have to spawn another process if these facilities are required. The difference lies with a process being created through DOS, whereas a task is one level lower, being created by EXEC. Consequently, if you want a technical reference for setting up a Process, you refer to the AmigaDOS Manual, put out by BANTAM. The section of this manual titled "AmigaDOS Developer's Manual" (bottom of page 189 in my copy) will show you the syntax of a "LoadSeg" call, over the page is the "UnLoadSeg" call. These calls load and unload segments of code for the express purpose of spawning new Processes. The address of the code just loaded is referred to in the "CreateProc" call (page 187). Tasks are explained in the "ROM Kernel Reference Manual: Exec". The two calls AddTask and RemTask are used to create tasks at the Exec level. The calls rely on the correct initialization being performed. All necessary information can be found in the Exec manual, and this is illustrated with many examples. But if you're the lazy type like me, this won't be sufficient. I NEED code, in machine readable format (ie on disk), and I have to know that it works. For this reason I have scoured the FISH disks and found some interesting material. Megadisc Theme disks are currently in preparation, specifically demonstrating task and process creation. Existing public domain offerrings are possibly a little cryptic, and don't always deliver what they promise. I will be reworking these into a format suitable for distribution and append relevant documentation. Megadisc will notify its readers when the disks become available. Follow-on articles will provide relevant code, comprehensively annotated, so that you too can write multitasking programs!! IPC On a slightly different track, I have just received word from Pete Goodeve (of XICON fame) in the USA. He has been the leading light and inspiration for a new standard - "IPC". This new and mysterious acronym is short for "Inter Process Communication". This standard will do for multitasking what IFF did for files. The standard will permit different modules to talk a common language provided that all agree to follow the same conventions. But, you ask, why? The possibilities are limitless. It would be possible to mix'n'match commercial packages and public domain software. The word processor of choice with your favourite spelling checker, a different printing package, and then send it all by modem to a friend - but all by the one program. External interfaces with a database retrieval system could be all powerful. Real time data capture by slave processes would be simple, your comms package could quietly lift data off a videotex system, pass it to one of a number of slave processes, depending on content. Key values could be plugged into your spreadsheet: - by now you're starting to see the awesome power of such a standard??!! Pete and his co-workers had posted this standard on USENET in the USA and after much debate its form has stabilised. The very first copy of the sample disk arrived in my letterbox only days ago, along with three catalogues and two bills. No doubt you'll only be interested in the sample disk, so I've forwarded this to Megadisc, for packaging as a theme disk. If sufficient interest is shown, I will write some more on the standard in a future issue of Megadisc. I suspect that we will hear far more about this new standard in the coming months. [Ed: Any programmer out there who is interested in this IPC development and wants to get Pete's disk, just call on (02) 9593692. This initiative looks like it could out-hype HyperCard on the Mac, but like anything that starts, it needs support, especially from other countries. So anyone who needs a project, here it is. And Pete Goodeve is a most deserving person, not to mention capable - a bit of gossip, he tells me that WorkBench 1.3 featured a XICON lookalike, with no attribution to him. After presenting his case to Commodore, they decided to change the name to ICONX...And anyway, it doesn't work on the 1.3 currently available. Anyway we continue to use the excellent XICON and are grateful to Pete for the support he showed from the very beginning.] XXXXXXXXXXXXXXXXXXXXXXXXXXXX END OF MULTI-TASKING XXXXXXXXXXXXXXXXXXXXXXXXX