Learning more here and doing some other research, it becomes clearer to me why SMP is hard. I think I probably underestimate the complexity of developing a multi-core kernel itself. I probably spend too much time on the other side of the kernel to think about all the ramifications of handling PCI bus stuff, etc., and I guess some variants of AmigaOS are based on microkernels that might not make it easy to provide SMP, etc (or maybe make it easier, I dunno).
Let me rephrase what I said:
The Forbid/Permit semaphore is a publicly readable and writeable kernel structure.
You are free to change the definition of how the OS works, but then you are on your own. AROS (very sensibly (IMNSHO)) decided to take 3.1 with warts and all and implement that first. When they are 100% done you can add New Stuff.
I wasn't suggesting changing how it works. I think I understood what you said, and I think it is fine if Forbid()/Permit() serializes execution of any apps waiting on a Forbid(). Even with all this contention I think multi-core would be effective where needed, because apps that suck up lots of CPU wouldn't be doing it all within Forbid() sections as that would be completely terrible programming practice. And if they do that, too bad for those apps. From Amiga Classic perspective there wasn't really enough CPU available to do heavy number crunching, so I can see how apps back then could monopolize a lot of the CPU just dealing with the OS for GUI/file IO, etc. I don't think that applies as much going forward.
Also understood about AROS wanting get the basics covered first. I wasn't even suggesting adding multicore to AROS right away, just trying to say it would have to be the sandbox for the experiment if someone like myself wanted to play with it as it's the only one with code to play with.
@Karlos
Personally, I don't care whether or not my OS4 box runs classic (680x0 or PPC) software, so long-term, I'd like to see support for legacy software disappear entirely. If you wanted to keep them, though, you could keep the first 32 bits of a 64-bit address space reserved for that stuff and create as many individual or shared sandboxes as the user wants. Think VM86 and DOS under OS/2 and Windows NT.
Whose requirements are those? What is AmigaOS, exactly? The kernel? The API? The coupled hardware? Regarding new applications, isn't that the point?
If the legacy kernel is itself a process under a new kernel--one that did all the magic necessary to support the legacy kernel as a process--then barring hardware incompatibilities, how would old applications know the difference? New applications could use the same APIs we use today, minus the bits we know to be "bad."
I think the Amiga without the legacy apps wouldn't be too interesting to me. My vision of an Amiga box going forward is something that can be all things Amiga, including historical, with as much modernization of things as possible as well. I don't really care how it does this, running on some unix variant kernel, through emulation, WINE-style, etc., though the better/faster/more compatible it runs the better it is IMO. I think in the end the OS X model is probably where it needs to go. Obviously that might be difficult to get the resources for, no idea how hard that is.
The 'original' Los Gatos Amiga crew were very much aware of the problems related to the 1983-1985 design decisions, and tried to apply what they learned in their next design, the 3DO operating system. I don't know if they made it SMP friendly or not, but it suffered the same ultimate fate as Amiga.
Heh, I am probably one of the rare few who actually developed for the 3DO M2. It's funny because at the time I had no clue there was any kind of Amiga connection. I didn't learn about the people behind Amiga until the last year when I got back into it since that info was scarce in the pre-internet world that my Amiga days existed in before. I've since learned that I previously crossed paths with a few people and techs related to Amiga. Would have been nice to know at the time as I would have got a kick out of it and maybe brought it up.
The M2 seemed quite elegant to program for. It was quite polished for where it was in development. I think because of this I don't remember much about the system. I had to go to wikipedia and look up that it was indeed a dual core power PC box, so it suported SMP! That probably would have messed up programmers pretty good at that time - maybe not a great design decision. The audio DSP did also make the system AMP =). I remember you had to cobble together a bunch of fortran authored objects to create a plugin/signal path. It seemed pretty advanced at the time, hard to believe it even worked, but it did! So there you go, the M2 had both SMP and AMP, which makes it somewhat topical to this thread. =) No idea about the original 3DO.
