Opinion: PPC, 68080 and other

[specfreak]

Yeah, I read on the discord about possibilities and it's very active and encouraging to read such things, and I understand that it could be a long road, but still exciting.

I've seen some youtube vids using QEMU direct outside of WinUAE to run OS4.1 FE, so I guess it's possible if someone had the inclination to do so.
Could you use a stock A1200's '020 to bootstrap/load into a PiStorm to run a baremetal emulator akin to how EMU68 works and QEMU could? What kind of speeds could the Pi Reach for PPC? When I had OS4.1FE Classic on my A1200 it basically handed over to the PPC chip after a few reboots and then can run 'RunInUAE' giving you OS 3.1 with an '020. Does it emulate the 020 or use the onboard (I think it emulates?)

The people in this community are very clever so I wouldn't be surprised.

[Gorf]

Originally Posted by minator

I stand corrected.

But the slots where not equal:
2 for integer operations and two for floating point.
And only one integer-slot is connected to the barrel-shifter, so only that slot can do multiplications and shifts, while only the other integer-slot can do branching.

So if you need a lot of integer multiplications in a row (like early 3D shooters) you are essentially down to a single issue CPU again.

Alpha 21264 (1998) could to out-of-order execution, but this is still very limited compared to todays CPUs. Well but so could Pentium Pro since 1995.

In terms of OOO there is no distinct RISC advantage - all architectures need to throw a lot of silicone on to it, to make it happen.

To avoid this Intel had the glorious idea to let the compiler do the re-ordering and give the CPU a very long instruction word instead: EPIC
And everyone thought: "This is the way!"
Well ... not so much.
Turns out there is not that much parallelism in the instruction flow of a single thread in real world applications.

[Gorf]

Originally Posted by specfreak

Could you use a stock A1200's '020 to bootstrap/load into a PiStorm to run a baremetal emulator akin to how EMU68 works and QEMU could? What kind of speeds could the Pi Reach for PPC? When I had OS4.1FE Classic on my A1200 it basically handed over to the PPC chip after a few reboots and then can run 'RunInUAE' giving you OS 3.1 with an '020. Does it emulate the 020 or use the onboard (I think it emulates?)

Wouldn't it at that point make more sense to port OS4 or MorphOS to aarch64 instead?

[Samurai_Crow]

Originally Posted by Gorf

Wouldn't it at that point make more sense to port OS4 or MorphOS to aarch64 instead?

Only until the RISC-V pricing model drives the AArch64 into obsolescence. It's discussions like these that make bytecodes more attractive than binary dependencies.

[Thomas Richter]

Originally Posted by Samurai_Crow

Only until the RISC-V pricing model drives the AArch64 into obsolescence. It's discussions like these that make bytecodes more attractive than binary dependencies.

Do you really think RiscV will ever take off? There is an entire mobile market behind arm with sufficient financial power to drive the chip development, though is there sufficient market penetration for RiscV? There is a bit high-performance, and a bit embedded where RiscV is used/sold as add-on to an FPGA, but what else?

[Gorf]

Originally Posted by Samurai_Crow

Only until the RISC-V pricing model drives the AArch64 into obsolescence. It's discussions like these that make bytecodes more attractive than binary dependencies.

I agree on the bytecode part. Or at least some intermediate representation, that gets compiled at install-time.
Amiga actually has some history with that: Elate/Tao was actually a smart concept ... ahead of its time I guess.

As for RISC-V vs. ARM, I am not so sure yet. At high volume the license fees for ARM are not really a big deal, but these partnerships and the generated income ensure ARM's constant development, while on RISC-V everything is down to the individual companies, which might not share their implementation details or any IP. It will be interesting so watch the outcome of this battle.

[Samurai_Crow]

Originally Posted by Thomas Richter

Do you really think RiscV will ever take off? There is an entire mobile market behind arm with sufficient financial power to drive the chip development, though is there sufficient market penetration for RiscV? There is a bit high-performance, and a bit embedded where RiscV is used/sold as add-on to an FPGA, but what else?

If the mobile market stuck with Java's bytecodes instead of compiling to ARM binary formats, they would have been free to jump ship to any instruction set Android could be ported to. Now that Oracle's pricing scheme for enterprise scale Java is driving people into the arms of WebAssembly, the same could happen to ARM shortly thereafter.

