@Hammer

Perhaps your thinking of Cyrix, that’s was intel clone.

https://www.youtube.com/watch?v=iWGAdoMz1c0

Lots of PowerPC cpu’s are superscalar, with support for out of order operations, even old 601’s has some support for it, it’s kind of point of having so many GPR registers. As long next instruction does depend on previous instruction, it they can operate in parallel, and overlap in time.

for example AltiVec has own 128 bit registers, FPU has 64bit registers, and you CPU has its integer 64bit registers, typical compiled for 32bit mode. Seams to ignore 64bit load and store, perhaps CPU types has set, for better optimized code, never invested much time in that. (or maybe it depends on the GCC version)

but because SPE does have its own registers, thats not a options.
but SPE can

https://www.nxp.com/docs/en/reference-manual/SPEPEM.pdf

Instead, the SPE can use one 64bit GPR registers.
the operation can be divided up by lower and upper bits, allowing for 2 x 32bit float operations performed by one single instruction.

This similar to how AltiVec works, with 128bit special registers, 1 x 128bit operation, it can do two 32bit operations, 4 x 16bit operations or 8 x 8bit operations, preformed by a single instructions. This is a advantage, this also similar to how assembler on GPU’s work as explained by Hans on his webpage.

so what we are talking of here is different way of archiving parallel operations.

Last edited by NutsAboutAmiga on 25-Jul-2023 at 05:25 PM.
Last edited by NutsAboutAmiga on 25-Jul-2023 at 05:21 PM.
Last edited by NutsAboutAmiga on 25-Jul-2023 at 04:52 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Hammer

https://en.wikipedia.org/wiki/Fast_inverse_square_root

the fast inverse square root Algorithm used in quake, is interesting, because it peeks under the hood of float, and preforms an integer and float operation on same value. Technical a int and float works the same way on PowerPC, its just that bytes are swapped, the result of storing something, and loading back, should be same, not sure endianness effects it, and can’t find anything that suggest it does.

Pentiums got native support for it built in so did PowerPC.
PowerPC even has AltiVec support for it.

https://reviews.llvm.org/D101209?id=341456

the ARM can have bigger issue, as it only support LE floats, and support LE or BE integers, can be none consistent, if it’s in BE mode. But then again it probably has also support it as assembler optimized instruction, but I have not looked.

Last edited by NutsAboutAmiga on 25-Jul-2023 at 05:22 PM.
Last edited by NutsAboutAmiga on 25-Jul-2023 at 05:19 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Hammer Perhaps your thinking of Cyrix, that’s was intel clone. https://www.youtube.com/watch?v=iWGAdoMz1c0

Cyrix's 6x86 design is missing performance-enhancing Pentium FPU features.

From RTL Engineering https://www.youtube.com/watch?v=DWVhIvZlytc
Intel Pentium MMX 233 vs AMD K6 233ANR microarchitecture comparison and Quake.

Pentium P5 optimizations
1. FXCH Pairing (Floating Point Exchange), can mitigate x87 mess (K6 did not do this). K6-2 includes FXCH. The minor performance hit on AMD k6.

2. Superscalar integer pipeline pairing (K6 did this)

3. Pipelined floating unit (K6 did this - mostly)

4. Integer-FP execution overlap, can hide FDIV latency (K6 did this)
Stalls the K6 scheduler, likely the biggest factor for the performance difference.

RTL Engineering's detailed K6 FPU vs Pentium FPU with FDIV instruction handling https://youtu.be/DWVhIvZlytc?t=799

AMD learns from this K6's Quake debacle with K7 Athlon's FPU.

Quote:

Lots of PowerPC cpu’s are superscalar, with support for out of order operations, even old 601’s has some support for it, it’s kind of point of having so many GPR registers. As long next instruction does depend on previous instruction, it they can operate in parallel, and overlap in time. for example AltiVec has own 128 bit registers, FPU has 64bit registers, and you CPU has its integer 64bit registers, typical compiled for 32bit mode. Seams to ignore 64bit load and store, perhaps CPU types has set, for better optimized code, never invested much time in that. (or maybe it depends on the GCC version)

