A-EON Interview about Amiga's future - Distrita

[Thorham]

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).

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 Amiga will never be as secure as BSD

Unless you run BSD on it

Coding directly with an assembler makes sense.
Yes, its more painful, but it would also result in more compact, faster code.

It's more fun! 68k assembly language is a hobby of mine. C is nice, but I use it for utilities like Lua5.3 with some added libraries, or some other miscellaneous things.

Should you ever seriously decide to do this, I'm in.

Don't wait for it.

[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).

[KimmoK]

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.
... 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.
... Compare the AmigaOS to the DOS+Windows, MacOS, RiscOS and the Amiga has less growing pains and more speed. ....

Nice thread & nice post.

Never thought that the ability to stop task switching for a while is one of the reasons why AOS has been so wickedly fast (responsive).

Instead of NG developments done behind closed doors I would love to see alternative kernels etc. and some recompiled apps for it, for user community to try, to see how they can behave.

When we now have Ghz instead of Mhz to play with, there should be room to take "slower" ways in use without being slower than the fastest multitasker and responder OS+HW of y1990.

++
Also... when thinking of multicore systems. IMO: server OSs (Linux, Unix, OSX, NT) have taken SMP in use without considering if it would give better responsives if some core is put to deliver the user experience (dedicated to it heavily, if not totally).
I'm thinking that if the SW that is responsible for user experience (responsiveness) would have very high priority on some core, it more likely has the data it needs on the L2 cache etc.... IMO, some OS need several cores at 2Ghz to say "tada", so focusing stuff on only one core might not be good idea for that kind of mammoth OS. But I think for some OS (that almost fits in L2 cache of a core) it might work better.

[Rob]

"However, we have acquired a worldwide, non-exclusive, perpetual licence to use the Amiga One (and AmigaOne), AmigaOS and Boing Ball names and associated trademarks from Hyperion Entertainment."

Interesting.  I knew about AmigaOne license, did not know about the others.

A-EON having been using the Boingball and AmigaOS branding on their products for quite some time so nothing new here.

[itix]

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.

When you are programming in higher level languages you dont have those assembler instructions available. The compiler may generate code using those instructions but it is not guaranteed. For example Intuition manual recommends using Forbid()/Permit() pair if you are toggling flags in your Window structure.

Forbid()/Permit() pair is also fundamental part of AmigaOS design. When you are scanning certain system lists you must arbitrate access with these. When Workbench launched program is returning it must call Forbid() before exit. If you are sending a message to public message port you must use Forbid() for protection. Many functions in the OS are serialized and are executed in Forbid() like memory handlers and library init/expunge functions.

Semaphores in AmigaOS are internally using Forbid(). AllocMem() is using Forbid() and it is very slow function what hampers multitasking very badly if called repeatedly.

[OlafS3]

With 'writing something better' I mean a completely new OS that's entirely incompatible with AOS. Not a single part would be kept. It would be more of a proof of concept than anything else, because there would be no software to run on it, of course.

I would also do it in 68k assembly language. Completely. Some people will probably tell you that that's a very bad idea

To develop a new OS just as "proof of concept" with no software for it instead of f.e. helping on Aros 68k to improve it sounds rather weird to me but go for it if you want

[guest11527]

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?

For that, or at least, for systems with multiple bus masters. The Amiga infrastructure does not need those, resource locking is done in a different way. Unfortunately, a pretty broken way.

AmigaOs uses "Forbid()/Permit()" as low-level locking mechanism, along with "Disable()/Enable()". Unfortunately, the former cannot work on multi-core systems, whereas the latter is even more broken as it requires even a communication to the slow custom chips.  

Other operating systems use a smarter and more scalable design where the lowest level synchronization primitive is not based on disabling multitasking completely, but on semaphores. Everything else is then based on top of this, including monitors (this is the closest analog to exec semaphores, which are - actually - not really semaphores in the classical sense, but rather "monitors").

As of 2.04, Forbid() locking (fortunately) grew out of fashion in many places, even the dos.library uses now semaphores in many places - though for backwards compatibility, also runs a forbid-lock on top. (Shudder).

[guest11527]

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.

Actually, bset/bclr or addq are not atomic, at least not in the sense the word is used today. A second bus master could intercept the instruction at any time and then observe Os structures in an inconsistent way. Except that such bus masters are absent on the Amiga as single-core machine.

Library open counts are, however, not really secured due to atomicity of addq/subq, but are rather Forbid/Permit locked. Or actually, the whole story is a bit more complicated, as library open consists of the low-level exec function which is forbid-locked, and a high-level ramlib add-on which is patched in by the system itself as soon as dos becomes available. Then, however, locating libraries is due to the single-threaded ramlib task to which exec (or rather, the ramlib patch on top of exec) communicates. Thus, this is a pretty complex beast and had, as of 1.3, quite a couple of loopholes.

