A-EON Interview about Amiga's future - Distrita

[matthey]

The Amiga has always had real priority based preemptive multitasking.

True. Any task can take over the system and turn off multitasking so it is not secure but it is preemptive multitasking by definition. Responsiveness was traded for security.

I feel the AmigaOS has been slighted (not by mongo). The AmigaOS is one of the best and most responsive OSs at multitasking (near real time OS made the Toaster possible). Code reuse and modularity are also top notch even today. The AmigaOS trades security for speed and ease of use. There was a lot of forward thinking in the AmigaOS design and choice of 68k CPU which allows most software from 1985 to still work today. Both the AmigaOS and 68k CPU have survived the test of time quite well, IMO, despite not having been developed anywhere near their potentials. The Amiga weak point (originally it's strength) was the custom chips which again were under developed. Compare the AmigaOS to the DOS+Windows, MacOS, RiscOS and the Amiga has less growing pains and more speed. It's the lack of a more modern 68k AmigaOS, lack of more modern 68k hardware (which I believe can be kept very compatible) and as a result lack of more modern software and software support that makes the grass greener on the other side of the fence.

[matthey]

By those words (which I have bold faced) you make my point.
The OS is cooperative, preemptive multitasking would always allow another process to eventually gain control.
Not that a round robin scheduler always precludes preemptive operation.
But a decent OS would always reserve some time slices for kernel operations that would allow enforcement of task switching.
In short, see the second sentence in my post.

No. Preemptive multitasking uses a timer that lets tasks run until their time is up and then the task is preempted (interrupted) to give another a turn. This is how the Amiga works. Preemptive multitasking can be turned off with other operating systems through Admin privileges or hacking which makes their multitasking no less preemptive (while it's working). The task doesn't have to worry about task scheduling or what task is running with preemptive multitasking. Cooperative multitasking requires the task to call an OS function to allow another task to run. The Amiga exec.library does have a Switch() function (-$36) but it is private (even though it may be useful in some cases). The Amiga is considered to have preemptive multitasking though.

[matthey]

Edit - Looking over this, my bias is (even to me) painfully obvious.
Coming from OS' that always give ultimate priority to the kernel (and thus will never allow a single process to assume complete control of a system), Amiga OS has been (somewhat) disappointing.
So...by common definition, using the term preemptive is acceptable (even if this can be defeated) AND prioritization has previously been documented.

So... I'll cede this one to you guys.
With the qualifier that it is a piss poor implementation of preemptive multi-tasking.

The AmigaOS requires cooperation between good behaving preemptively multitasking tasks. Again, this was a tradeoff of security (and to a lesser extent stability) for speed and ease of use. It was a better trade-off back in the day when CPU power was more limited but I would argue that the advantages are under-appreciated today. Would there be Amiga users today if the Amiga ran at the speed modern secure operating systems would run on a <100MHz 68k CPU? Would the Amiga be as fun and easy to use?

Which leads me to a question: Why is there Forbid() and Permit() in the first place? Apart from shutting the OS down I see no reason for those functions to be there at all.

Resources need to be shared with a multitasking AmigaOS and the 68k and locking CPU instructions (CAS, CAS2, TAS) didn't work correctly because of the way the memory bus was accessed with the custom chips (cache coherency issues between the CPU and custom chips). C= could have solved the problem if they made (or licensed) their own customized CPU to go with the custom chips but that was exceedingly expensive back then. This is no longer a problem today in FPGA (SMP should be possible too).

Forbid()/Permit() are not as big of worry as exec/Supervisor() and dos/Format(). The Amiga will never be as secure as BSD but there are a few things we could do to improve security (or at least improve stability and make it quick and easy to recover and restore from problems).

[matthey]

You don't need those, because you can use bset and bclr. These instructions test the bit they set or clear before writing to the bit. With this you have test then set and test then clear. Perfectly fine for such mechanisms. Aren't CAS. CAS2 and TAS for multiple CPUs anyway?

The 68k, like most CISC processors, does read-modify-write cycles atomically (together). This is used on the Amiga extensively for incrementing/decrementing library open counts for example. RISC can't do this because the ALU and load/store instructions are separate (problematic for PPC Amigas). The locking instructions like CAS, CAS2, TAS are used for resource arbitration which is essential for multiple CPUs/cores but they can also be used for multitasking resource arbitration. MacOS and Unix like OSs use them more than they should considering how slow they are (hundreds of cycles in worst cases). The AmigaOS started with Forbid()/Permit() and later added semaphores. AmigaOS 4 added spinlocks and their locking instructions should work without the custom chips (which they need to use more). I'm no expert on this topic and it can be tricky so I will stop here (one reason programming on a PC is more difficult for beginners).

[matthey]

I am not so sure is this true. If Amiga multitasking is so good why MP3 players or CD burners need large buffers?

To me it seems multitasking on Amiga is unpredictable.

Paula's audio buffer size is limited by the custom chips (easily fixed with enhanced custom chips). The Amiga serial ports were limited to low speeds because of limited buffer size support. Amiga IDE was limited by small buffer sizes (and old PIO modes) until the 4000T. Without proper buffer sizes, the CPU has to do more work and the Amiga with 68k CPU has a limited pool of CPU cycles to start with. Buffer sizes were probably adequate when the Amiga was created but were barely or in most cases not upgraded with ECS and AGA. The Amiga did receive expansion boards and accelerators which fixed many of these bottlenecks.

Try installing Windows XP on an old 386, 486 or Pentium CPU to see how responsive it is in comparison to a 68k Amiga. I had the fan die in an old laptop with Pentium M (roughly the performance of a Pentium III at the same clock speed but more efficient on power) which caused the clock speed to run at 800MHz. Responsiveness was worse than most 68k Amigas even though it had some processing power in slow motion. These modern OSs with their security, features and bloat have a lot of overhead. MOS PPC Macs also are more responsive and performance efficient than with their previous Mac OS X. Any surprise?

[matthey]

I am not sure is this related only to slow I/O. For example your real time application, is it still working right if you have GCC compiling large source code at background at lower priority?

"Real time" depends on the CPU performance and OS/multitasking efficiency so it only applies for a particular OS with a particular CPU doing specific tasks. This phrase is more commonly used when referring to embedded systems with defined bounds. Needed Cache sizes and response times can be calculated with most embedded systems but not for general purpose computers. This is why I used the phrase "near real time" when referring to general purpose computers. The AmigaOS with Toaster was real time enough for it's purposes on the Amiga where it was not possible with much faster processors on other operating systems. Throw in some more background tasks on the Amiga (like GCC compiling in the background at low priority) and the response time may have dropped too much. Add a faster 68k processor and the background tasks may be possible again with Toaster.

I asked for a lower task priority for vbcc's vc (maybe 68k only?) to be able to compile in the background while editing. Frank Wille chose a task priority of -2 which made a huge difference in editor responsiveness (major slow down to minor slow down). I am using a CSMK3 68060@75MHz with many of the bottlenecks we talked about before removed. A slower and less efficient Amiga may not feel so responsive while compiling and editing.