some fancy ideas for a extended (68k?) CISC-CPU

[Thomas Richter]

Originally Posted by meynaf

An exception is a crash.

No, an exception is an exception. How the program deals with it determines whether that is a crash or not.

Originally Posted by meynaf

What i have attempted or not isn't the point. You have to stop always bringing the subject to my person.
Now, CAS2 is for double linked list. All others are satisfied with the simpler CAS instruction, which i wouldn't remove.

No, it's not. If you believe it is for doubly linked lists only, please look up "lock free stack" and the "ABA problem", as I suggested. You cannot implement a robust lock free stack with just one pointer exchange through CAS.

Originally Posted by meynaf

About the other primitive used by risc cores, and the 68k doesn't have, why not telling more about it ? Hey, wait. Isn't it just some

exg

instruction targeting memory ?

Load-linked / store conditional is another primitive you use there. It is less complex than conditional exchange, but it requires additional hardware resources.

Originally Posted by meynaf

This instruction isn't worth its silicon, it's a pita for a hw implementation, has an ugly encoding, and isn't friendly when it comes to supporting it in an assembler or a disassembler. All that for double linked lists which can be done by other means.

Nope, not without blocking. That is pretty much the point. You can of course implement semaphores by means of TAS and then protect critical regions by a semaphore or a futex, but that's a blocking approach and less performing, and 68K does not have "linked load" for any other form of a two-operand exchange.



Again, that wasn't important back then, but it is very important today with massive SMT.

Originally Posted by meynaf