addq/bset and friends are thus less often used by the Os as one may think. In fact, if you are writing in a higher level language, one cannot guarantee that the compiler emits the right instructions in first place (unless you're using C++11, which does have atomic variables. "atomic" in the real sense. Of course, there is no such compiler on the Amiga.)

[Iggy]

...Don't wait for it.

Yes, I rather figured that.

[Thorham]

When you are programming in higher level languages you dont have those assembler instructions available.

For an OS it doesn't seem a problem to have some handwritten code here and there. User programs should use OS facilities for locking mechanisms.

Forbid()/Permit() pair is also fundamental part of AmigaOS design. When you are scanning certain system lists you must arbitrate access with these. When Workbench launched program is returning it must call Forbid() before exit. If you are sending a message to public message port you must use Forbid() for protection. Many functions in the OS are serialized and are executed in Forbid() like memory handlers and library init/expunge functions.

Semaphores in AmigaOS are internally using Forbid(). AllocMem() is using Forbid() and it is very slow function what hampers multitasking very badly if called repeatedly.

I didn't expect that. What a steaming pile

To develop a new OS just as "proof of concept" with  no software for it instead of f.e. helping on Aros 68k to improve it  sounds rather weird to me but go for it if you want

Is it so weird to want something new that's not hampered by cruddy design? Anyway, if they want 68k assembly language optimizations for 68k Aros, then that meight be interesting for me.

For that, or at least, for systems with  multiple bus masters.

Good, I want to try some things, and don't want to be stuck with instructions that may or may not work properly.

[guest11527]

Is it so weird to want something new that's not hampered by cruddy design? Anyway, if they want 68k assembly language optimizations for 68k Aros, then that meight be interesting for me.

While I don't know the design goals of AROS, I would assume that some form of source-code based compatibility is desired there. So I afraid AROS suffers from the same elementary Forbid/Permit problem AmigaOs has. But anyhow, this pair is only one of many design flaws.

While I agree that it is probably not weird to want something new, I should also say that I wouldn't really expect much interest from outside on such a project. There are many things that could be done better, better than AmigaOs, or Linux, or Windows, all together. But whatever design you come up with, it is really the application base that makes a living Os, and as such, any new design is damned to be irrelevant...  

Good, I want to try some things, and don't want to be stuck with instructions that may or may not work properly.

bset and friends are surely working correctly, and are - as far as AmigaOs is concerned - "atomic enough" if you get my drift. TAS/CAS/CAS2 and so on is nothing you can count on on Amiga hardware. It will probably not do what you want, and even interact badly with some bus protocols. For example, I'm not entirely sure what a TAS into Zorro RAM might possibly do. It's probably even board dependent.

[itix]

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).

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.

[guest11527]

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.

Actually, this is really not the fault of the multitasking. First of all, "large" is really a matter of perspective. Is a one megabyte buffer large or small? For the Amiga, it is large, for a PC, it is small.

But more important, the problem is really slow I/O. Look at the bandwidth average Amiga hardware has to offer. Probably a couple of MBs per second. Consider the latency of the average old Amiga harddrive (from the museum). Now compare that with a PC (probably hundred to thousand times higher bandwidth) times lower latency, times larger buffers....

[wawrzon]

Is it so weird to want something new that's not hampered by cruddy design? Anyway, if they want 68k assembly language optimizations for 68k Aros, then that meight be interesting for me.

one would have to chat with aros developers, where asm optimizations would be already useful. there is already 68k asm in places, mostly by jason and toni but also some optimizations by matthey. best is to read neccessary documentation, join developers mailing list, get access to the repository and kcommunicate with them. im a member, but im not experienced in coding. however, wherever i can help, i will. for instance to setup local build environment.

[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?

[itix]

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.

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?

Try to run simple non-IO real time task at priority 0 and GCC below 0.

You might find out that GCC is loading some files from the disk and this is delegated by the OS to tasks running at higher priority than your task. Suddenly your real time task is blocked by the OS serving low priority tasks.

To me it seems that if you dont raise your own priority over OS tasks you dont get served as expected. It doesnt matter how fast your system is. As long as you are running at priority lower than 10 the scheduler cant guarantee you fair share to the CPU.

Try installing Windows XP on an old 386, 486 or Pentium CPU to see how responsive it is in comparison to a 68k Amiga.

But Windows XP has lot more features than Amiga, like memory protection, built-in TCP/IP and USB stacks, and bunch of services (like you mention below).

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?

Sure. No surprise there. But on the other hand raw performance is still same. Heavy computational tasks run roughly at same speed and it is not possible to have significant gain in the RC5-72 contest for example.