The only real difference in an OOO performance core is the instruction cracker and maybe some tweaks throughout the pipeline. If those pipeline tweaks are the same as an efficiency core's tweaks, ARM may need to watch themselves. Switching architectures from a custom core licensing the AArch64 instruction set could be some experiments away from becoming an equally performant RISC-V with no license required.

Re Intel and AMD CISC:
In order to simplify Intel's cores they are looking at ways to drop the 16 and 32 bit compatibility. This will shrink the cores' real-estate on-chip but ultimately ARM is edging them out by issuing instruction-set only licensing combined with RISC-V being free-to-use non-profit.

With all the problems Intel has been having with their latest 2-generations of chips, compounded by their in-house production processes barely getting smaller than 14 nM variants a few years ago, could spell the beginning of Intel focusing on being fab-only and AMD being fabless.

Finally, Intel and AMD build all the same stuff so if Intel focuses on competing with TSMC on the fab-side and with AMD being dependent on TSMC for their production end we'll just have to see whether x86-64 can last with just AMD designing and Intel building. This is hypothetical but likely.

Re:China
China doesn't like that x86 and ARM are controlled by western nations so their MIPS-derived Longsoon CPUs may not have enough market left with RISC-V in the picture. In the end, China needs high-performance semiconductors without political baggage and RISC-V has it in spades compared to anything in China's Marxist philosophy's influence.

TL; DR:
China is the wildcard here: if RISC-V drives out Longsoon and grows there, ARM loses out. If Intel shifts from design and production to just production, AMD is forced to pick up x86's slack and x86-64 slackens. If WebAssembly takes over Java's lunch ticket, instruction-set based ship-jumping commences.

[hammer]

Originally Posted by Thomas Richter

Do you really think RiscV will ever take off? There is an entire mobile market behind arm with sufficient financial power to drive the chip development, though is there sufficient market penetration for RiscV? There is a bit high-performance, and a bit embedded where RiscV is used/sold as add-on to an FPGA, but what else?

Google officially drops RISC-V from Android. https://www.theregister.com/2024/05/...ndroid_pulled/

[hammer]

Originally Posted by Samurai_Crow

Re Intel and AMD CISC:
In order to simplify Intel's cores they are looking at ways to drop the 16 and 32 bit compatibility. This will shrink the cores' real-estate on-chip but ultimately ARM is edging them out by issuing instruction-set only licensing combined with RISC-V being free-to-use non-profit.

Decoders consume very tiny chip area space and micro-ops are the same.

x86-64v1 is no longer patented and can be freely used by anyone.

Since 2013, game consoles have defined the minimum AVX usage for gaming PCs.

[NorthWay]

Originally Posted by Gorf

Turns out there is not that much parallelism in the instruction flow of a single thread in real world applications.

There is still Mill who are betting their boat against the commonly accepted truth of that. I'm a bit worried about the silence from that direction, because I like a _lot_ of their ideas. (If I was to do a 64bit Amiga-like (SAS)OS I'd hope they would deliver so it could be my target.)

[Samurai_Crow]

Originally Posted by hammer

Google officially drops RISC-V from Android. https://www.theregister.com/2024/05/...ndroid_pulled/

Google is also a western IP holding and China wants to replace Android too.

[Thomas Richter]

Originally Posted by Gorf

Amiga actually has some history with that: Elate/Tao was actually a smart concept ... ahead of its time I guess.

No, behind its time. This was just a "me-too" product to mirror what Java bytecode already offered. Ok, Java was stack-based, Tao was register-based, but if you have to compile it to the target machine in the end, it does not matter. No competative company with sufficient development resources behind it, and adressing a niche that was too similar to Java. Pointless, and mission to fail.

Originally Posted by Gorf

As for RISC-V vs. ARM, I am not so sure yet. At high volume the license fees for ARM are not really a big deal, but these partnerships and the generated income ensure ARM's constant development, while on RISC-V everything is down to the individual companies, which might not share their implementation details or any IP. It will be interesting so watch the outcome of this battle.