https://barefeats.com/doom3.html
Doom 3's X86 vs PowerPC compare.

Glenda Adams, Director of Development at Aspyr Media, has been involved in Mac game development for over 20 years. I asked her to share a few thoughts on what attempts they had made to optimize Doom 3 on the Mac and what barriers prevented them from getting it to run as fast on the Mac as in comparable Windows PCs. Here's what she wrote:

"Just like the PC version, timedemos should be run twice to get accurate results. The first run the game is caching textures and other data into RAM, so the timedemo will stutter more. Running it immediately a second time and recording that result will give more accurate results.

The performance differences you see between Doom 3 Mac and Windows, especially on high end cards, is due to a lot of factors (in general order from smallest impact to largest):

1. PowerPC architectural differences, including a much higher penalty for float to int conversion on the PPC. This is a penalty on all games ported to the Mac, and can't be easily fixed. It requires re-engineering much of the game's math code to keep data in native formats more often. This isn't 'bad' coding on the PC -- they don't have the performance penalty, and converting results to ints saves memory and can be faster in many algorithms on that platform. It would only be a few percentage points that could be gained on the Mac, so its one of those optimizations that just isn't feasible to do for the speed increase.

2. Compiler differences. gcc, the compiler used on the Mac, currently can't do some of the more complex optimizations that Visual Studio can on the PC. Especially when inlining small functions, the PC has an advantage. Add to this that the PowerPC has a higher overhead for functional calls, and not having as much inlining drops frame rates another few percentage points.




Quote:

but because SPE does have its own registers, thats not a options. but SPE can https://www.nxp.com/docs/en/reference-manual/SPEPEM.pdf Instead, the SPE can use one 64bit GPR registers. the operation can be divided up by lower and upper bits, allowing for 2 x 32bit float operations performed by one single instruction. This similar to how AltiVec works, with 128bit special registers, 1 x 128bit operation, it can do two 32bit operations, 4 x 16bit operations or 8 x 8bit operations, preformed by a single instructions. This is a advantage, this also similar to how assembler on GPU’s work as explained by Hans on his webpage. so what we are talking of here is different way of archiving parallel operations.

FYI, I'm already aware of e500v2's 64-bit SIMD, embedded FP64 (not fully compliant with IEEE-754, similar to PS3's CELL's non-compliant IEEE-754 SPE) capability, and shared GPRs.

IBM has offered compliant IEEE-754 SPE with PowerXCell 8i.

FYI, AMD Radeon HD 7970 (GCN 1.0 Tahiti) has compliant IEEE-754-2008 FP32 and FP64. AMD's Polaris GCNs has gimped FP64 support, hence they don't replace Tahiti GCN's FP64 use cases. Most 3D use cases are fine with FP32.

OpenCL support is important to abstract the various CPU's SIMD and GPU's MIMD extensions.

Last edited by Hammer on 26-Jul-2023 at 04:56 AM.
Last edited by Hammer on 26-Jul-2023 at 03:47 AM.
Last edited by Hammer on 26-Jul-2023 at 03:44 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Hammer https://en.wikipedia.org/wiki/Fast_inverse_square_root the fast inverse square root Algorithm used in quake, is interesting, because it peeks under the hood of float, and preforms an integer and float operation on same value. Technical a int and float works the same way on PowerPC, its just that bytes are swapped, the result of storing something, and loading back, should be same, not sure endianness effects it, and can’t find anything that suggest it does. Pentiums got native support for it built in so did PowerPC. PowerPC even has AltiVec support for it. https://reviews.llvm.org/D101209?id=341456 the ARM can have bigger issue, as it only support LE floats, and support LE or BE integers, can be none consistent, if it’s in BE mode. But then again it probably has also support it as assembler optimized instruction, but I have not looked.

One problem, A-EON's X5000's P5020 (PPC e5500 core) and A1222 Plus's P1022 (PPC e500v2 core) do not have AltiVec.

PPC e5500 is like PPC G3 with 64-bit support.

