Enhanced 68k ISA

[Megol]

Originally Posted by matthey

Is a <150MHz FPGA processor a modern processor? I agree that there is less advantage to a branch hint bit as the prediction technique gets better but high end processors have gshare/adaptive dynamic prediction (there is a several cycle latency with these techniques so it still could be useful in a few cases). More likely for 68k processors is 2 bit saturating or no dynamic prediction where a hint bit would be "useful" if faster executing code is considered "useful". It would be helpful to see some timed results of a variety of code executing with no dynamic prediction and with a hybrid 2 bit saturating with hint bit but everyone has already decided what is "useful". The cost of a hint bit on the 68k is so high that it is practically free but lets reject it as not "useful" even though most research shows a branch prediction improvement for practically free.

With "modern" I mean competent branch prediction. If then the design is stretched out over several huge FPGAs and running at an effective clock rate of 1MHz (similar to verification efforts of real processor designs before ASIC realization) doesn't matter.

The fact is hint bits doesn't help much, only for startup (first time a branch is seen) where a static prediction fails (backwards taken, forwards not taken). After it have been noticed by the branch predictor the hint doesn't matter anymore. The saving is in other words 1x branch mispredict penalty for cold code where branches doesn't follow the normal static prediction pattern.

To compare to some modern high-performance processors: some doesn't even do static prediction according to the branch direction, they just assume a never seen branch will not be taken. In other words some designers doesn't even think static predictions are worth the effort even though this have much higher overheads (e.g. one misprediction per loop).

We are talking of branches in code here where a 32 bit displacement already gives +-4 GB displacement. If all the code of the AmigaOS was combined into one executable it would probably not exceed this. If all the code which was released for cost on the Amiga in the first year was combined into one executable it would probably not exceed this. I don't think it would be a problem to divide code up into sections this small even if 64 bit addressing existed. The problem with PC relative addressing is not the branch displacement range but the code density deterioration and use of an expensive addressing mode because of a lack of range in PC relative addressing modes (beyond +-32kB). This is where the 2 new PC relative addressing modes proposed could practically eliminate both problems. Even then, 64 bit PC relative displacements are not necessary and would likely never be used. Code is much smaller than data even on modern processors.

I agree. Look at it as a similar choice as the RISC V being capable to expand to 128 bit address space. No it is not likely to be used much and even with 128 bit address space 64 bit (or even 32 bit) displacements/offsets should be enough for nearly everything.

[Mrs Beanbag]

maybe instead of introducing new user-mode instructions that existing software won't use, existing compilers/assemblers don't support &c... (plus what if someone else produces a competing 68k implementation? there is no guarantee they will respect your extensions)

How about just introducing support for more than one hardware thread, either by hyperthreading or dual-core. Instructions to support this could be supervisor-mode only so not affecting most developers (at least not OS-friendly ones!) An operating system patch would be required to take advantage of it, but then all existing software can benefit from improved multitasking performance.

[meynaf]

Originally Posted by Mrs Beanbag

How about just introducing support for more than one hardware thread, either by hyperthreading or dual-core. Instructions to support this could be supervisor-mode only so not affecting most developers (at least not OS-friendly ones!) An operating system patch would be required to take advantage of it, but then all existing software can benefit from improved multitasking performance.

You require a lot more than a few instructions and a simple system patch to do that !
What you are asking for here is called SMP and the OS is simply not adapted to this.

[Mrs Beanbag]

Originally Posted by meynaf

You require a lot more than a few instructions and a simple system patch to do that !
What you are asking for here is called SMP and the OS is simply not adapted to this.

of course, i didn't mean to suggest that all that would be required is a few more instructions. implementing a multi-core or hyperthreaded CPU would be far more involved than that. I only meant that any new instructions that were required could be made supervisor-privileged and thus no concern of the typical application programmer (although maybe some hardware-specific demo could use them!)

As for SMP, well maybe it need not be fully-symmetric multiprocessing, perhaps only one core/thread could be capable of supervisor mode thus the operating system itself would be restricted to single threaded operation, but since the OS already has programmer-abstracted multitasking (i.e. pre-emptive, not co-operative multitasking) how much trouble could it really cause if two user tasks or processes were running simultaneously on different cores? Not that i'm saying it would be a small feat. But really impossible? Eventually it will have to happen, if someone wants to bring 68k into the 21st century.

