OS4 Classic, why disable the 68k ?

[Zac67]

In theory, the '040/060 could run asynchronously in parallel to the PPC (WarpOS + 3.x worked that way). However, OS4 isn't up to handling SMP/AMP, it needs to be designed that way.

[Zac67]

I may be wrong, but I don't think that bus snooping worked so well (or perhaps at all) with the design

Sadly, bus snooping doesn't solve the problem: since any CPU could be modifying data segments (that may even have been cached by the other side) without writing them back right away, data caches can diverge substantially. x86/x64 systems are having quite a tough time ensuring cache coherence - just look at AMD's MOESI protocol (with the added challenge of multiple local RAM busses). With a heterogene AMP system without MESI you have little choice.

The only way to get around the extremely expensive context switches is to divide the RAM into regions for each CPU with a shared (non-cached) region for message passing - if I understood correctly this is what you were thinking of. However, shared memory is also expensive as it must not be cached and you need to copy all data passed back and forth to this slow memory - so you'll starve a CPU depending on caching as well (though not as badly).

[Zac67]

@Karlos
I think I got it now... I'd call it 'fine-grained cache coordination' - definitely doable, provided the quick signalling bit (interrupts passing) works, but I can hardly imagine how anything should be working without it. You'd have to write new drivers for the 68k side though (or provide elaborate frontends to the existing ones, not sure if a generic one can do the trick). I can imagine that it may be easier to write new PPC drivers from scratch (definitely for something generic as IDE - yes, only an example of course). I got a bit distracted with the 'DMA' bit, but that's just one of the ways you could use the passing of jobs back and forth - very much like the AOS messaging system actually!

Ram set at 60ns in the firmware on these BlizzardPPC :

Wos (060@72 rev5 & 603e@360 with a 72 Mhz FSB) : 668 ms
Pup (060@72 rev5 & 603e@360 with a 72 Mhz FSB) : 1031 ms

Wos (060@72 rev1 & 603e@200 with a 66 Mhz FSB) : 791 ms
Pup (060@72 rev1 & 603e@200 with a 66 Mhz FSB) : cannot load the ppc.library

Woah - those definitely are killer times - far worse than I could imagine. But then again, flushing a better sized cache can take a while... Well, as Karlos has pointed out there are better ways, simply flushing everything is only the easiest by far.