@orgin

What's crazy and weird to you might make perfect sense to someone else.

It's not weird, nor is it crazy. You thinking that is what's weird.

@OlafS25

I can’t comment on what is not official or is not released..

I can merely comment on issue with SMP, and cache concurrency, from the information, I looked up or find lectures about it..

if it’s possible or not to do x/y/z, comes down to problem solving abilities, and what solution was chosen. Something can be hard to do, when you have a lot of stuff running in background tripping all over the place.

So far from what I have lookup, it’s normal for cores to have their own MMU, so a exception should not affect other cores. something some people suggests that’s not case, but as pointed out by Gemini, it won’t be possible for threads to have its own virtual memory maps if that was the case.

cache concurrency has hardware solution, and software solutions, there are different ways this can be implemented, as outlines in YouTube lectures I have pointed to..

I can’t comment on the AROS solution.

If it is possible or not to run Petunia inside a sandbox, my guess is that’s its possible, however I do not know implementation, so I can’t say for sure..

I can say for sure that it is not possible to add 64bit support without a sandbox for 32bit programs..

My opinion about AmigaOS4.1 API is that is fragile and can need improved security, regarding stack, API’s and structurally.. and that major changes can require a sandbox solution.

I guess that a lot of AmigaOS libraries are not cache concurrency safe, and might need to be sandboxed. its far better if programs fail to open a library, then bring down the system

Cleaned up some weird stuff in this thread.

Stay away from the crazy stuff please, and continue the interesting discussion you're having here.

@LiveForIt

On AROS there is a experimental version with SMP support. As I understand it the concept is one core runs the system processes, apps are automatically started on other cores or can be started on a own core. Advantage, system is more stable and expeciaslly more resposnsive

But this of course needs changes in exec that affect compatbility. No problem if your software base is limited and mostly sources available and adaptable, a problem if most software is closed and cannot be recompiled. The same is true for 68k.

Another topic is migration to 64bit. You have software that is 32bit and cannot be reompiled. Solution is a runtime where 32bit software works on 64bit system..

68k can be solved by UAE of course, for example Amiberry.

So in short you need to modernize to drop compatibility to the old 68k amigaos and also to the existing PPC base and solve it by runtime/VM for PPC software (QEMU?), perhaps runtime for closed 32bit software, integration of 68k using UAE (as transparent as possible). Petunia will no longer work

@joerg

with a sandbox approach you most likely end up width a different execbase anyway..

you need a ready list / wait list per core, and I think old linked list is a bit slow due to its scattered data, and its slow to index, as you need to walk the list up and down.

Quote:

page zero is already memory protected, if not you won’t get a DSI error on NULL pointers..

I have used exceptions in NallePuh, and I must say it works far better than I expected even on busy loops, pocking the same address repeatedly. No doubt is slow, but once you read address 0x00000004, into a register, you no longer reputedly poke that address.

@LiveForIt
Quote:Wrong, you'd have to unmap the page containing SysBase->ThisTask (+4092 other bytes of struct ExecBase) instead and use exception handlers to return the required data per core.

Just like there is no SysBase pointer in 0x4 but the zero page is unmapped and an exception handler returns the SysBase pointer if something is accessing 0x4 with a 32 bit read.

No big problem for the zero page, only old m68k code accesses 0x4 to get SysBase, and most only once at program start. For PPC native software it's passed as one of the _start() arguments, or other functions like in libraries, etc., but it's always available without having to access 0x4.
But if you'd unmap a large part of struct ExecBase and use exception handlers instead to return the data you'd get extreme slowdowns, it might even be slower using SMP with 2 cores with such a method than only using a single core

@joerg

Quote:

Easy... set SysBase->ThisTask to 0xdeadcafe or something silly.

put a MMU protection on 0xdeadcfae, the exception routine calls IExec->FindTask(NULL); or something like that.. (might need to find correct the IExec sense that might be a different instance, per core)

"Per-Core Structure: Almost all modern multi-core processors have an MMU integrated into each individual core. This allows each core to independently translate virtual addresses to physical addresses for the thread or process it is currently executing."

So I guess you need to set that exception 4 times, if you have 4 cores..
you might perhaps have a slight different exception per core, that handles instance of IExec..

@LiveForIt
Quote:AddTail() is an exec function, in all versions of AmigaOS.

There are macros for all list functions (or at least were in some old m68k C compiler includes), but software using them instead of the exec functions usually does even much worse things as well, for example using (struct ExecBase *)SysBase->ThisTask instead of IExec->FindTask(NULL), and therefore will never work with SMP.

@tao

but if we are talking about 64bit, we don't need to guess. then we must have a sandbox.. so its just over the horizon anyway..

and frankly disabling multitasking to access a public stricture is not good idea... and even worse on SMP system..

Sure maybe solve the messaging API, but AddTail() is a macro, there if you have no function that you retro fit any cache flushes, then the pre-compiled code can't become SMP friendly.

for more info look here, also notice the warnings, and bad advice.

http://amigadev.elowar.com/read/ADCD_ ... cs_3._guide/node01E1.html

you will need to do it on forbid / permit, but that is already pretty bad.

@LiveForIt

Quote:

Of course. Just musing over "how we got here".

Quote:

Thanks for the primer. I'm glad to hear that you're guessing, as hopefully the kernel developers came up with something much more "drop-in". It apparently largely works, too. When the technical writeup finally appears (wiki.amigaos.net ?) I'll be curious to see which solution they chose.

A new Life-of-Tech blog

https://life-of-tech.blogspot.com/2026/02/ayn-odin-2-portal.html

@Tuvok

Hi, yes, the Amiboing high score table should work. Make sure you have the latest version 1.05 from August 1, 2017 installed.
If you have forgotten your password, send us an email at mail@amiboing.de. @imagodespira can reset your password.

@Goos
Thank you so much for this prize and your support. Great stuff.

Any news on Godot for Amiga?

@Tuvok

keep em coming

@OlafS25

Whenever a subject of this nature is brought up in any Amiga forum, I remember all of the doom-and-gloom in the Amiga magazines around 1989-1990 concerning Workbench 2.0 being incompatible with around 60% of the Amiga software at the time. When 2.0 came out, I upgraded. I eventually got a kickstart switcher to run old games. I found the upgrade worth it even though it introduced some incompatibility. If AmigaOS 4.3 or higher breaks compatibility with 68k, there will be workarounds. The new features will be worth the change in my opinion.

@AmigaOldskooler

@Goos

Cool! Thank you!

Does AmiBoing still work for Hi-Score saving? Maybe I lost my password, I can't log in.

@328gts



69043 I'm right behind you! hahaha

@LiveForItQuote:

Interesting video, thanks! I could follow and more or less understand up until AWS Lambda, then I was lost.