[meynaf]

Originally Posted by Mrs Beanbag

As for SMP, well maybe it need not be fully-symmetric multiprocessing, perhaps only one core/thread could be capable of supervisor mode thus the operating system itself would be restricted to single threaded operation (...)

The operating system does not normally run in supervisor mode.

Originally Posted by Mrs Beanbag

(...) how much trouble could it really cause if two user tasks or processes were running simultaneously on different cores?

Quite a lot of trouble. Consider two programs accessing the same list, especially with inline versions of Forbid/Disable.

[Mrs Beanbag]

Originally Posted by meynaf

The operating system does not normally run in supervisor mode.

ok but when it is switching/scheduling tasks surely it is?

Quite a lot of trouble. Consider two programs accessing the same list, especially with inline versions of Forbid/Disable.

without Forbid/Disable that would be potentially troublesome even just with pre-emptive multitasking on a single core. And i don't know what is meant by "inline versions" of these functions. not going through the Exec library to do this sounds like asking for trouble. But Exec's Forbid/Disable could be made to temporarily halt all other threads. This might not be optimal, but then again, how often does it happen?

[meynaf]

Originally Posted by Mrs Beanbag

ok but when it is switching/scheduling tasks surely it is?

When switching yes, when scheduling not necessarily. The OS goes into supervisor mode only when it is mandatory.

Originally Posted by Mrs Beanbag

without Forbid/Disable that would be potentially troublesome even just with pre-emptive multitasking on a single core.

That depends. A single instruction is atomic on a single core and this fact is used quite a lot.

Originally Posted by Mrs Beanbag

And i don't know what is meant by "inline versions" of these functions.

Something like addq.b #1,tdnestcnt(a6) or move.w #$4000,$dff09a.

Originally Posted by Mrs Beanbag

not going through the Exec library to do this sounds like asking for trouble.

The OS itself does it. Some apps probably also do.

Originally Posted by Mrs Beanbag

But Exec's Forbid/Disable could be made to temporarily halt all other threads. This might not be optimal, but then again, how often does it happen?

It's not that simple. You can't halt all other threads regardless of what they're doing : many cases can go haywire, like when some thread calls Disable while the main one is actually executing an interrupt...

Besides, the OS task lists are totally incompatible with multiple core - they're not designed for that at all.

[Mrs Beanbag]

Originally Posted by meynaf

When switching yes, when scheduling not necessarily. The OS goes into supervisor mode only when it is mandatory.

This whole mechanism will need recoding anyway...

That depends. A single instruction is atomic on a single core and this fact is used quite a lot.

x86 and other ISAs must have also had to get round this kind of thing somehow...

Something like addq.b #1,tdnestcnt(a6) or move.w #$4000,$dff09a.

The OS itself does it. Some apps probably also do.

Wherever the OS itself does it, can be patched. Ok maybe just a complete custom ROM!

It's not that simple. You can't halt all other threads regardless of what they're doing : many cases can go haywire, like when some thread calls Disable while the main one is actually executing an interrupt...

hmm i see your point... and if two cores execute mutually-problematic instructions at the same time, which gets priority? Then again, x86 et al must also have had to overcome this sort of thing, this doesn't seem like a 68k specific problem.

Besides, the OS task lists are totally incompatible with multiple core - they're not designed for that at all.

can we extend the task list in a way that doesn't break (most) old software?