The battle is already over - arm has the market volume and market share, and "the winner takes it all". People are going mobile, and mobile is arm. It's not a bad architecture, and surely a lot more orthogonal than the insane x86 chips. Luckely, "Windows Mobile" never took off. Too bad for Nokia, but what a relief for the engineers...

[Samurai_Crow]

Re:bytecodes
Java was interpreted and JIT when Tao/Elate was AOT. Tao was unprofitable and sold its design to Sun before they (Sun) folded and sold out to Oracle. Now that WebAssembly is an open standard, JavaScript can become an alternate runtime for it and the rest can just fold.

Java and Elate were too object-oriented for their own good (as is JavaScript for that matter) but the WebAssembly bytecode can build just about anything, depending on the runtime standard followed. Once the WASI standard develops a full enough WebAssembly runtime for systems programming, native instruction sets are window-dressing and only for decoration.

[Promilus]

Originally Posted by Gorf

But the slots where not equal:
2 for integer operations and two for floating point.
And only one integer-slot is connected to the barrel-shifter, so only that slot can do multiplications and shifts, while only the other integer-slot can do branching.

So if you need a lot of integer multiplications in a row (like early 3D shooters) you are essentially down to a single issue CPU again.

It's typical usage of that time and guess what - still practiced nowadays. Integer pipelines are by no means symmetrical. And that processor was still faster than processors used when those old shooters were released. And everything else runs much faster thanks to multiple execution pipelines. There's also address generation...

In terms of OOO there is no distinct RISC advantage - all architectures need to throw a lot of silicone on to it, to make it happen.

It's easier to predict streamlined ISA of RISC (especially with fixed instruction size) than the flow of rather complicated CISC and it's encoding. I.e. it's easier to shuffle instructions resulting 1uop than those translated to 1, 2, 3 (or more!)

To avoid this Intel had the glorious idea to let the compiler do the re-ordering and give the CPU a very long instruction word instead: EPIC

Not really. That wasn't entirely their idea. It was actually HP idea they sold to Intel claiming it will kill both x86 and PPC. Yeah, the same HP that invented PA RISC with ultra big cache (and which commodore did want to implement with absolutely tiny cache). Sooo... yeah.

[Gorf]

Originally Posted by Thomas Richter

No, behind its time. This was just a "me-too" product to mirror what Java bytecode already offered.

It would be the other way around, since TAOS is older than the JVM

https://news.ycombinator.com/item?id=37209998
https://news.ycombinator.com/item?id=9808159

And as mentioned above TAOS was originally AOT and not JIT

[hammer]

Originally Posted by Samurai_Crow

Google is also a western IP holding and China wants to replace Android too.

RPC is heavily using West's open-source Linux.

There's nothing new with Communist's state-owned/state-controlled OS and CPU rough copies.

Due to RPC's WTO failure, both the USA and the EU have executed their respective 'CHIPS' Acts.

Smart missiles and drones require the mentioned IP areas.

From https://medium.com/discourse/tsmc-th...an-be0774531bb

In the 1970s and 1980s, the Taiwanese government gave the semiconductor industry strategic priority for development.


Historical context is important. There's a reason why the USSR was trade-blocked from the WTO trade zone.

[hammer]

Originally Posted by Gorf

I agree on the bytecode part. Or at least some intermediate representation, that gets compiled at install-time.
Amiga actually has some history with that: Elate/Tao was actually a smart concept ... ahead of its time I guess.

As for RISC-V vs. ARM, I am not so sure yet. At high volume the license fees for ARM are not really a big deal, but these partnerships and the generated income ensure ARM's constant development, while on RISC-V everything is down to the individual companies, which might not share their implementation details or any IP. It will be interesting so watch the outcome of this battle.

RISC-V is fragmented and it's not unified like the X86 PC platform. Common CPU ISA is not enough for a unified platform.

My NVIDIA RTX has a customized RISC-V microcontroller and it's meanless for application programmers.

With RISC-V ISA, the "losers" are the microcontroller vendors with proprietary instruction sets e.g. ARC (Argonaut RISC Core). ARC switched to RISC-V known as ARC-V as an extension for ARC product line.

Seagate uses RISC-V ISA, but the actual hardware implementation is proprietary.