An exception is a crash (wait ? didn't i write this same sentence earlier in that post ? ). In the same way as a null pointer dereference (which a "real" operating system will catch too).

A null-pointer reference will typically lead to a core dump in any sane system, yes, but a bounds check may or may not. The oberon compiler I mentioned does not cause a crash on a bounds violation.

Originally Posted by meynaf

I didn't pretend 68k was Amiga. But if an instruction is useless on most platforms exept a few, and its job can be done by other means, then it's not worth adding.

The question is, how you count "most platforms?". Motorola had certainly more in vision than a games computer, the 68K market was quite a bit bigger. In some critical applications, it is quite important to have bounds checks and ordered recovery in case of violations. Not in toy systems like the Amiga, of course.

Originally Posted by meynaf

But ext is for signed values only. For the unsigned it becomes more complicated if the register can not be cleared before reading the value (when the target is itself or an addressing mode uses it).

You can fuse a "moveq #0,d0:move ..,d0" then. No worries about that. Wouldn't surprise me if Gunnar wouldn't be doing that.

Originally Posted by meynaf

Coldfire has mvs/mvz. x86 has movsx/movzx.

Coldfire has a very simple pipeline, it was designed for that. It's not a workstation processor, but its target market were embedded systems where CPU power consumption is important. On such a system, you don't use a complicated pipeline with opcode fusion.

Originally Posted by meynaf

Opcode fusion is the lazy reply. It doesn't change the fact there is a big impact on code density.

Yet, this is what contemporary CPUs do all the time. They are risk-machines with a cisc-interpreter. Maybe it's "lazy", but it shows one important fact: You do not change the machine language lightly. All attempts to do that failed - x64 is an AMD extension of a 32-bit extension of a 16 bit extension of an 8 bit processor, and it is so successful because it kept legacy code working. All these "itanium" ideas were nice, but failed. Now, maybe, arm has enough critical mass to succeed (hopefully), but what kind of an argument is "code density" in a tiny tiny market like 68K legacy?

Originally Posted by meynaf

But text segment is very often followed by data segment, of which data could have been accessed with pc-relative modes.

No, it is not "followed" in a Haward design. It is in completely (physically isolated) memory, addressed through the function codes. That is pretty much the point of a Haward design.

Originally Posted by meynaf

It is nice theory vs programming flexibility. Forgive me if i prefer the latter.

Forgive me if Motorola envisioned also target markets where it does matter to have this separation, and thus designed the instruction set with such things in mind. You have a very Amiga-centric approach here, but that's just too narrow minded what 68K was about.

Originally Posted by meynaf

The example of the Atari ST is something else. What is used isn't the fact it's code or data, it is the FCx signal associated with the supervisor/user state. And indeed it makes sense ; not only hardware is protected, but also vector table and most system variables. Still nothing to do with PC-relative accesses, though.

For PC-relative addressing, you would use the instruction/data function codes.

Originally Posted by meynaf

Not enough code space, what a joke. The 68000 had full line-A and line-F available.

A-line is for operating system applications, and F-line is reserved for coprocessors. You know that of course.

Originally Posted by meynaf

But yes, the excuse behind this error is that eor is 'rare enough'.

Apparently. Every instruction set is designed around compromises. This is just one of them. Risc instruction sets have other restrictions, such as being unable to load a full-bitwidth data into one register. You either have to use an indirection, or you have to use two loads to load the upper and lower bit, and assemble them. That is then the price for fixed-size instruction words.

Originally Posted by meynaf

No. It is a pure implementation problem. As movem is a complex one to do, even with microcode. It made the cpu designers very conservative and so they handled only the most common case.
Yet the instruction is extremely handy in many situations, and a gem for code density. I'd rather extend it.

It is useful, but a headache in CPU design. It increases latency, or complexity. It didn't matter for the 68K which is not able to restart instructions in all cases, and which is micro-coded all the way, but look at which jumps the 68040 has to do for exception processing of movem. 68060 got away with it, at the price of potentially causing double writes in some situations.

[meynaf]

Originally Posted by Thomas Richter

No, an exception is an exception. How the program deals with it determines whether that is a crash or not.

CPU exceptions and high level language exceptions are two different things.

Originally Posted by Thomas Richter

No, it's not. If you believe it is for doubly linked lists only, please look up "lock free stack" and the "ABA problem", as I suggested. You cannot implement a robust lock free stack with just one pointer exchange through CAS.

I have looked it up and did not find any evidence of anything. Actually, not even asm code at all - let alone asm code using such an instruction.

Originally Posted by Thomas Richter

Load-linked / store conditional is another primitive you use there. It is less complex than conditional exchange, but it requires additional hardware resources.

CAS2 also requires additionnal hardware resources.

Originally Posted by Thomas Richter

Nope, not without blocking. That is pretty much the point. You can of course implement semaphores by means of TAS and then protect critical regions by a semaphore or a futex, but that's a blocking approach and less performing, and 68K does not have "linked load" for any other form of a two-operand exchange.

Instead of blocking, you will loop if the resource isn't available. It's the same. Taking a semaphore, doing the thing with normal instructions, releasing the semaphore, isn't much slower than attempting to make the change, and loop until the change has been correctly made.

Originally Posted by Thomas Richter

Again, that wasn't important back then, but it is very important today with massive SMT.

This massive SMT is not done with asm code, and i doubt compilers will emit this particular instruction...

Originally Posted by Thomas Richter

A null-pointer reference will typically lead to a core dump in any sane system, yes, but a bounds check may or may not. The oberon compiler I mentioned does not cause a crash on a bounds violation.

Whether there is a core dump or not, does not change the thing we have an error situation, which is assimilable to a crash.

Originally Posted by Thomas Richter

The question is, how you count "most platforms?". Motorola had certainly more in vision than a games computer, the 68K market was quite a bit bigger. In some critical applications, it is quite important to have bounds checks and ordered recovery in case of violations. Not in toy systems like the Amiga, of course.

I counted most platforms except a few.
What are you defending here anyway ? The only systems still using 68k are "toy systems" and the embedded, and none of these will need these instructions.

Originally Posted by Thomas Richter

You can fuse a "moveq #0,d0:move ..,d0" then. No worries about that. Wouldn't surprise me if Gunnar wouldn't be doing that.

Yes of course this is what Gunnar does.
Except that if you try :

 moveq #0,d0
 move.b d0,d0

or :

 moveq #0,d0
 move.b (a0,d0.w),d0

then it doesn't work, where the real instruction would.

Originally Posted by Thomas Richter

Coldfire has a very simple pipeline, it was designed for that. It's not a workstation processor, but its target market were embedded systems where CPU power consumption is important. On such a system, you don't use a complicated pipeline with opcode fusion.

And what does that change ? The usefulness of an instruction for the programmer, does not depend on implementation details - or at least it should not.

Originally Posted by Thomas Richter

Yet, this is what contemporary CPUs do all the time. They are risk-machines with a cisc-interpreter. Maybe it's "lazy", but it shows one important fact: You do not change the machine language lightly. All attempts to do that failed - x64 is an AMD extension of a 32-bit extension of a 16 bit extension of an 8 bit processor, and it is so successful because it kept legacy code working. All these "itanium" ideas were nice, but failed. Now, maybe, arm has enough critical mass to succeed (hopefully), but what kind of an argument is "code density" in a tiny tiny market like 68K legacy?

This whole discussion can be considered pointless due to the same reasons...
I like code density. It's one of my design goals. It has several benefits, even in a software vm. It's not about 68k market at all, actually, just that i want to code on something that's more developer friendly.

Originally Posted by Thomas Richter

No, it is not "followed" in a Haward design. It is in completely (physically isolated) memory, addressed through the function codes. That is pretty much the point of a Haward design.

First, you could start by spelling it correctly. "Haward" design does not exist. It is Harvard design.
Second, most - if not all - machines ever using a 68k weren't doing this. Actually the 68000 is not even able to really do this separation - MOVES got added later.

Originally Posted by Thomas Richter

Forgive me if Motorola envisioned also target markets where it does matter to have this separation, and thus designed the instruction set with such things in mind. You have a very Amiga-centric approach here, but that's just too narrow minded what 68K was about.

Amiga-centric, no. But all personal computers, embedded systems, and consoles, using a 68k, and most big machines too - if not all - implemented something that didn't make use of this separation.
Sorry, but this is a failed theory. The fact the design is this way does not make it more successful.
It's the same thing as the C vs X flags. Another nice, wrong theory.

Originally Posted by Thomas Richter

For PC-relative addressing, you would use the instruction/data function codes.

Except that you can not do that on the 68000, where function codes are not directly available.

Originally Posted by Thomas Richter

A-line is for operating system applications, and F-line is reserved for coprocessors. You know that of course.

Of course. But it does not mean all that space was really required, and eor would have taken less than a quarter of it.

Originally Posted by Thomas Richter

Apparently. Every instruction set is designed around compromises. This is just one of them. Risc instruction sets have other restrictions, such as being unable to load a full-bitwidth data into one register. You either have to use an indirection, or you have to use two loads to load the upper and lower bit, and assemble them. That is then the price for fixed-size instruction words.

It does not mean it is a bad idea to remove these restrictions when it's doable.

Originally Posted by Thomas Richter

It is useful, but a headache in CPU design. It increases latency, or complexity. It didn't matter for the 68K which is not able to restart instructions in all cases, and which is micro-coded all the way, but look at which jumps the 68040 has to do for exception processing of movem. 68060 got away with it, at the price of potentially causing double writes in some situations.

As you said yourself, instruction sets are designed around compromises

[Bruce Abbott]

Originally Posted by Thomas Richter

Yet, this is what contemporary CPUs do all the time. They are risk-machines with a cisc-interpreter. Maybe it's "lazy", but it shows one important fact: You do not change the machine language lightly. All attempts to do that failed...

As would this one. But meynaf isn't trying to create a CPU, he's just making a VM with 68k-like opcodes. Why? I guess because he is familiar with 68k machine code and likes to code in it, as many of us do. You may say that this is pointless and bound to fail - and you are almost certainly right - if we were talking about wider adoption.

Many years ago I was working with Motorola MCUs, then wanted to use 8031 but didn't like Intel's mnemonics. So I created a Motorola style instruction set equivalent and coded with that. Great idea except I couldn't use anyone else's code or tools, so I capitulated and learned to use the Intel mnemonics.

That's what you have to do when living in the real world. But meynaf is apparently creating a little fantasy world for his own amusement. The fact that it has no application for Amiga users (or anyone else probably) doesn't concern him.

Now, maybe, arm has enough critical mass to succeed (hopefully), but what kind of an argument is "code density" in a tiny tiny market like 68K legacy?

Unless the improvement is dramatic enough to significantly reduce hardware requirements or the code has to fit into some specific environment it's pointless, except for aesthetics.

It is interesting to compare the concerns of Amiga developers to those on other platforms. We think 1MB of program code is a lot, but on a modern PC it's a pittance. Windows 10 uses several Gigabytes just to start up, and a fairly plain looking web page may require 1GB on a modern browser. This bloat is affecting stuff ported the Amiga as well, but what can you do when the original code was written without any attempt to minimize memory usage?

At the other end of the scale I have done a lot of work with MCUs that only had 1k of ROM or less and a few bytes of RAM. That's when you learn to make every byte count! But embedded developers today just buy a bigger faster chip, which is cheaper than spending the time to make your code more efficient. And with all the code written in C it's not hard to switch to a totally different CPU.

This thread isn't really about any practical application of an extended 68k CPU (certainly not for Amiga anyway), but more someone's dream of their ideal 68k-like ISA. This is in the finest tradition of Amigans ranting on about what Amiga shoulda coulda woulda been if Commodore wasn't in charge - with every person having their own ideas. So let's hear those ideas!

[meynaf]

Originally Posted by Bruce Abbott

As would this one. But meynaf isn't trying to create a CPU, he's just making a VM with 68k-like opcodes. Why? I guess because he is familiar with 68k machine code and likes to code in it, as many of us do. You may say that this is pointless and bound to fail - and you are almost certainly right - if we were talking about wider adoption.

What ? Are you telling i'm not gonna take over the world and impose my cpu everywhere ?

[Bruce Abbott]

Originally Posted by Thomas Richter

A-line is for operating system applications,

I thought Line-A was for extending the instruction set. But of course once that was provided it couldn't be used for extending the actual instruction set in future CPUs, because existing applications might be using it.

On the Amiga at least one language (Blitz BASIC) uses it, but it may not use all possible opcodes. Therefore it should be possible to simulate new instructions through Line-A, then when we are happy with them produce a new CPU with native versions that don't go through the exception vector. Just avoid the opcodes used by popular legacy code, then tell developers not to use the ones we have allocated.

But what do we really want? That's right - programmable microcode! Then we can load in our own custom instructions with total flexibility and without compromising compatibility. Imagine c2p in a single instruction, customized to suit the particular screen mode. Or DSP functions, built in mpeg decoding, encryption etc. Or even a completely different ISA. And we already have the hardware to do it.

[Thomas Richter]

Originally Posted by meynaf

CPU exceptions and high level language exceptions are two different things.

Yes, without any doubt, but I was talking here about "exception" in the microprocessor sense. Exceptions may be used to indicate errors, but not necessarily so. The same goes for C++ exceptions, of course.

Originally Posted by meynaf

I have looked it up and did not find any evidence of anything. Actually, not even asm code at all - let alone asm code using such an instruction.

I already pointed you to compilers using it.

Originally Posted by meynaf

CAS2 also requires additionnal hardware resources.

Certainly. Multi-core processing always does, you need additional primiives. I am not saying one is better than the other, just that you need one. CAS alone is not sufficient, you need some primitive in the sense of CAS2 that allows atomic exchange of two pointers/one pointer and a number.

Originally Posted by meynaf

Instead of blocking, you will loop if the resource isn't available. It's the same. Taking a semaphore, doing the thing with normal instructions, releasing the semaphore, isn't much slower than attempting to make the change, and loop until the change has been correctly made.

Nope. In the regular code path, without conflicts, the CAS just runs through. The TAS is an additional operation. There are reasons why these primitives are important in multi-core systems.

Originally Posted by meynaf

This massive SMT is not done with asm code, and i doubt compilers will emit this particular instruction...

Wrong. And yes, compilers support it of course. On the x64, you also have the "lock prefix", something the 68K misses, which makes many atomic operations simple. A standard atomic increment is an increment with lock prefix. On the 68K, you cannot do that, you need a load/increment/cas loop. Check what the gcc generates from <std::atomic>.

Originally Posted by meynaf

Whether there is a core dump or not, does not change the thing we have an error situation, which is assimilable to a crash.

Again, no. An exception is a tool, which may indicate an error situation, but not necessarily.

Originally Posted by meynaf

I counted most platforms except a few.
What are you defending here anyway ? The only systems still using 68k are "toy systems" and the embedded, and none of these will need these instructions.

Then what is this thread about? Unrealistic bull? None of that will materialize.

Originally Posted by meynaf

And what does that change ? The usefulness of an instruction for the programmer, does not depend on implementation details - or at least it should not.

Its not exactly needed in the sense the code with it can be as fast as the code without it.

Originally Posted by meynaf

Second, most - if not all - machines ever using a 68k weren't doing this. Actually the 68000 is not even able to really do this separation - MOVES got added later.

MOVES is supervisor only, and it is needed by the operating system to place data or code in particular segments. It is a very needed instruction for the Os, and for that reason it is super-only.

Originally Posted by meynaf

Amiga-centric, no. But all personal computers, embedded systems, and consoles, using a 68k, and most big machines too - if not all - implemented something that didn't make use of this separation.

Right, but this wasn't the perspective from which 68K was designed. If you design it from a different perspective, well, you through the design goals overboard, and you end up with something different (obviously).

Originally Posted by meynaf

Sorry, but this is a failed theory. The fact the design is this way does not make it more successful.
It's the same thing as the C vs X flags. Another nice, wrong theory.

Again, you are making assumptions.

Originally Posted by meynaf

Except that you can not do that on the 68000, where function codes are not directly available.

Ah, what? Of course they are available as hardware signals, on dedicated pins of the chip.

Originally Posted by meynaf

Of course. But it does not mean all that space was really required, and eor would have taken less than a quarter of it.

Mot made a different estimate. I don't need eor often enough (unlike add or sub) to justify that.

Originally Posted by meynaf

As you said yourself, instruction sets are designed around compromises

Yes, and I don't want to add to remove anything. I am just saying, would one develop an instruction set similar to the 68K today, with what we know today about CPU design, this instruction would likely go.

[Thomas Richter]

Originally Posted by Bruce Abbott

I thought Line-A was for extending the instruction set.

Correct, for the user to extend it. It is just a different perspective to the same thing. One can either say, "line A" triggers a subroutine, or an Os call, or one could say that this operation the line A performs extends the instruction set by an "instruction" that implements the corresponding operation. Apple used that for Os calls. Atari did that for its blitter emulation (which became hardware later).


Thus, line-a is user-reserved, not motorola-reserved. Line-F is reserved for motorola, not for the user.

Originally Posted by Bruce Abbott

But what do we really want? That's right - programmable microcode! Then we can load in our own custom instructions with total flexibility and without compromising compatibility. Imagine c2p in a single instruction, customized to suit the particular screen mode. Or DSP functions, built in mpeg decoding, encryption etc. Or even a completely different ISA. And we already have the hardware to do it.

I do not want that - it is just more incompatibility. The Amiga is what it is. A new microcode just creates more islands of lacking compatibility, software that excludes various users instead of including them, and that is the wrong thing of doing on a small target market.


If I would create a new CPU, well, that would look totally different, but I don't, and I won't.

[meynaf]

Originally Posted by Thomas Richter

Yes, without any doubt, but I was talking here about "exception" in the microprocessor sense. Exceptions may be used to indicate errors, but not necessarily so. The same goes for C++ exceptions, of course.

The big difference is how a handler can be installed. C++ exceptions need no supervisor code for that.

Originally Posted by Thomas Richter

I already pointed you to compilers using it.

Nah, i don't think so. And even if a compiler does that, where's the point ? Should an instruction be created just to satisfy the needs of a few compilers ?

Originally Posted by Thomas Richter

Certainly. Multi-core processing always does, you need additional primiives. I am not saying one is better than the other, just that you need one. CAS alone is not sufficient, you need some primitive in the sense of CAS2 that allows atomic exchange of two pointers/one pointer and a number.

But perhaps this feature is by itself a bad idea.
Accessing same structure from several concurrently running threads is usually looking for trouble.
Sometimes it is necessary, but... that's rare.
Should we create an instruction for a rare case ?

Originally Posted by Thomas Richter

Nope. In the regular code path, without conflicts, the CAS just runs through. The TAS is an additional operation. There are reasons why these primitives are important in multi-core systems.

The cost of the additionnal operation is hardly ever time critical.
Besides, CAS2 is a microcode monster and it is S.L.O.W.

Originally Posted by Thomas Richter

Wrong. And yes, compilers support it of course. On the x64, you also have the "lock prefix", something the 68K misses, which makes many atomic operations simple. A standard atomic increment is an increment with lock prefix. On the 68K, you cannot do that, you need a load/increment/cas loop. Check what the gcc generates from <std::atomic>.

There exists a compiler targeting 68k that supports c++11 now ? And one that will emit a CAS2 ? I want to see that.

Originally Posted by Thomas Richter

Again, no. An exception is a tool, which may indicate an error situation, but not necessarily.

And again, this is for a high level exception, not a cpu exception.

Originally Posted by Thomas Richter

Then what is this thread about? Unrealistic bull? None of that will materialize.

This thread is about ideas for an extended 68k, no more no less. That it will materialize or not is irrelevant.

Originally Posted by Thomas Richter

Its not exactly needed in the sense the code with it can be as fast as the code without it.

The same can be said about many instructions, actually - including those you defend here (f.e. chk, trapcc).
But at least this one makes asm programmer's life easier. Concentrating on "fast" aspect of the thing is very reductive.

... apart that during all that time code without it isn't really as fast as code with it.
For example, it is common to merge an instruction with a branch going over it. If it's already a merged instruction, it no longer works.
Not to mention the lowered pressure on icache bandwidth.

Originally Posted by Thomas Richter

MOVES is supervisor only, and it is needed by the operating system to place data or code in particular segments. It is a very needed instruction for the Os, and for that reason it is super-only.

But its not available for 68000, that was the point.

Originally Posted by Thomas Richter

Right, but this wasn't the perspective from which 68K was designed. If you design it from a different perspective, well, you through the design goals overboard, and you end up with something different (obviously).

I thought it was obvious that i indeed design it from a different perspective.

Originally Posted by Thomas Richter

Again, you are making assumptions.

Which are ?

Originally Posted by Thomas Richter

Ah, what? Of course they are available as hardware signals, on dedicated pins of the chip.

Of course i meant not available from a software point of view (on the 68000).

Originally Posted by Thomas Richter

Mot made a different estimate. I don't need eor often enough (unlike add or sub) to justify that.

That's ok, if orthogonality has no value.

Originally Posted by Thomas Richter

Yes, and I don't want to add to remove anything. I am just saying, would one develop an instruction set similar to the 68K today, with what we know today about CPU design, this instruction would likely go.

If you remove movem, then the instruction set would cease to be similar to the 68k. Remember original design goal of 68k, it is to ease coding in asm - removing that instruction goes totally against this.

[Thomas Richter]

Originally Posted by meynaf

The big difference is how a handler can be installed. C++ exceptions need no supervisor code for that.

Certainly not, no. It is a completely different use of the word "exception".

Originally Posted by meynaf

And even if a compiler does that, where's the point ? Should an instruction be created just to satisfy the needs of a few compilers ?

Heck, no. Just that you were saying that the instruction is "useless", though I pointed you to a case where it is used. This is the status quo. If you would create a CPU today, as said, it would look totally different. But that's a different game. I do not quite understand what the goal of this thread is supposed to be.

Originally Posted by meynaf

But perhaps this feature is by itself a bad idea.
Accessing same structure from several concurrently running threads is usually looking for trouble.

The goal is to speed up algorithms by SMP, and SMP requires synchronization primitives. Of course, you want to use as little of them as possible, but you need them. This is where the development of CPUs is going - massively parallel, as the speed race is over.

Originally Posted by meynaf

Should we create an instruction for a rare case ?

Yes, as you cannot synchronize data between CPUs in any other way. So some support is needed.

Originally Posted by meynaf

The cost of the additionnal operation is hardly ever time critical.
Besides, CAS2 is a microcode monster and it is S.L.O.W.

In the legacy 68K it is, but if one would design a CPU with the needs of today, you would not microcode it, obviously.

Originally Posted by meynaf

There exists a compiler targeting 68k that supports c++11 now ? And one that will emit a CAS2 ? I want to see that.

g++ exists for 68K, and its atomic operations would likely use cas for std::atomic<int> and cas2 for std:atomic<long long>, at least this is my best guess. That, or a protection through TAS, which is a tad slower and requires one additional byte for the storage of the state.


But why do you insist on "an existing compiler"? I thought this discussion would be academic in first place?

Originally Posted by meynaf

This thread is about ideas for an extended 68k, no more no less. That it will materialize or not is irrelevant.

Then you need a CAS2 and a CAS.




[QUOTE=meynaf;1447308]


The same can be said about many instructions, actually - including those you defend here (f.e. chk, trapcc).
[/QOUTE]
Look, what you don't appreciate is that mot created this instruction set with a particular mindset, and that there was - back then - a use case for them. Ok, put that overboard. You get a different architecture. But then, if you want a new architecture to begin with (which is insane, but anyhow), you should address all deficiencies of the 68K right at the beginning, and make it fit for 2021. That implies support for multiprocessing, and this requires some form of synchronization primitive.

Originally Posted by meynaf

But its not available for 68000, that was the point.

Function codes are available for the 68K, that is the point.

Originally Posted by meynaf

I thought it was obvious that i indeed design it from a different perspective.

Which is what? For a toy system like the Amiga? If you design for that, the best design is not to change the design, because that will break legacy software the least. If you design for a new system, then address the needs of 2021.

Originally Posted by meynaf

Of course i meant not available from a software point of view (on the 68000).

They are also available from the software side. As stated, it makes a difference on the Atari ST, rightfully so.

Originally Posted by meynaf

That's ok, if orthogonality has no value.

Then you would need that for any other type of instruction as well. Shifts? Rols? Mul? Div? Why stop there?

Originally Posted by meynaf

If you remove movem, then the instruction set would cease to be similar to the 68k.

Why is that an issue? If you remove CHK, the instruction set would cease to be similar to the 68K either.

Originally Posted by meynaf

Remember original design goal of 68k, it is to ease coding in asm - removing that instruction goes totally against this.

No, that is not the design goal of the 68k. The design goal of the 68K was to make the life of (contemporary) compiles easy. There are many constructions in the 68K that support high languages. That's why we have LINK, UNLK, JSR, no link register, indirection with offset, indirection with data register, and also why we have TRAPV, TRAPcc and CHK (check for overflows and react, checked array bounds).


Assembler was already going out of fashion at the time of the 68K. Assembler was the domain of the 6800.

[meynaf]

Originally Posted by Thomas Richter

Certainly not, no. It is a completely different use of the word "exception".

Seems we are not speaking about the same thing.

Originally Posted by Thomas Richter

Heck, no. Just that you were saying that the instruction is "useless", though I pointed you to a case where it is used. This is the status quo. If you would create a CPU today, as said, it would look totally different. But that's a different game. I do not quite understand what the goal of this thread is supposed to be.

If you do not understand what the goal of this thread is supposed to be, why participating at first place ?

Originally Posted by Thomas Richter

The goal is to speed up algorithms by SMP, and SMP requires synchronization primitives. Of course, you want to use as little of them as possible, but you need them. This is where the development of CPUs is going - massively parallel, as the speed race is over.

This is what i meant. You want to use as little of them as possible. There is a good reason for that.

Originally Posted by Thomas Richter

Yes, as you cannot synchronize data between CPUs in any other way. So some support is needed.

There are many other ways. Not all CPUs that are multi-core in the world have this instruction. So some support yes, but not necessarily this one.

Originally Posted by Thomas Richter

In the legacy 68K it is, but if one would design a CPU with the needs of today, you would not microcode it, obviously.

I remember having discussed with Gunnar about this one. Seems it's not among the easiest to do in HW, let alone without microcode.
It's probably microcoded even with todays x86.

Originally Posted by Thomas Richter

g++ exists for 68K, and its atomic operations would likely use cas for std::atomic<int> and cas2 for std:atomic<long long>, at least this is my best guess. That, or a protection through TAS, which is a tad slower and requires one additional byte for the storage of the state.

Yes g++ exists, but it's old enough. This std::atomic stuff starts with C++11.

Originally Posted by Thomas Richter

But why do you insist on "an existing compiler"? I thought this discussion would be academic in first place?

It was in reply to "compilers support it of course". I supposed it was existing support. But maybe not ?

Originally Posted by Thomas Richter

Then you need a CAS2 and a CAS.

I have CAS.

Originally Posted by Thomas Richter

Look, what you don't appreciate is that mot created this instruction set with a particular mindset, and that there was - back then - a use case for them. Ok, put that overboard. You get a different architecture. But then, if you want a new architecture to begin with (which is insane, but anyhow), you should address all deficiencies of the 68K right at the beginning, and make it fit for 2021. That implies support for multiprocessing, and this requires some form of synchronization primitive.

Yes i have addressed all deficiencies of the 68k right at the beginning - and lack of sync stuff isn't among them.
Yes this gives me a different architecture in some way, yet still very similar. Isn't it what this thread is all about ?
And yes i have support for multiprocessing and some form of synchronization primitive (actually several). Not that the vm currently uses that, however.

Originally Posted by Thomas Richter

Function codes are available for the 68K, that is the point.

In hardware only. Not in software (at least, not until 68020). And thus it is NOT ENOUGH for making it a true Harvard design.

Originally Posted by Thomas Richter

Which is what? For a toy system like the Amiga? If you design for that, the best design is not to change the design, because that will break legacy software the least. If you design for a new system, then address the needs of 2021.

The needs of 2021 aren't very different than the needs of before. Some use cases have disappeared, others have appeared, and this is exactly why i concentrate on general purpose instructions rather than specialized ones.

Originally Posted by Thomas Richter

They are also available from the software side. As stated, it makes a difference on the Atari ST, rightfully so.

Software on 68000 can not use a pointer in memory to use PC-relative space, so no, they are not avaialble from the software side.
What makes the difference on the Atari ST is supervisor vs user, not PC relative or not - which does not make a difference there (data section is always right after text section).

Originally Posted by Thomas Richter

Then you would need that for any other type of instruction as well. Shifts? Rols? Mul? Div? Why stop there?

As a recall, orthogonality is same addressing modes for same kind of instruction, not same addressing modes for all instructions.
So yes, shifts and rols are similar and have same modes. Ditto for mul & div.
And of course and/or/eor are all logical operations and support same modes.

Originally Posted by Thomas Richter

Why is that an issue? If you remove CHK, the instruction set would cease to be similar to the 68K either.

This instruction plays absolutely no role in current programs, contrary to movem. I have disassembled megabytes of code and found thousands of movem and one chk (which was not even used for bound checking, but to trigger a deliberate exception).
Hence removing chk does not change the way you code on the cpu - but believe me that with movem removed it would become night and day.

Originally Posted by Thomas Richter

No, that is not the design goal of the 68k. The design goal of the 68K was to make the life of (contemporary) compiles easy. There are many constructions in the 68K that support high languages. That's why we have LINK, UNLK, JSR, no link register, indirection with offset, indirection with data register, and also why we have TRAPV, TRAPcc and CHK (check for overflows and react, checked array bounds).

Assembler was already going out of fashion at the time of the 68K. Assembler was the domain of the 6800.

Sorry, but this is just plain wrong. Read original 68000 design documents.

[Thomas Richter]

Originally Posted by meynaf

Seems we are not speaking about the same thing.

I am talking about CPU exceptions. They only crash if they are not handled. Actually, C++ exceptions also crash the program if they are not handled. Whether an exception crashes is thus not a matter of the exception, but a matter of whether there is some way of recovering from them.

Originally Posted by meynaf

If you do not understand what the goal of this thread is supposed to be, why participating at first place ?

Why do you create a pointless thread? There will be no consequence of it - not that you are creating a CPU, and not that this is of any relevance to the Amiga.


There are two possible routes: Think about what is important for the Amiga. For the Amiga, nothing of that is of any relevance. It would just create more islands of incompatibility, which makes little sense.


If you think about 68K in general, then there are many more things that are more important than "additional addressing modes for eor". What would be much more important would be 64 wide registers, and larger addressing spaces.


However, these two goals are mutually exclusive. A modern 68K, and something that is useful for the Amiga.

Originally Posted by meynaf

This is what i meant. You want to use as little of them as possible. There is a good reason for that.

Yes, but that is more because coupling between CPUs happens only if the job is hard to parallelize. So it is not "you want to avoid the instruction", but rather "algorithms that require a lot of them are hard to parallelize in first place".

Originally Posted by meynaf

There are many other ways. Not all CPUs that are multi-core in the world have this instruction. So some support yes, but not necessarily this one.

Right, though 68K already has made this particular choice, the same choice x86 made.

Originally Posted by meynaf

I remember having discussed with Gunnar about this one. Seems it's not among the easiest to do in HW, let alone without microcode.
It's probably microcoded even with todays x86.

Of course it hard to support, leave alone because it requires a bus cycle that indicates the lock; on the Amiga, it is all irrelevant because you cannot use CAS and friends anyhow. Zorro does not support RMW-cycles.

Originally Posted by meynaf

Yes g++ exists, but it's old enough. This std::atomic stuff starts with C++11.

To my knowledge, the 68K target still exists.

Originally Posted by meynaf

Yes i have addressed all deficiencies of the 68k right at the beginning - and lack of sync stuff isn't among them.

Sync like CAS exists, though you would also need CAS2, and you would need 64-bit wide data (and a 128 wide CAS, i.e. "CAS4").

Originally Posted by meynaf

Yes this gives me a different architecture in some way, yet still very similar. Isn't it what this thread is all about ?

Now tell me what you want to do with this information? You will not build a new CPU, and it wouldn't be useful for the Amiga either.

Originally Posted by meynaf

The needs of 2021 aren't very different than the needs of before.

*Cough* SMP-support. 64-bit support.

Originally Posted by meynaf

Software on 68000 can not use a pointer in memory to use PC-relative space, so no, they are not avaialble from the software side.

That doesn't mean that PC-relative addressing is pointless. A typical example is a lookup table interleaved into the program code, for example to implement a switch-case. There wouldn't be a pointer to it, just a a move.w d(PC,d0.w),dx or something like it.

Originally Posted by meynaf

What makes the difference on the Atari ST is supervisor vs user, not PC relative or not - which does not make a difference there (data section is always right after text section).

I do not know where the ST places its segments, but on the Amiga, it is wherever the scatter loader aka LoadSeg() places them. However, that is - as said - not a good design. Ideally, the text segment should go into a different memory type, or should be write-protected.

Originally Posted by meynaf

This instruction plays absolutely no role in current programs, contrary to movem.

Yet, there are programs that use them. Thus, what is exactly your goal? Break Amiga programs, ignore the Amiga? Create a new platform? Why? We already have better processor platforms. "Better" as in "actually available in hardware", not as a pipe dream.

Originally Posted by meynaf

I have disassembled megabytes of code and found thousands of movem and one chk (which was not even used for bound checking, but to trigger a deliberate exception).
Hence removing chk does not change the way you code on the cpu - but believe me that with movem removed it would become night and day.

Yes, but your point is? Either you keep things working, then you need to keep existing instructions. Or you don't, and then you can get rid of some instructions that are "in the way" of a fast design. movem is certainly hard to support.

[meynaf]

Originally Posted by Thomas Richter

I am talking about CPU exceptions. They only crash if they are not handled. Actually, C++ exceptions also crash the program if they are not handled. Whether an exception crashes is thus not a matter of the exception, but a matter of whether there is some way of recovering from them.

But handling a C++ exception does not require going to supervisor mode. It's definitely not the same thing.

Originally Posted by Thomas Richter

Why do you create a pointless thread? There will be no consequence of it - not that you are creating a CPU, and not that this is of any relevance to the Amiga.

I did not create this thread.

Originally Posted by Thomas Richter

There are two possible routes: Think about what is important for the Amiga. For the Amiga, nothing of that is of any relevance. It would just create more islands of incompatibility, which makes little sense.

If you think about 68K in general, then there are many more things that are more important than "additional addressing modes for eor". What would be much more important would be 64 wide registers, and larger addressing spaces.

However, these two goals are mutually exclusive. A modern 68K, and something that is useful for the Amiga.

Why would i choose one of these roads ? Amiga isn't my only concern, and i certainly don't want to go "modern" the same way everyone else did.
So at the end : neither of these.

Originally Posted by Thomas Richter

Yes, but that is more because coupling between CPUs happens only if the job is hard to parallelize. So it is not "you want to avoid the instruction", but rather "algorithms that require a lot of them are hard to parallelize in first place".

Whatever the reason is, i don't really care much. The important thing is that this kind of instruction isn't used often.

Originally Posted by Thomas Richter

Right, though 68K already has made this particular choice, the same choice x86 made.

'xcept that 68k actually dropped it afterwards.

Originally Posted by Thomas Richter

Of course it hard to support, leave alone because it requires a bus cycle that indicates the lock; on the Amiga, it is all irrelevant because you cannot use CAS and friends anyhow. Zorro does not support RMW-cycles.

Right. Even though i tried to catch this kind of cycle failing on my A1200 and couldn't - even in chipmem.

Originally Posted by Thomas Richter

To my knowledge, the 68K target still exists.

Yes, but not exactly up to date.

Originally Posted by Thomas Richter

Sync like CAS exists, though you would also need CAS2, and you would need 64-bit wide data (and a 128 wide CAS, i.e. "CAS4").

No i don't need CAS2, neither do i need 64-bit wide data - and especially not with cmpxchg16b or cas2.q.

Originally Posted by Thomas Richter

Now tell me what you want to do with this information? You will not build a new CPU, and it wouldn't be useful for the Amiga either.

I have a VM that works and it runs on the Amiga. So in some way i have built a new CPU, and when/if made fast enough, it will be useful for the Amiga as well.

Originally Posted by Thomas Richter

*Cough* SMP-support. 64-bit support.

No, these are just driven by marketing needs to faster execute badly written programs, and the failure of cpu manufacturers to achieve faster single threaded execution.
In any case, they are not required on a 68k-like machine.

Originally Posted by Thomas Richter

That doesn't mean that PC-relative addressing is pointless. A typical example is a lookup table interleaved into the program code, for example to implement a switch-case. There wouldn't be a pointer to it, just a a move.w d(PC,d0.w),dx or something like it.

I haven't said PC-relative mode is pointless, just that the 68000 can't do accesses of data like if it was code (contrary to 68020 which has mode with zpc and moves instruction).

Originally Posted by Thomas Richter

I do not know where the ST places its segments, but on the Amiga, it is wherever the scatter loader aka LoadSeg() places them. However, that is - as said - not a good design. Ideally, the text segment should go into a different memory type, or should be write-protected.

ST places its segments (text, data and bss in that order) in single memory allocation - actually a ST program reserves all available memory and you have to issue a call to give some back to the system. So in some way it's even worse.
Yet i can say that write protecting the code isn't very useful and both ways are ok for me.

Originally Posted by Thomas Richter

Yet, there are programs that use them.

I still have to see one.

Originally Posted by Thomas Richter

Thus, what is exactly your goal? Break Amiga programs, ignore the Amiga? Create a new platform? Why? We already have better processor platforms. "Better" as in "actually available in hardware", not as a pipe dream.

Break Amiga programs, no. Ignore the Amiga, no. But create a new platform, yes.
No, we don't have better processor platforms.
And my vm, though not finished there, also works on common pc hardware.

Originally Posted by Thomas Richter

Yes, but your point is? Either you keep things working, then you need to keep existing instructions. Or you don't, and then you can get rid of some instructions that are "in the way" of a fast design. movem is certainly hard to support.

Didn't i mention binary compatibility wasn't my goal ? Therefore, i don't need to keep existing instructions.
About getting rid of instructions that are "in the way", why do you think i didn't keep cmp2/chk2/cas2.
About removing movem, certainly not. It represents nearly 1 instruction out of 50. Widely used instructions must not be removed. Even if this one is only second to the Bitfields when it comes to complexity of implementation.

[Bruce Abbott]

Originally Posted by meynaf

I have a VM that works and it runs on the Amiga. So in some way i have built a new CPU, and when/if made fast enough, it will be useful for the Amiga as well.

How so?

[meynaf]

Originally Posted by Bruce Abbott

How so?

Like my system framework. Something transparent to users, but allowing me to code easier. And that other coders might end up using too eventually. See it as just another programming language.

[Thomas Richter]

Originally Posted by meynaf

But handling a C++ exception does not require going to supervisor mode. It's definitely not the same thing.

No, it is not the same thing, but there are commonalities. As in "if handled, completely harmless" and "a worthwhile tool, not only for exceptions".

Originally Posted by meynaf

Why would i choose one of these roads ? Amiga isn't my only concern, and i certainly don't want to go "modern" the same way everyone else did.
So at the end : neither of these.

So what's the point?

Originally Posted by meynaf

Whatever the reason is, i don't really care much. The important thing is that this kind of instruction isn't used often.

Yet, it's essential in the sense that you cannot do without it on multi-core systems. One can replace a movem by multiple moves. But one cannot replace RMW-instructions by anything else but another locked RMW-instruciton.

Originally Posted by meynaf

'xcept that 68k actually dropped it afterwards.

On the 68060, CAS2 was dropped. Back then, it wasn't important, of course. There were no multi-core 68K systems, so the thing was irrelevant. Back then.

Originally Posted by meynaf

No i don't need CAS2, neither do i need 64-bit wide data - and especially not with cmpxchg16b or cas2.q.

You don't, but I do. Not on the Amiga, though.

Originally Posted by meynaf

I have a VM that works and it runs on the Amiga. So in some way i have built a new CPU, and when/if made fast enough, it will be useful for the Amiga as well.

Gimme a break. Someone arguing that "every cycle is important" programs on a VM? Why not program the real thing? Why waste so much computing power for a VM?

Originally Posted by meynaf

No, these are just driven by marketing needs to faster execute badly written programs, and the failure of cpu manufacturers to achieve faster single threaded execution.

Oh dear... You can hardly get a smart phone without 64bit cores, and more than one of them. That's not "badly written programs", but "expectations of the user". Oh, and you certainly need more RAM for a VM. Isn't that just a badly written program - a program that doesn't run on its target platform natively?

Originally Posted by meynaf

In any case, they are not required on a 68k-like machine.

That depends on your goals. If you would want to modernize 68K and make it ready for SMP, then that would be the way to go.

Originally Posted by meynaf

Yet i can say that write protecting the code isn't very useful and both ways are ok for me.

Certainly useful enough for any sane operating system available today.

Originally Posted by meynaf

Break Amiga programs, no. Ignore the Amiga, no. But create a new platform, yes.

Then why start from a yesterday's processor? With a restricted 32 bit address space?

Originally Posted by meynaf

No, we don't have better processor platforms.

Certainly we do. A lot faster, more powerful.

Originally Posted by meynaf

And my vm, though not finished there, also works on common pc hardware.

Oh, wasting the power of the fast x64 CPU to run a VM? How much sense does that make? Sounds like contradicting your goals.

Originally Posted by meynaf

Didn't i mention binary compatibility wasn't my goal ? Therefore, i don't need to keep existing instructions.

Then, who do you think will jump on it? Why? Where's the market? We have sufficient CPU platforms to begin with.

Originally Posted by meynaf

About getting rid of instructions that are "in the way", why do you think i didn't keep cmp2/chk2/cas2.

Lack of vision? Lack of insight? Don't ask me. I would keep them, in particular CAS2 as I really have needs for it. Not on the Amiga, of course. Looks like a serious drawback.

[meynaf]

Originally Posted by Thomas Richter

No, it is not the same thing, but there are commonalities. As in "if handled, completely harmless" and "a worthwhile tool, not only for exceptions".

It is harmless even if not handled, actually.
And all this just to defend completely obsolete CHK...

Originally Posted by Thomas Richter

So what's the point?

I am afraid trying to explain it wouldn't be very useful. Your mind is already set and will not change.

Originally Posted by Thomas Richter

Yet, it's essential in the sense that you cannot do without it on multi-core systems. One can replace a movem by multiple moves. But one cannot replace RMW-instructions by anything else but another locked RMW-instruciton.

Perhaps i have other locked RMW-instructions. Or perhaps i have invented an innovative way to arrange so that it is not needed anymore. Who knows.

Originally Posted by Thomas Richter

On the 68060, CAS2 was dropped. Back then, it wasn't important, of course. There were no multi-core 68K systems, so the thing was irrelevant. Back then.

There is still no multi-core 68k systems as of today.

Originally Posted by Thomas Richter

You don't, but I do. Not on the Amiga, though.

Why should i care about what you use or not ?

Originally Posted by Thomas Richter

Gimme a break. Someone arguing that "every cycle is important" programs on a VM? Why not program the real thing? Why waste so much computing power for a VM?

The "every cycle is important" - which i haven't really written, btw - is sometimes true but it depends on the machine we're considering.
Why not program the real thing, simply because it's an horror.
Why waste so much computing power on a VM, guess what, programs may end up faster than native ones simply because it's not hard to beat bloatware.
Anyway it's a machine where it is commonplace to stack software layers on top of other software layers, so at the end it's the same.

Originally Posted by Thomas Richter

Oh dear... You can hardly get a smart phone without 64bit cores, and more than one of them. That's not "badly written programs", but "expectations of the user".

No. Really not. The user does not expect "64bit cores". The user expects a smart phone doing its smart phone job. The technology behind doesn't matter.

Originally Posted by Thomas Richter

Oh, and you certainly need more RAM for a VM. Isn't that just a badly written program - a program that doesn't run on its target platform natively?

And yet this program will actually use less resources than a native one. Because the native one is really badly written.

Originally Posted by Thomas Richter

That depends on your goals. If you would want to modernize 68K and make it ready for SMP, then that would be the way to go.

68k is already ready for SMP. It does not need any change for that.
But as i said, my goal isn't 68k compatibility. I just wanted to take from 68k what i like, and make a better thing.

Originally Posted by Thomas Richter

Certainly useful enough for any sane operating system available today.

Operating systems available today are everything but sane.

Originally Posted by Thomas Richter

Then why start from a yesterday's processor? With a restricted 32 bit address space?

Because yesterday's processor was better in many ways ? Because i can get the best of both worlds by having 32 bit logical space with 64 bit - or whatever - physical one ?

Originally Posted by Thomas Richter

Certainly we do. A lot faster, more powerful.

But with no control anymore on what happens in them. More powerful but could be sending spam without user to notice. Machines that don't belong to their users anymore. With considerably reduced life duration. And of course, a PITA to program. Sorry but it's not my definition of "better".

Originally Posted by Thomas Richter

Oh, wasting the power of the fast x64 CPU to run a VM? How much sense does that make? Sounds like contradicting your goals.

My goals are not just about "speed", contrary to many people. So it's not contradicting anything.
Yes in some way it does not have much sense but guess what : it's the only solution. If no cpu gets implemented with a decent ISA today its not my fault. I do with what i can use.
Anyhow, tell that to Java or .Net users.

Originally Posted by Thomas Richter

Then, who do you think will jump on it? Why? Where's the market? We have sufficient CPU platforms to begin with.

I don't need anyone to jump on it - at least, not now. And i pay no care about the market.

Originally Posted by Thomas Richter

Lack of vision? Lack of insight? Don't ask me. I would keep them, in particular CAS2 as I really have needs for it. Not on the Amiga, of course.

I lack neither vision nor insight, but i can understand why you think so. I would be pleased if you cease writing such things, though.
Now, keep CAS2 if you want and be happy with it - i don't want you to change that, even if it would be better if you tried to envision how an ideal machine would be, without paying too much attention on current technology. Then perhaps we would be able to really talk.

Originally Posted by Thomas Richter

Looks like a serious drawback.

But it's not. The drawback isn't located at not having a CAS2 or similar instruction. The drawback is the reason why one would want such an instruction at first place.

Now a question if you don't mind. Why do you insist so much for imposing your point of view on something you obviously won't be using ? Don't tell me you fear it's gonna be used some day, so much that you'll be forced to use it too

[Gorf]

Originally Posted by Thomas Richter

Heck, no. Just that you were saying that the instruction is "useless", though I pointed you to a case where it is used. This is the status quo. If you would create a CPU today, as said, it would look totally different. But that's a different game. I do not quite understand what the goal of this thread is supposed to be.

Well - I started this thread to ask the coders here, what they think about my (maybe cumbersome) ideas - these are not 100% 68k centric, but as the provided examples show, these ideas would be applicable there as well.

It is of course just a hobby project - staring with a simplistic VM and maybe going FPGA one day.
The complexity of something like the 68000 is probably the upper limit for such a project ...

As meynaf's vm for him my project is for my personal use - I am not trying to convince you of anything or getting others to use it.

That said: I enjoy the discussion it spawned!

[Gorf]

There is still no multi-core 68k systems as of today.

The Sony NEWS workstations had two 68020s (later 68030s) - but not in SMP configuration.
https://en.wikipedia.org/wiki/Sony_NEWS

The Apple MacII had a 68020 and for NuBus development a 68000 on a card running A/ROSE with a 32bit preemptive multitasking kernel, which was quite more advanced than the System2 running on the MacII itself ...

https://en.wikipedia.org/wiki/A/ROSE

SMP is not the only way to do multicore:
AMP (Asymmetric Multi-Processing )
uAMP (unsupervised Asymmetric Multi-Processing)
BMP (Bound Multi-Processing)
Cluster (e.g. Lightwave on 68k)
...

The more cores you want to handle the less classic SMP is the best solution.

Operating systems available today are everything but sane.

sadly this is very true

[Thomas Richter]

Originally Posted by Gorf

The more cores you want to handle the less classic SMP is the best solution.

I disagree. Specialized processors only work well for one single job. A generic system with multiple cores works well for multiple applications. It offers more flexibilty than dedicated processors.

Originally Posted by Gorf

sadly this is very true

You hopefully don't attempt to convince me that AmigaOs is an "operating system", right?

[Gorf]

Originally Posted by Thomas Richter

I disagree. Specialized processors only work well for one single job. A generic system with multiple cores works well for multiple applications. It offers more flexibilty than dedicated processors.

I wrote nowhere anything about "specialized" or "dedicated" processors.
You seen to misunderstand the concept of SMP and why it is not working well for larger numbers of processors...
There is a reason why AMD an others are implementing NUMA ...

You hopefully don't attempt to convince me that AmigaOs is an "operating system", right?

Of course it is one, but with very many shortcomings, as you of all people would know.
And no: it is also not a "sane" one, even if it did some things right others did not back in the day - but this has only historical value from today’s point of view...
But that does not change the fact that all of today’s operating systems are totally crap and a insane mess.
Let’s see what Fuchsia brings...