While it's fruitful to think of all the problems i'm someone who prefers to imagine solutions. I'm just going to wait for a second opinion on this tbh because i'm a little out of my depth (but i'm a fast learner).

[meynaf]

Originally Posted by Mrs Beanbag

This whole mechanism will need recoding anyway...

If you fancy rewrite the whole kernel, just do it

Originally Posted by Mrs Beanbag

x86 and other ISAs must have also had to get round this kind of thing somehow...

They didn't have to - it's Amiga specific problem.

Originally Posted by Mrs Beanbag

Wherever the OS itself does it, can be patched. Ok maybe just a complete custom ROM!

Yeah, if the whole ROM is rewritten and all incompatible apps are rewritten as well, it can work

Originally Posted by Mrs Beanbag

hmm i see your point... and if two cores execute mutually-problematic instructions at the same time, which gets priority? Then again, x86 et al must also have had to overcome this sort of thing, this doesn't seem like a 68k specific problem.

There is no 68k specific problem that i can see. For me the actual ISA is already enough to support SMP.
The problem is Amiga specific.

Originally Posted by Mrs Beanbag

can we extend the task list in a way that doesn't break (most) old software?

The struct doesn't have room for more info and can't be size extended. Dos processes could perhaps, but not Exec tasks.
All monitoring software expects the lists to be in the normal way, so it would break if the lists get changed.

Originally Posted by Mrs Beanbag

While it's fruitful to think of all the problems i'm someone who prefers to imagine solutions. I'm just going to wait for a second opinion on this tbh because i'm a little out of my depth (but i'm a fast learner).

The only solution would be complete sandboxing of old apps.

[Mrs Beanbag]

Originally Posted by meynaf

They didn't have to - it's Amiga specific problem.

There is no 68k specific problem that i can see. For me the actual ISA is already enough to support SMP.
The problem is Amiga specific.

forgive me but i don't see how any issue created by the atomicity of 68k instructions, or the handling of interrupts, is specifically an Amiga problem.

The struct doesn't have room for more info and can't be size extended. Dos processes could perhaps, but not Exec tasks.

Two-way associative map between the Exec task struct and the extra data?

The only solution would be complete sandboxing of old apps.

even apps that don't bang hardware, don't use interrupts, and don't communicate with each other so are completely unaware of each other's existence? i won't deny there is any problem but i feel you are somewhat overstating it.

If there is specifically an Amiga problem, it must be because, either, the OS itself is doing something non-SMP-safe (which can be fixed, in principle), or the OS is so hands-off that individual apps are going above its head and doing things directly. I realise the latter case does happen. But not in every program, constantly. These must be specific use-cases that can be enumerated.

Perhaps a more concrete example would help me understand.

[meynaf]

Originally Posted by Mrs Beanbag

forgive me but i don't see how any issue created by the atomicity of 68k instructions, or the handling of interrupts, is specifically an Amiga problem.

Because the Amiga is the only true multitasking system allowing the programs to take over the machine.

Originally Posted by Mrs Beanbag

Two-way associative map between the Exec task struct and the extra data?

The only way to find the extra data from the Exec task struct, is to perform some kind of search in a list. Not good in parts that must be very swift. But ok, that could work - in category "ugly but works".
You just have to hope someone will rewrite existing system monitors to not break when handling tasks directly...

Originally Posted by Mrs Beanbag

even apps that don't bang hardware, don't use interrupts, and don't communicate with each other so are completely unaware of each other's existence? i won't deny there is any problem but i feel you are somewhat overstating it.

If there is specifically an Amiga problem, it must be because, either, the OS itself is doing something non-SMP-safe (which can be fixed, in principle), or the OS is so hands-off that individual apps are going above its head and doing things directly. I realise the latter case does happen. But not in every program, constantly. These must be specific use-cases that can be enumerated.

Perhaps a more concrete example would help me understand.

The whole OS is non-SMP-safe. Do you want to rewrite it all ?
Apps are written with the assumption there is a single cpu in the machine.
I can't give you a concrete example.
But what i know for sure is that if something can go wrong, something will go wrong.

Anyway do we really need SMP ? What would that bring us ? Other systems have it because 1) they are unable to multitask properly without it and 2) this is the only way to write higher performance numbers on the paper (and marketing likes these numbers).

[Mrs Beanbag]

Originally Posted by meynaf

You just have to hope someone will rewrite existing system monitors to not break when handling tasks directly...

Granted, this is one category of application that will need updating.

The whole OS is non-SMP-safe. Do you want to rewrite it all ?

I don't, personally, on my own, but people are already rewriting it. Maybe we should bring AROS 68k team into this discussion?

Apps are written with the assumption there is a single cpu in the machine.
I can't give you a concrete example.

I work on apps all the time that have been written without any awareness of multi-core, they still work fine on my dual-core PC. A single app still runs single-threaded, it need worry about other cores no more than it need worry about other tasks or processes. The app won't be any faster if i don't rework it to use multiple threads, but it still runs.

But what i know for sure is that if something can go wrong, something will go wrong.

Something can always go wrong, no matter what you do, it's no reason never to do anything.

Anyway do we really need SMP ? What would that bring us ? Other systems have it because 1) they are unable to multitask properly without it and 2) this is the only way to write higher performance numbers on the paper (and marketing likes these numbers).

