OS4 Classic, why disable the 68k ?

[Erebos]

Hi,
I just wondering why the onboard 68k is disable on the Classic version of OS4 ?
If it wasn't, would it be possible to run things without 'runinuae' or the likes ? or maybe it will speed up this as it wont need to emulate the 68k ?

[Steady]

From what I understand, the context switches between 68K and PPC were way too slow, and it introduces a whole lot more complexity.

[Matt_H]

You'd run into the same problems as you do with WarpOS and PowerUp - context switches that zap performance.

Besides, the main issues with OS4 and compatibility have less to do with the processor and more to do with the substantial rewrite of the OS. It's the same kind of problem we experienced going from 1.3 to 2.04. In other words, even if we had a full 68K build of OS4, the stuff that requires UAE would almost certainly still require UAE to work.

[cha05e90]

Hi,
I just wondering why the onboard 68k is disable on the Classic version of OS4 ?
If it wasn't, would it be possible to run things without 'runinuae' or the likes ? or maybe it will speed up this as it wont need to emulate the 68k ?

This seems to be a common misunderstanding. You don't need UAE or RunInUAE to use 68k software with AmigaOS4.x (or MorphOS in that respect).

[vox]

Hi,
I just wondering why the onboard 68k is disable on the Classic version of OS4 ?
If it wasn't, would it be possible to run things without 'runinuae' or the likes ? or maybe it will speed up this as it wont need to emulate the 68k ?

Simplest answer is that whole OS4 is PowerPC and running native PPC apps is whole level of new experience. 68k WB friendly software will be working under Petunia, maybe even faster then 040 if PPC is 604 I suppose. AGA chipset should be even acessible? so even more software should work? (has anyone tested e.g. apps that used to crash on A1 on Classic OS4?
http://www.intuitionbase.com/ossoftware.php?category=3&letter=NON

Plus the context switching was known slowdown problem of PPC cards, so your PPC experience is full now :-)

[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.

[SamuraiCrow]

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.

It's not just OS4 that needs a redesign.  The Phase5 accelerator card has only one memory bus so it CANNOT run both processors at the same time.  It can switch between them, but not run them in parallel.

[dreamcast270mhz]

The issue Samurai describes is also present on the saturn, and a reson for its demise. The CPUs apart were weak, but together they ran well. Only one CPU could access the memory registers at a time, but their memory was divided for each cpu

[cha05e90]

In theory, the '040/060 could run asynchronously in parallel to the PPC (WarpOS + 3.x worked that way).

Really? I don't think it worked that way.

[Erebos]

indeed, very interesting answers here.
So it is because of hardware design that OS4 is doing that way..
But if WarpOS+ 3.x managed to do that it must be feasible ;-)

[Piru]

The Phase5 accelerator card has only one memory bus so it CANNOT run both processors at the same time.  It can switch between them, but not run them in parallel.

The CPUs most definitely do run in parallel.

I don't know who invented this nonsense and for what purposes, but it is not true.

[Piru]

Really? I don't think it worked that way.

It was possible to run 68k and PPC code independent from each other, at least with PowerUP. There were certain highly optimized apps that used to do this. For instance the infamous FastQuake used a special cache inhibited memory area as a ring-buffer to avoid the need for cache flushes. This way both CPUs could run at full speed with as few context switches as possible.

[cgutjahr]

But if WarpOS+ 3.x managed to do that it must be feasible ;-)

It is feasible, but it would slow down the PPC CPU considerably: Each time you switch from one CPU to the other on a PowerUp board, you have to flush all CPU caches (because the CPUs are sharing the same memory, and this is the only way to maintain memory integrity). Now imagine doing that hundreds of times per second (as you would have to, when running 68k and PPC tasks in parallel) - the system would crawl.

As it is, depending on the speed of your PPC CPU, the 68k CPU emulated by OS4 is definitely faster than a 68040 anyway.

[Erebos]

@cgutjahr
as i was talking about classic version, I cant see how the PPC side of my blizard ppc at 240mhz can be faster emulating 68k than my real 060 onboard...
Plus i'd say that performances do not drop at all when on 3.9 i have 68k tasks running along side ppc ones (like wos mp3 decoding)
Reason maybe is that it is much easier to maintain an unique branch of the OS that is primary towarded to NG amigas and not designed for classic at first.
maybe that contexts switches are too heavy to handle, but...i'm skeptical

Anyway please do not misunderstand my words, i'm glad that OS4 exists for classic and thanks Hyperion for it ;-)

[bbond007]

@cgutjahr
as i was talking about classic version, I cant see how the PPC side of my blizard ppc at 240mhz can be faster emulating 68k than my real 060 onboard...
Plus i'd say that performances do not drop at all when on 3.9 i have 68k tasks running along side ppc ones (like wos mp3 decoding)
Reason maybe is that it is much easier to maintain an unique branch of the OS that is primary towarded to NG amigas and not designed for classic at first.
maybe that contexts switches are too heavy to handle, but...i'm skeptical

Anyway please do not misunderstand my words, i'm glad that OS4 exists for classic and thanks Hyperion for it ;-)

Well, you would need to take the same approach they took with 3.X

Because your native OS is in PPC you would need to write a specialized kernel for your 68K and as well as supporting PPC libraries to communicate with and facilitate data exchange with said 68K kernel.  

You would convince application developers to compile parts of their applications 68K native and to retool their applications to use a design pattern conducive to offloading tasks to a slower processor. To convince the developers you'll just need to remind them of the Amiga's central design philosophy concerning multitasking and the offloading of work from the central CPU.

The first PPC->68K API would called "Power Down" but soon after its introduction a new standard will emerge called "WarpOS/2".

Fortunately, specific "Power Down" and "WarpOS/2" compatibility layers will created for the respective API's which will allow some degree of compatibility.

People will bicker over the technical merits of both APIs for years until the entire OS is fully ported to 68K.