PPC e6500 has AltiVec. PPC e6500 is a suitable replacement for A1-X1000's Altivec capable PWRficient PA6T-1682M.
---------------
For the Amiga-related market, ARM Cortex A53 and A72 AArch64 competition have ARMv8 NEON 128-bit SIMD.

Emu68 is booted into AArch64 BigEndian mode (from https://www.patreon.com/posts/emu68-on-aarch64-33084316?l=it)

Michal Schulz:
as soon as my code starts, whether it is the 32bit or 64bit arm code, I switch the big endian mode on. The rest of the emulator, including the supervisor/hypervisor mode of the ARM cpu, is operated in big endian mode.

You may read on the early startup process of Emu68 in this article: https://github.com/michalsc/Emu68/wiki/AArch64


"Fast inverse square root" was used in Quake 3 Arena and designed for IEEE 754-1985 32-bit floating-point specification.

The fast inverse square root algorithm from Quake III Arena is much slower and less accurate than using the SSE instruction RSQRTSS on x86 processors that were also released in 1999 and 3DNow's PFRSQRT with K6-2 in 1998.

Last edited by Hammer on 26-Jul-2023 at 04:52 AM.
Last edited by Hammer on 26-Jul-2023 at 04:27 AM.
Last edited by Hammer on 26-Jul-2023 at 04:27 AM.
Last edited by Hammer on 26-Jul-2023 at 04:16 AM.
Last edited by Hammer on 26-Jul-2023 at 03:59 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

2. Compiler differences. gcc, the compiler used on the Mac, currently can't do some of the more complex optimizations that Visual Studio can on the PC. Especially when inlining small functions, the PC has an advantage. Add to this that the PowerPC has a higher overhead for functional calls, and not having as much inlining drops frame rates another few percentage points.

On Macintosh PPC / MacOS9 i susspect that be Symantic C++ compiler, not the typical GCC, they had some speical needs due to there Pascall legacy, non standard delcarations for strings etc. soft floats, so called FIX POINT or something.

IBM has had there own C compilers, but its not free, I not sure what platforms they support.

Last edited by NutsAboutAmiga on 26-Jul-2023 at 07:00 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Hammer

Quake I is fast enough even on 30 years old 603.
I don't need anything better.
I even don't finish Quake II up to now.
Amiga 1222 will be good enough for Quake I and Tomb Raider I.
It is fast enough for games that I always want to play on Amiga
but 25 years ago 68k was too slow and expensive.

And it is not pc.

@Hammer
Quote:

Michal Schulz: as soon as my code starts, whether it is the 32bit or 64bit arm code, I switch the big endian mode on. The rest of the emulator, including the supervisor/hypervisor mode of the ARM cpu, is operated in big endian mode.

I wonder if it would be possible to use AROS ARM behave like AmigaOs4 then...

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

When the AROS PPC version does not have it, you should not be too surprised if that be a lot of work to archive.

Last edited by NutsAboutAmiga on 27-Jul-2023 at 04:47 PM.
Last edited by NutsAboutAmiga on 27-Jul-2023 at 04:46 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Well, there's not much of a platform for AROS to run on PPC now is there? Even because there's already two more advanced solutions out there. At least in PiStorm it would feel at home...

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

PiStorm is the adapter card, it’s not the operating system, not an AROS distribution.

https://amigastore.eu/853-pistorm.html

You know I was corrected on the same thing, but its important use correct names and definitions, when talking about something, so people actually understand what your talking about.

the OS on the PI that emulates 680x0 is Emu68. And it does not behave like AmigaOS4 at all, it emulates a freaking CPU. The approaches can’t be more different, the only thing that’s common is the word JIT and JIT cache.

the most important part is that 680x0 and address and databus on a PIsStorm is GPIO pins, so for example a ARM instruction wont even know concept of that, as it operates on a real databus and address bus, not imaginary one.

Last edited by NutsAboutAmiga on 27-Jul-2023 at 08:06 PM.
Last edited by NutsAboutAmiga on 27-Jul-2023 at 07:58 PM.
Last edited by NutsAboutAmiga on 27-Jul-2023 at 07:56 PM.
Last edited by NutsAboutAmiga on 27-Jul-2023 at 07:54 PM.
Last edited by NutsAboutAmiga on 27-Jul-2023 at 07:53 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

You're right, I was thinking in the platform overall Amiga+pi and not pi alone. I never talked about pistorm being equal to AROS though. There's AROS ARM already, what I though was since emu68k can use big endian that AROS could be made to run big endian and emu68k be used like petunia is on OS4.

Ps- re reading I don't actually get why the confusion, while pistorm is the adaptor board it doesn't work by itself, so when I refer to pistorm I am obviously talking about the combo pistorm+pi in opposition to standalone

My main point is, there is nor will be AmigaOS 4 for ARM, since there's ARM AROS already, since from what MichalS said one can use big endian on it if some some similar strategy to AmigaOS+Petunia would be feasible, it doesn't have to be tied with emu68k

Last edited by pixie on 27-Jul-2023 at 08:15 PM.
Last edited by pixie on 27-Jul-2023 at 08:10 PM.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

Well if ports his JIT compiler over to AROS he must contend with fact that registers are sometimes reserved by OS, and for specific tasks.
Aros uses different ABI’s as well, for the different CPU families, you 64bit AROS where all addresses are 64bit, you have the 32bit x86 AROS, that LE, and PowerPC AROS that’s BE but uses stack passing like similar Linux does or other modern OS.

You will need some kind of translation layer, that converts 68K registers to native ABI, and back, as well he need to integrate in a way that makes sense.

It has talked about before, but AmigaOS4.x has clear separation between the 680x0 API and PowerPC native API, there different entry and exit points. That’s make it easy, there are exit strategies put in place to exit JIT cache, and return, when going between native routines, end generated code snippets in JIT cache.
All of this he does not have, need to be implemented, and he need to remove some stuff is PiStorm related, GPIO stuff.

So we are really talking about something different, yeh… sure he has been able to test out his JIT in real world, without having to worry about AROS environment, and I guess that’s one of advantages to the emu68 approach.

Emu68 / piStorm also works with real hardware and chipset once you remove that its no long as compatible as it is currently. That’s another thing.

They only aimed for source code level compatibility in the beginning, they had there AROS 680x0 version for some time, so I guess most of it has tested with AmigaOS programs. So perhaps it wont be like walking into twilight zone for the amiga programs.

Last edited by NutsAboutAmiga on 27-Jul-2023 at 09:34 PM.
Last edited by NutsAboutAmiga on 27-Jul-2023 at 09:31 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@pixie

Modifying AROS that way:

I don’t think there much interest in the 68k community to fund it, it won’t run their favorite 68k games. and fundamental lack of interest for writing portable code, that does not bang the Amiga chipsets. The PiStrom / Emu68 is perfect solution to 68k community, as they can continue writing bad code, that does not care about the OS, because JIT compiler lives outside of the OS its running, similar to how an emulator does it, except motherboard and chipsets are real.

I can’t help thinking about the people screaming defund the police. And then complaining about crime not being done anything about. This what feel about this idea. We know is lack of development on AROS for years, some people just grabbing free stuff put on ISO and calling it AROS distribution, and not funding the developers. Its same stuff being promoted year after year.

Perhaps Vampire developers funded some of the development of Apollo OS, and perhaps PiStorm PCB cards, being sold generate some money, and probably more then they will ever make on AROS version of the JIT compiler but let see what happens. Generally, its hardware that funds the software development. If people don’t need to buy your stuff, then you don’t get any money. if all the developers are getting is bugs reports like, there is “BUG”, and insults, and no money, you can bet they wont stay.

Last edited by NutsAboutAmiga on 27-Jul-2023 at 10:11 PM.
Last edited by NutsAboutAmiga on 27-Jul-2023 at 10:10 PM.
Last edited by NutsAboutAmiga on 27-Jul-2023 at 10:05 PM.
Last edited by NutsAboutAmiga on 27-Jul-2023 at 10:02 PM.
Last edited by NutsAboutAmiga on 27-Jul-2023 at 09:57 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

The PiStrom / Emu68 is perfect solution to 68k community, as they can continue writing bad code, that does not care about the OS, because JIT compiler lives outside of the OS its running, similar to how an emulator does it, except motherboard and chipsets are real.

I thought that on AmigaOS4 case at least those chipsets could still be accessed, so in a sense it would be possible for it also to access the hardware when you launch a game, but you would have the OS running full steam. That was it would be interesting, to keep people banging the hardware in this platform-
Quote:

I can’t help thinking about the people screaming defund the police. And then complaining about crime not being done anything about.

Perhaps because they don't see accountability, I don't say defund the police, but surely impunity isn't to be expected, and having about 16 weeks in formation doesn't help either...

Quote:

This what feel about this idea. We know is lack of development on AROS for years, some people just grabbing free stuff put on ISO and calling it AROS distribution, and not funding the developers. Its same stuff being promoted year after year.

I guess you have a point here.
Quote:

Perhaps Vampire developers funded some of the development of Apollo OS, and perhaps PiStorm PCB cards, being sold generate some money, and probably more then they will ever make on AROS version of the JIT compiler but let see what happens. Generally, its hardware that funds the software development. If people don’t need to buy your stuff, then you don’t get any money. if all the developers are getting is bugs reports like, there is “BUG”, and insults, and no money, you can bet they wont stay.

Well it surely will help AROS, but only 68k I guess

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Hammer Quote: 2. Compiler differences. gcc, the compiler used on the Mac, currently can't do some of the more complex optimizations that Visual Studio can on the PC. Especially when inlining small functions, the PC has an advantage. Add to this that the PowerPC has a higher overhead for functional calls, and not having as much inlining drops frame rates another few percentage points. On Macintosh PPC / MacOS9 i susspect that be Symantic C++ compiler, not the typical GCC, they had some speical needs due to there Pascall legacy, non standard delcarations for strings etc. soft floats, so called FIX POINT or something. IBM has had there own C compilers, but its not free, I not sure what platforms they support.

The problem with Barefeat's benchmark method is the use of 1600x1200 resolution which partly shifts the bottleneck toward the GPU. A real CPU benchmark would remove GPU as the bottleneck i.e. benchmark with lower resolution.

With modern games with discrete GPUs, lower latency with CPU pipelines, cache, and I/O bus (northbridge) also matters e.g. Athlon FX-55 has a similar instruction set to Pentium IV / Xeon, but with different results.

Athlon FX-55 has integrated Northbridge which has lower latencies.

The K8 Opteron has a 12-stage pipeline for integer calculations, the 970FX goes deeper and ends up with 16 stages. The floating point is handled through 970FX's 21 stages, and the K8 Opteron only needs 17. Athlon FX-74 reached 3 Ghz with 12 stage pipeline design.

AMD's Bulldozer has deep pipeline design mistakes e.g. 20 stages. AMD learns from Bulldozer mistakes with corrective Zen 1 design. Hardware prediction needs to be good for deeper pipelines CPU design.

https://images.anandtech.com/graphs/athlon%2064%20fx55_10180471040/5064.png
3.4 Ghz Pentium IV Extreme Edition is being beaten by 2 Ghz K8 Athlon 64 3200+.

Intel learns its mistakes with the Core 2 Duo E6600 (2.4 Ghz) which beats K8 Athlon FX-62 (2.8 Ghz) model.

Core 2 Duo's improvements are with medium pipeline depth, quad instruction issues per cycle, and full 128-bit SIMD hardware implementation. 1st generation Core i7 has integrated Northbridge.

The "instruction set" factor is only part of the answer when microarchitecture's hardware implementation also matters.

PPE has a similar PowerPC instruction set and it's slower than PowerPC 970 i.e. microarchitecture's hardware implementation also matters.

It's difficult to design a shortish pipeline "big core" CPU combined with very high speed.

When compared to the previous generation, RDNA 2 and Zen 4 have an extra pipeline stage to improve their high clock speed. Nothing is free.

Last edited by Hammer on 28-Jul-2023 at 02:10 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@ppcamiga1

Quote:

ppcamiga1 wrote: @Hammer Quake I is fast enough even on 30 years old 603. I don't need anything better. I even don't finish Quake II up to now. Amiga 1222 will be good enough for Quake I and Tomb Raider I. It is fast enough for games that I always want to play on Amiga but 25 years ago 68k was too slow and expensive.

Amiga? A-Eon doesn't have AmigaOS OEM and AmigaOne licenses.

For recent A-Eon hardware, the AmigaOS license is pushed down-the-chain distributors.
A-Eon has removed AmigaOne brand from its website.

My PC motherboard manufacturer's website has "design for Windows" markings i.e. "Windows 11 Ready". LOL.

The major reason for Quake benchmark is their use in other games titles.

These days, it's Unreal Engine 4 / 5 and Unity 2022 performance targets. id Software's influence has diminished with the rise of Epic's Unreal Engine 3 / 4 / 5. Only one game uses id Tech 7 engine i.e. Doom Eternal. Five games used id Tech 6 engine. 11 games used id Tech 4 engine.

A-Eon's SystemOS 54 doesn't have Amiga Corporation's AmigaOS and Amiga marks licenses.

PPC situation needs a "designed for Amiga" brand initiative.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@ppcamiga1

Quote:

ppcamiga1 wrote: And it is not pc.

FYI, UBoot has 16-bit X86 VBIOS legacy support.

PC with "UEFI Class 3" does NOT have 16-bit VBIOS and 16-bit MS-DOS support.

Intel ARC does NOT have 16-bit MS-DOS / 16-bit VBIOS support.

Look in the mirror about "not a PC".

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@pixie

Quote:

pixie wrote: @Hammer Quote: Michal Schulz: as soon as my code starts, whether it is the 32bit or 64bit arm code, I switch the big endian mode on. The rest of the emulator, including the supervisor/hypervisor mode of the ARM cpu, is operated in big endian mode. I wonder if it would be possible to use AROS ARM behave like AmigaOs4 then...

From AmigaOS 3.x side, userland apps can access multiple Emu68 instances for multi-threading with the corresponding quad-core ARMs.

AROS SMP version could be ported to multiple core 68K.

Userland 68K emulator with the host OS is the Apple method i.e. it wouldn't survive Amiga 68K WHDLoad.

Commodore Amiga is like a PC's hit-the-metal VGA and it's not Apple Macintosh. The Amiga is not another Macintosh.

Apple enforced the software abstraction layer earlier in the 68K Macintosh era.

Phase 5's selling PPC accelerators in the Apple MacPPC market has a significant influence on Escom-era Amiga Technologies' Amiga's post-68060 direction which then influenced Gateway-era Amiga Inc and ultimately, Hyperion's AmigaOS 4.x PowerPC. There was a backtrack from PPC with Hyperion's 68K Amiga 3.1.4 and 3.2 releases.

The attitude from Amithlon's creator about "we don't play games" smacks in the face of Amiga's core existence.

Phase 5/bPlan camp continued its direction with MorphOS.

For all intents and purposes, both AmigaOS 4.x and MorphOS are foreign to the Commodore Amiga legacy and the bulk of Amiga 68K users refuse to go with the flow.

AROS ARM direction that duplicates MorphOS/AmigaOS 4's userland 68K translation model wouldn't be retro-popular.

Last edited by Hammer on 29-Jul-2023 at 06:51 AM.
Last edited by Hammer on 29-Jul-2023 at 06:44 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

I wonder what type of functional calls are impaired on the PPC. One of the features was a large register file to avoid stack. In fact, since the PPC lacks a stack, a PPC stack is in reality just a software construct abiding to an ABI. So PPC function calls can be all register based and avoid memory. Except for when they pass over 8 parameters and then it gets stacked in memory. The stack frame can be avoided but then you lose the floor if it crashes. PPC must have some penalty for branches despite the design to keep it register based. Aside from needing a middleman register to perform the branch too.