Do we NEED it? Do we NEED an enhanced 68k? Do we need an Amiga at all? Sometimes we just want to do stuff to see if we can do them... but never mind that...

Multicore exists because, single-thread instruction-level parallelism limit was reached, Gigahertz limit was reached, demand for faster processing didn't stop, but (thankfully) modern workloads are increasingly multi-threaded by nature. It doesn't just increase specs on paper. It also actually works.

Although, before trying multi-core, i'd suggest hyperthreading, which is more-or-less equivalent to pre-emptive multitasking, with task switching every CPU cycle, so should create fewer problems (?) both for the OS and user programs.

[meynaf]

Originally Posted by Mrs Beanbag

I work on apps all the time that have been written without any awareness of multi-core, they still work fine on my dual-core PC. A single app still runs single-threaded, it need worry about other cores no more than it need worry about other tasks or processes. The app won't be any faster if i don't rework it to use multiple threads, but it still runs.

Of course it runs, because the OS won't allow you to write something that doesn't.
Your program is isolated in its own space and has no access to other programs space, let alone system structs.
(Hey, wait. This is exactly what i told about when writing about sandboxing the apps...)

Originally Posted by Mrs Beanbag

Something can always go wrong, no matter what you do, it's no reason never to do anything.

Sure but when seeing a wall it's better not to run into it.

Originally Posted by Mrs Beanbag

Do we NEED it? Do we NEED an enhanced 68k? Do we need an Amiga at all?

We *do* need an enhanced 68k (or something having the same coding flexibility). At least I do.

Originally Posted by Mrs Beanbag

Multicore exists because, single-thread instruction-level parallelism limit was reached, Gigahertz limit was reached, demand for faster processing didn't stop,

Exactly - but ask yourself the question of why multicore didn't appear before the limits were reached...

Originally Posted by Mrs Beanbag

but (thankfully) modern workloads are increasingly multi-threaded by nature.

Do we execute "modern workloads" on an Amiga ?
What are they anyway ?

Originally Posted by Mrs Beanbag

It doesn't just increase specs on paper.

This is what they wanted you to believe. But how to know, without any reference to compare with ? Do we have single core, single threaded multi-gigahertz cpus running on operating systems not smp aware ?

Originally Posted by Mrs Beanbag

It also actually works.

Yes but this has a cost.

Originally Posted by Mrs Beanbag

Although, before trying multi-core, i'd suggest hyperthreading, which is more-or-less equivalent to pre-emptive multitasking, with task switching every CPU cycle, so should create fewer problems (?) both for the OS and user programs.

Perhaps but neither the OS nor user programs actually have a use for this.
I even have some code that would break if task priorities were broken.

[Mrs Beanbag]

Originally Posted by meynaf

Of course it runs, because the OS won't allow you to write something that doesn't.
Your program is isolated in its own space and has no access to other programs space, let alone system structs.
(Hey, wait. This is exactly what i told about when writing about sandboxing the apps...)

ok. most programs don't write into other program's space (on purpose!) Maybe some do, for interprocess communication. These programs don't merely "have no access" to other program's space, they have no interaction with other programs whatsoever, except by such mundane means as reading and writing files. But how it makes a difference whether the other program is on another core or hyperthread, or just another task, i have yet to establish. The same sort of problems can be encountered. If two programs are inserting into the same linked list, for instance, if a task switch happens while in the middle of doing it, bad things can happen.

Accessing system structs might be more troublesome, but then again it always was. How many programs written for KS1.3 break on 3.1?

We *do* need an enhanced 68k (or something having the same coding flexibility). At least I do.

what for?

i'd like it. i don't "need" it.

Do we execute "modern workloads" on an Amiga ?
What are they anyway ?

fair play, but i could certainly imagine getting use out of it, if it were there. Amiga OS obviously doesn't have quite the menagerie of background services as Windows or Linux but if i could be rendering some image or compressing some big file, or play an MP3 (which the cool kids are doing these days), and still get on with something else without hinderance, that would be nice.

I even have some code that would break if task priorities were broken.

sounds like bad code

[meynaf]

Originally Posted by Mrs Beanbag

ok. most programs don't write into other program's space (on purpose!) Maybe some do, for interprocess communication. These programs don't merely "have no access" to other program's space, they have no interaction with other programs whatsoever, except by such mundane means as reading and writing files. But how it makes a difference whether the other program is on another core or hyperthread, or just another task, i have yet to establish. The same sort of problems can be encountered. If two programs are inserting into the same linked list, for instance, if a task switch happens while in the middle of doing it, bad things can happen.

Sure many programs would work exactly the same.
The problem with running on several cores is that normal, simple concurrent access protections fail. And we're not supposed to use CAS, CAS2 instruction types on the Amiga (the manual says it, right ?) - so this ought to require some hardware modding as well (= not just changing the cpu with a simple trapdoor accelerator).

Originally Posted by Mrs Beanbag

Accessing system structs might be more troublesome, but then again it always was. How many programs written for KS1.3 break on 3.1?

So it boils down to having a new OS version and break a few programs in the process ? Hmm...

Originally Posted by Mrs Beanbag

fair play, but i could certainly imagine getting use out of it, if it were there. Amiga OS obviously doesn't have quite the menagerie of background services as Windows or Linux but if i could be rendering some image or compressing some big file, or play an MP3 (which the cool kids are doing these days), and still get on with something else without hinderance, that would be nice.

Take some uae in jit mode. There you can render some image, compress some big file, play some mp3 and still get on with something else (please notice, however, that you scarcely do all these together !).

Originally Posted by Mrs Beanbag

sounds like bad code

On AmigaOS low priority tasks are always interrupted by higher priority ones. Or does some manual say otherwise ?

[NorthWay]

You _can_ expand the task struct if you absolutely want to as was introduced with 2.x(3.x?). I have always forced that in my own Exec versions, and I don't know of any ill effect from what I have run.

It still doesn't help you with RMW operations that expect to be atomic when using a single cpu.
You have to resort to MMU trapping access to the Forbid() semaphore and the interrupt register that Disable() touches to make sure you catch them all and can properly signal the other cpu(s). That will not be pretty... nor fast. Interestingly, a 68K FPGA implementation could be given special purpose hw to accellerate these special cases, but you still have the RMW problem.

[meynaf]

Originally Posted by NorthWay

You _can_ expand the task struct if you absolutely want to as was introduced with 2.x(3.x?). I have always forced that in my own Exec versions, and I don't know of any ill effect from what I have run.

What ? An app can expand that struct if it wants, but Exec itself ?
Many programs just use the size of 92 bytes to allocate new tasks and that would break !

[NorthWay]

    ;* Pointer to an extended task structure.  This structure is allocated
    ;* by V36 Exec if the proper flags in tc_ETaskFlags are set.  This
    ;* field was formerly defined as:
    ;*		UWORD	TC_TRAPALLOC	    ; traps allocated
    ;*		UWORD	TC_TRAPABLE	    ; traps enabled
    ;* Please see the Exec AllocTrap() and FreeTrap() calls.
    ;*
    APTR    tc_ETask		    ; pointer to extended task structure

I have patched Exec to force setting T_ETASK(is that the correct name?) on all task creations and so far do not know any ill effect. There certainly is a possibility there can be as C= made it optional, but hopefully most useful sw is 2.0-aware.

Exec would be free to modify/extend the TC_ETASK struct for multi-cpu purposes, but that does not resolve non-atomic opcodes.

[meynaf]

Originally Posted by NorthWay

I have patched Exec to force setting T_ETASK(is that the correct name?) on all task creations and so far do not know any ill effect. There certainly is a possibility there can be as C= made it optional, but hopefully most useful sw is 2.0-aware.

Why doing that ? Sounds like looking for trouble.

Originally Posted by NorthWay

Exec would be free to modify/extend the TC_ETASK struct for multi-cpu purposes, but that does not resolve non-atomic opcodes.

This struct doesn't appear to even be documented...

Anyway, extending the struct is something, however, what to put in some fields like execbase->ThisTask ?

[NorthWay]

Originally Posted by meynaf

Why doing that ? Sounds like looking for trouble.

I was testing per-task mmu tables. I changed the private structure to hold more info.

Originally Posted by meynaf

This struct doesn't appear to even be documented...

The change to Exec is, but the struct it points to is indeed not documented and definitely so intended not to be.

Originally Posted by meynaf

Anyway, extending the struct is something, however, what to put in some fields like execbase->ThisTask ?

I haven't even begun thinking about that.
Anyone know what the OS4 devs are thinking, or what Jim Drew thought he could get away with back in the day?