@kolla

Quote:

kolla wrote: @matthey Quote: 68060 units which can issue/execute/retire/fold instructions in parallel 2x integer units (equivalent of load/store unit in each integer unit) 1x branch unit 1x FPU That’s not the point, which was about code execution in an emulated 68k vs a real 68060, running AmigaOS - AmigaOS code doesn’t expect the CPU to do things in parallel (even when it does)

Parallel execution here was about instruction-level parallelism. Which was, and is, doable even on the Amiga os..
Quote:

so emulation of CPU isn’t nearly as "critical" as having chipset components running independently from each other and the CPU.

It is, if you need perfect compatibility with plenty of games.

@minator

Quote:

minator wrote: Will try again... CISC may make code smaller but has an opposite effect on silicon. In fact it has an enormous cost on silicon area and complexity. The 060 was $308 The MIPS R4200 had similar performance and lower power (about 2W) at around $50. 2 years later the StrongARM gave 2x the performance, required under 0.5 Watts and cost $29. The 060 was very RISCy for a CISC chip and a worthy end to the 68K line, but RISC outperformed it at the high end and undercut it at the low end.

That's mainly because of two reasons.

First, Motorola bad management: they had a very good product which they sold for too high price. And they decided to kill it, jumping on the RISC wagon due to the academic propaganda.

Second, there's really no RISC. In fact, they are all CISCs. The reason is very simple: they give up at the RISC's foundations / principles in order to delivery real-world products.

There's also a third one, which is the most important when talking about the RISC vs CISC everlasting debate: CISC processors were very old designs, which carried over bad decisions and legacy burdens. Whereas the so called RISCs starter from scratch with new designs and no legacy baggage.

A modern CISC architecture designed from scratch as well can easily draw circles around any so called RISC architecture.
I've at least two proofs of that (my NEx64T architecture, and especially new one), but I can easily provide more (a 68k-inspired one, for example).

@matthey

Quote:

matthey wrote: minator [quote] The 060 was very RISCy for a CISC chip and a worthy end to the 68K line, but RISC outperformed it at the high end and undercut it at the low end. v In Amiga Bill's interview of Joe Circello, someone asked Joe a question kind of like whether the 68060 breaks down instructions to RISC like micro-ops and actually has a RISC execution pipeline inside as some people think is the case for x86(-64) cores too. The 68060 does not waste transistors and power breaking down instructions into micro-ops and the superscalar execution pipelines are executing powerful CISC instructions accessing cache/memory in a single cycle. It is doing all this without microcode which every x86(-64) core design I am aware of including the Cyrix CPUs/cores above are using.

You can avoid microcode even on x86/x64 processors, if you want, by using proper millicode, for example. But then you're giving up on performance. Which could be absolutely fine for instructions like AAA, AAD, etc., but not convenient, at all, on much more useful ones like REP MOVSx or REP STOSx (which are one of the reasons why x86/x64 provides very compact and performant code on common activities like memory move or clear/store).

Microcode isn't an evil per sé: it's functional about what you want/need to achieve.

For example, you can use microcode for walking MMU pages: very practical, easier and convenient to implement compared to direct logic.
Quote:

Joe Circello made statements about RISC mistakes and RISC-V people relearning lost knowledge as he wears a RISC-V shirt and jokes about it. Inside the Motorola 68060 & Chip Design: Interview with Lead Designer Joe Circello! https://www.youtube.com/watch?v=1takr2k7Yfo I do not know if Joe is even aware of how good and far ahead of its time the 68060 was. The price efficiency was sabotaged by not clocking it up but it was still a market success for embedded use. The tech needs to be scaled up for better performance instead of castrating it and scaling it down into ColdFire. The 68k is more difficult to pipeline than x86 but I believe it can be more powerful and more power efficient and the 68060 is proof that it can be successfully pipelined. The 68060 still has performance advantages over the P5 Pentium, Cyrix 6x86 and SiFive Series 7. The only question is how well it can be clocked up with its deep for the time 8-stage pipeline and that was a question Joe was not asked in the interview. CPU max clock rating @ ~500nm process size with pipeline stages and MHz/stage ARM710@40MHz 3-stage 13MHz/stage PPC601+@120MHz 4-stage 30MHz/stage PPC603@160MHz 4-stage 40MHz/stage Pentium P54C@120MHz 5-stage 24MHz/stage PPC604@180MHz 6-stage 30MHz/stage X704@~500MHz 6-stage 83MHz/stage HP PA-8000@180MHz 7-stage 26MHz/stage Alpha 21064@300MHz 7-stage 43MHz/stage MIPS R4400@200MHz 8-stage 25MHz/stage 68060@50MHz 8-stage 6MHz/stage Average MHz/stage: 32MHz/stage I do not believe the problem was technical. Low end PPC cores used shallow pipelines and static branch prediction to save area and power too. The PPC603(e) core design did not get deeper pipelines and dynamic branch prediction until the PPC G3 in 1997. The PPC was designated for high end embedded use and the 68k/CF was designated for low end use below where fat PPC would scale. Sadly, Moto did not know the RISC-V research even as they had to quickly double the caches of PPC603 with only 1.8 million transistors into the PPC603e now using 2.6 million transistors, more transistors than the 68060 and still not reaching the instruction cache performance. The 68060 also has a deeper pipeline for clocking up more, more superscalar processing units and dynamic branch prediction which explains why it could not be clocked up.

68060's pipelining and clocking-up issues might be related to the intrinsic nature of its architecture.

16-bit "fragmented" opcodes with many exceptions required a 16-bit LUT which was not only very expensive in terms of transistors used, but could have also hit on the maximum clock reachable by the chip.

Another reason could have been the difficulty on getting the right instructions lengths (68060 can execute two instructions, so it has double this problem) due to extension words.

And another problem could be related to the double-indirect memory addressing modes, which were/are very complicated to implement on a (super)pipelined processor.

Perhaps all of them have contributed to the clocking-up issues.

Something that could give at least some information (I don't want to talk about a final proof) might come from an implementation on the same FPGA, and comparing it to a "similar" (e.g. designed for performance, as best as possible) other architectures implementation.
For example, a 68060-like design compared against a PowerPC G2 (?) and/or Pentium design on the same FPGA to check which maximum frequency can be reach by all of them.

@kolla

Quote:

kolla wrote: @matthey Why are you arguing with yourself? Why do you stack your reasoning backwards? My point is simple: emulating the 68k CPU while keeping the chipset

Why not emulating the chipset as well?
Quote:

be it "real" or FPGA - separate, as we do with PiStorm/Emu68, has advantages over emulating the entire Amiga in software. Of course, this advantage only exists in so far you actually _use_ the chipset,

About which "advantages" are you talking about?
Quote:

once you’re only using P96 and AHI those advantages are gone and you may just as well stick to plain software emulation. So exactly why do you insist that software emulation of _just_ the CPU is "bad", and then drag in UAE variants - where CPU _and_ chipset are emulated, sequentially - as an argument? Yes, (classic) Amiga needs 68k, but whether that CPU is implemented in software emulation or hardware is of very little importance compared to whether the chipset too is emulated in software or hardware.

I reveal you a secret: they same thing can be said about the chipset.
Quote:

So, next giant wall of (repetitive, irrelevant, pointless) text coming up, I guess…

At least it's very interesting, whereas your questions and arguing are have no technical foundations.

@thread

Quote:

kolla wrote: ... emulating the 68k CPU while keeping the chipset - be it "real" or FPGA ...

Just for information, this was already done, for example Minimig ITX with PiStorm:
https://www.youtube.com/watch?v=ojApXc5e6q4

Pocket storm 20k:
https://bsky.app/profile/did:plc:yh5grkvtvwhf6y2h6jzdnfha

----

But if someone here dreams of a 'big player' selling it as an Amiga compatible computer, with the sacred name 'Amiga' on the custom made keyboard case, this might never happen.

cdimauro Quote:

OK, but old applications for such very old systems don't require Ghz machines to obtain a much better user experience with this kind of software (games usually don't need faster hardware. On the exact contrary, they need the exact hardware to avoid glitches/issues). You can pump a lot their emulated processors even on cheap FPGA systems, offering a vastly superior experience.

Most Amiga games work with a higher CPU clock speed because timing is usually based on screen refresh. There are some Amiga games with CPU timing loops and there are some games with bugs like missing WaitBlit() but most of those have been fixed with WHDLoad. I expect more Amiga games to break because of requiring a 68000 or a specific version of the AmigaOS but those are mostly early games.

Some of the other 68k systems would need a 68000 core and finer clock speed control for good compatibility. Fully static CMOS CPU cores like the 68060 allow a clock speed from max to zero. An extra clock source or two and finer control of clock speeds on a per core basis should allow to lower clock speeds to original frequencies or as close as possible. Even the NeoGeo console has good compatibility with a small CPU overclock from 68000@12MHz up to about 68000@14MHz with some games benefiting from a 68000@24MHz as supported by MiSTer, Analogue FPGA hardware and possibly the upcoming Neo Geo AES+. Three clock sources should cover most 68k retro timing needs.

Common: 4, 8, 12, 16, 20, 24
PAL: 3.55, 7.09, 14.18
NTSC: 3.58, 7.16, 14.32

https://wiki.neogeodev.org/index.php/Overclocking

cdimauro Quote:

I don't see applications...

The included Amiga Forever applications are on the Amiga boot drive. There is much more functionality and quality than what Commodore included with the AmigaOS.

cdimauro Quote:

Emulation could not be accurate only because the precise specs / schematics aren't available. There's nothing, theoretically, which prevents emulation to be perfect. Either you decide to emulate a system in software (via regular processors) or in hardware (FPGA), or don't go through emulatation at all (ASIC), you require its complete schemas in order to have a perfect replica of the original.

Emulation can be accurate but requires powerful and expensive hardware to emulate much weaker hardware. It is also more difficult with a non-RTOS.

cdimauro Quote:

Right. IF you've the a good volume then an ASIC is much cheaper than any emulation-based system, for obvious reasons. Specifically, you need to embedded several cores for retro purposes. To support several 68k systems then you need at least: - a 68000 (better if it can support a 68010, and you can select at boot time if you want a 68000 or a 68010) with perfect cycle timings / behavior; - a 68020 (cycle timings are important, but they can be less precise here). Better if it can support a 68030 as well (selectable at boot time, of course), since they are very similar; - a super fast 68040/68060 (selectable at boot time). I propose to add another not-cycle-exact 68000 or 68020 (the cheapest to implement) as a "system processor", only used for controlling the entire platform and to implement the GUI / user interface with OSD graphics etc.. Since retro systems have other processors from different families, it'd be good to provide some cores of them (6502/6510/8502, 8085, 8086, z80, z180, ...) as well.

I do not know about an extra 68020/68030 core. I suppose it depends on how well a modernized 68k core could be downgraded for compatibility. The problem with 6502 family cores is that there were many variations and it would be difficult to have one super configurable core. A 65C816 would come close to gaining super valuable SNES and Apple IIGS compatibility but the SNES version is highly customized. A Z80 core is interesting as it was more standard and a common companion in 68k hardware like the NeoGeo, Sega Genesis/Mega Drive, Capcom CPS-1 & CPS-2 Arcade boards, Torch Unicorn and Cifer 68k Systems. Ok, maybe the last 2 are not so important but Arcade games could be a draw as MiSTer supports them. ASIC CPUs with FPGA chipsets would give a cost reduced MiSTer. Small 8-bit CPUs are cheap enough to provide in a FPGA depending on if and how much the FPGA resources are reduced. MiSTer can easily handle 8-bit CPUs with chipsets. The problem is with high performance CPU cores where a 486 CPU alone barely fits in the MiSTer FPGA.

cdimauro Quote:

ASICs are VERY convenient because they can use several million transistors and yet they cost a single dollar, or even less.

The RP2350 MCU has 520 kiB of SRAM and sells for ~$1 USD.

520 kiB * 1024 B/kiB = 532,480 B * 8 b/B = 4,259,840 b * 6 transistors/b = 25,559,040 transistors

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

ASICs can use tens of millions of transistors for ~$1 USD. A 68060&AA+ ASIC uses about 3 million transistors or about 11% of the transistors so would an ASIC cost $0.11 USD? Probably not as package and testing costs would not likely go down proportionately but the RP3250 is the RPI selling price and not their cost. The cost is likely roughly 1/3 of the ~$1 USD price.

cdimauro Quote:

So, all of the above is certainly doable, but it requires some experts to work on it and design this retro platform in a manner that it's usable to emulate most of the systems. Which means that the ASIC should also provide some "basic blocks" like embedded memories which are available and usable depending on the system to emulate. Another important thing is regulating the priorities on accessing the memory by the various components. As we know, retro simulation requires very precise timings, and the above cores need to be carefully controlled on when and how they can access the memory. I've no idea on how to do it, because there are plenty of systems which exists, and they have their own quirks (Amiga has its own due to the chip mem vs chipset vs fast mem). Anyway, ON PAPER it's possible to design a single, very cheap, ASIC which can support multiple systems, and that provides much better value compared to any existing solutions. But IMO it's very difficult to design and implement it.

Experienced MiSTer developers like those working on the NeoGeo AES+ could provide universal retro system knowledge. There are many possible 68k Amiga hardware and FPGA experts. Most of the 68k Amiga developers are still alive. Good CPU architects are more difficult to come by but the original 68060 chief architect, Joe Circello, has connections to the Amiga as we found out in the recent Amiga Bill video. Architect Mitch Alsup likes the 68k better than RISC-V too. Obtaining the 68060 sources would be key as it would save a huge amount of time. Many other retro resources needed could likely be used from the MiSTer and other FPGA projects so they are less of a problem.

cdimauro Quote:

Are you sure that a commercial "retro-platform" (like the one which I've proposed above) has no royalties to pay to any CPU vendor?

No, but retro CPU trademarks are expired. Copyrights could be a problem for reverse engineered exact CPU copies in some cases but MiSTer cores are usually reimplementations. The ROMs and chipsets are more of a concern for copyright violations but using a FPGA for them would be like MiSTer. Some are open source like for the X68000 while it may be worth trying to license some others.

cdimauro Quote:

5.2Ghz on a 7nm node process isn't realistic, at all, for a super pumped 68k core.

I agree that a 5 GHz clock speed is unrealistic. There are only a handful of businesses that produce chips with 5 GHz clock speeds including Intel, AMD, IBM, Apple and Qualcomm. There is a giant leap in cost from targeting 8-stage in-order CPU cores to 12-16 stage OoO CPU cores. I expect more along the lines of SiFive development where the SiFive 8-stage in-order series 7 CPU core, which is similar to the 68060, has only reached 1.5 GHz with an 8-stage pipeline at 28nm in the VisionFive 2 SBC. SiFive has only reached 3.4 GHz with the OoO P670 13-stage pipeline at 5nm. The 7nm process may not be too far off to target as I was thinking 10nm-40nm. While 7nm may sound too advanced, an ASIC would likely take 1.5 years of development before production if everything worked out. An ~14nm process may be more practical and may reach 2 GHz or more. ColdFire v5 added an extra pipeline stage to 9-stage and split the instruction and data/operand fetch stages in two, likely as much to allow larger L1 caches as to clock it up. Larger caches have slower access times which can limit the max clock and is the reason we have multilevel caches. Newer chip fab processes increase cache access times and the 32kiB L1 caches the ColdFire v5 used are the most common size today while the most popular in-order CPU depth is 8-stage with few pipelines of this depth splitting the accesses. ColdFire v6 was planned to be superpipelined which Joe mentioned in his interview but the days of super deep pipelines and extreme clock speeds are mostly over.

cdimauro Quote:

You can avoid microcode even on x86/x64 processors, if you want, by using proper millicode, for example. But then you're giving up on performance. Which could be absolutely fine for instructions like AAA, AAD, etc., but not convenient, at all, on much more useful ones like REP MOVSx or REP STOSx (which are one of the reasons why x86/x64 provides very compact and performant code on common activities like memory move or clear/store). Microcode isn't an evil per sé: it's functional about what you want/need to achieve. For example, you can use microcode for walking MMU pages: very practical, easier and convenient to implement compared to direct logic.

I am not anti microcode or millicode even though CPUs that used microcode were usually larger and had reduced performance where the microcode was used. The 68000 supposedly used between 1/4 and 1/3 more transistors because of the microcode design and I believe every 68k CPU design used microcode until the 68060. It was an amazing feat to develop such an advanced CISC CPU with no microcode and with so few bugs and delays. Usually the microcode CPU cores are easier to develop and allow changing the microcode later in development but it was the microcoded buggy and late 68040 which sank the 68k where the non-microcoded 68060 had no such problems.

cdimauro Quote:

68060's pipelining and clocking-up issues might be related to the intrinsic nature of its architecture.

Joe called the 68k a clean architecture which he could not say about x86.

Last edited by matthey on 17-Jun-2026 at 08:48 PM.

Quote:

matthey wrote:

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@cdimauro

Quote:

That's mainly because of two reasons. First, Motorola bad management: they had a very good product which they sold for too high price.

They were certainly known for overpricing things, the 88100 chips were almost $2000 to make a system.
The problem with the 060 is it was too expensive to make for an embedded chip. It was a 200 sq mm chip competing against chips less than half that size. R4200 was only 81 sq mm.

OTOH the 060 was cheap compared to the Pentium, but by the time the 060 shipped the Pentium was at 100MHz, and outperformed it. Even it had scaled with the Pentium, it would still be well behind the workstation chips and the Pentium Pro would have destroyed it the following year.

Quote:

And they decided to kill it, jumping on the RISC wagon due to the academic propaganda.

RISC wasn't an academic thing, it came from an IBM project to build a phone switch but turned into a very fast general purpose processor. All that became known as RISC was in the IBM 801.

It also wasn't propaganda. In the early to mid 80s Motorola dominated the workstation space. Then the Sun SPARC appeared and it destroyed the 68030 on performance. That's what killed the high end 68K.

Most workstation vendors went with their own RISC chips, Apple and NeXT selected the 88000 series but chose to wait for the single chip 88110. It came out in 2 years before the 060 at a higher performance level.

The PowerPC alliance replaced the 88K series before the 88110 shipped and both Apple and NeXT went with PowerPC (NeXT cancelled their RISC machine before it hit the market).

Quote:

Second, there's really no RISC. In fact, they are all CISCs.

I'd say the opposite, most if not all true CISCs went out of production decades ago.

Quote:

The reason is very simple: they give up at the RISC's foundations / principles in order to delivery real-world products.

What do you think the founding principles were?


Quote:

A modern CISC architecture designed from scratch as well can easily draw circles around any so called RISC architecture. I've at least two proofs of that (my NEx64T architecture, and especially new one), but I can easily provide more (a 68k-inspired one, for example)

A proof would be a functioning chip, or at least a simulation of one.

Last edited by minator on 18-Jun-2026 at 12:32 PM.
Last edited by minator on 18-Jun-2026 at 12:31 PM.
Last edited by minator on 18-Jun-2026 at 12:30 PM.

_________________
Whyzzat?

minator Quote:

They were certainly known for overpricing things, the 88100 chips were almost $2000 to make a system. The problem with the 060 is it was too expensive to make for an embedded chip. It was a 200 sq mm chip competing against chips less than half that size. R4200 was only 81 sq mm.

The better chip developers charged a premium price but did not always provide a better product. The 88110 was lackluster, later than MIPS and SPARC offerings and the many chip systems made it very expensive, unlike minimal chip 68k CPUs. The 88110 is a good design and was a big improvement although it would have been better as a 64-bit CPU, especially for SIMD instructions. Both the 88k and PA-RISC SIMD instructions operated on integer registers while x86 SIMD and many others either had separate SIMD registers or shared them with the FPU. Adding FP SIMD instructions puts FP values in int registers although the 88k already supported this with an unusual register layout. I prefer the 88k and PA-RISC RISC ISAs to simplistic MIPS, SPARC and Alpha ISAs but they all made RISC mistakes. Motorola was also too proud of their late and mediocre 68040 as they tried to recoup development costs with a high price despite the diminished competitiveness by the time it was released. The high power draw and heat limited the max clock more than expected as well. This was all fixed with the reasonably priced and cool operating 68060 but Motorola had already lost many customers including the workstation and desktop markets. The 68060 was expensive for the much smaller high end embedded market then but it was still a success delivering very good int performance without needing to clock it up, which is an advantage for the embedded market. The 68060 gained the benefits of and solved the challenges of a deeper pipeline and superscalar execution at the same time which provided synergies and was ahead of most desktop CPUs which failed or did not try even though 8-stage in-order superscalar CPU designs are the most popular in the world today. DEC Alpha architects had an advanced 7-stage superscalar CPU design but they were handicapped by the Alpha ISA bad code density which led to the introduction of the L2 cache. The 68060 design is less extreme and more practical but no less elegant than Alpha designs while benefiting from code density and one of the easiest to use ISAs ever. It is a shame such a super high tech design was not clocked up as planned and was only used in the small high end embedded market.

The ACE consortium and AIM alliance drank the RISC Kool-Aid and decided to replace CISC on the desktop. Windows NT introduced support for Alpha and MIPS in 1993 and PPC in 1995. The P5 Pentium was just introduced in 1993 and the 486 was still in many lowed end PCs up until about 1995. The MIPS R4200 was introduced as low end competition for the 486 on the desktop at a very aggressive price, which was likely required to take market share from x86, but still failed. The R4200 was a higher tech design, had larger caches (16kiB-i & 8kiB-d) and targeted a newer fab processes than the older 486. It was more comparable to the Cyrix 5x86 which was also higher tech, had more caches and outperformed the 486. The R4200 was a small and low power scalar core which doubled for embedded use but it was a return to the classic 5-stage RISC pipeline with FP support added in the same pipeline instead of a separate FPU.

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

MIPS Reaches New Lows With R4200 Design
https://www.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/070701.pdf Quote:

Integer and FP Data Path Combined To further reduce the die area, the designers came up with an unusual strategy of performing floating-point calculations using the integer data path instead of having a separate FP unit. This doesn’t mean that FP instructions are “emulated� using integer operations; the combined data path is enhanced to handle both types of math. Since the MIPS-III architecture specifies 64-bit integers, handling double-precision floating-point numbers in the same data path does not increase its width. ... Pipeline Similar to R3000 The R4200 reverts to the five-stage pipeline used by the R3000; the R4400’s eight-stage pipeline was deemed too complex for a low-cost chip. The five-stage pipe requires less bypass circuitry and has only a single-cycle stall for branches and loads. With fewer and shorter stalls, the shorter pipeline can use a lower clock rate to achieve a given performance level, thus reducing power consumption.

Recall that the MIPS R4000 and R4400 cores switched to 8-stage pipelines with the deeper pipeline providing instruction level parallelism (ILP) equivalent to superscalar execution but with less resource costs according to them. The 68060 gains the performance benefits of an 8-stage pipeline (while avoiding RISC load-to-use stalls and handling branches better than the R4x00), superscalar execution and a FPU that operates in parallel, all with synergies, but there is a resource cost. The R4200 was a simple cheap RISC CPU that could be clocked up but it is easy to make simple RISC CPUs, the reason there were so many RISC ISAs. The challenge is making RISC CPU cores high performance. The R4200 pipeline has one ALU which is used for ALU operations (add, logic, shift), AGU operations (address mode calc) and FPU operations. The 68060 pipelines has 5 ALUs with 2xAGU (more powerful 3 input ALUs instead of 2 input), 2xALU and FPU ALU(s) which can all be used in parallel. Instructions have to loop through the shallow R4200 pipeline multiple times while the 68060 can execute instructions with single cycle throughput that are the equivalent of 2 RISC instructions, include cached memory accesses and avoid load-to-use stalls (~25% of instructions are loads). The 68060 can additionally fold away predicted branches and execute FPU instructions in parallel further increasing ILP. Also, the 68060 has lower instruction latencies for MUL, DIV and FPU instructions by devoting more resources. It is an insult to compare the R4200 to a 68060. The 68060 outperformed the MIPS high end R4000 and R4400 but at least they remained competitive with the ability to add expensive high performance L2 caches to support their overtaxed L1 instruction caches and avoid their multiplexed memory busses. As soon as talking about L2 cache transistors/area, all that extra 68060 hardware for performance is payed for by the 68k code density. A MIPS CPU had to execute 33% more instructions than a PA-RISC CPU, which still suffers from a RISC ISA with 8% of instructions NOPs, not enough displacement bits in some instructions and 3 instructions needed for FP branches. At least MIPS developers relented and added pipeline interlocks and result forwarding/bypassing. MIPS is the ISA RISC-V is based on though.

Computer Organization and Design (RISC-V Edition)
https://www.cs.sfu.ca/~ashriram/Courses/CS295/assets/books/HandP_RISCV.pdf Quote:

The good news is that an open instruction set that adheres closely to the RISC principles has recently debuted, and it is rapidly gaining a following. RISC-V, which was developed originally at UC Berkeley, not only cleans up the quirks of the MIPS instruction set, but it offers a simple, elegant, modern take on what instruction sets should look like in 2017.

The book linked is written by David Patterson and John Hennessy. I hope you recognize the names and understand their significance. Actually, not that much changed from MIPS except the combined compare and branch instructions and many later MIPS instructions becoming optional extensions to scale lower. Pay no attention to performance handicaps due to lack of addressing modes and too many instructions executed though. David Patterson has been good at promoting and hyping RISC and bringing back the failed MIPS as an open source RISC-V has been successful unlike the OpenPOWER attempt to revive dead PPC.

The book above has an interesting comment about the 68k.

Computer Organization and Design (RISC-V Edition)
https://www.cs.sfu.ca/~ashriram/Courses/CS295/assets/books/HandP_RISCV.pdf Quote:

x86 Conclusion Intel had a 16-bit microprocessor two years before its competitors’ more elegant architectures, such as the Motorola 68000, and this head start led to the selection of the 8086 as the CPU for the IBM PC. Intel engineers generally acknowledge that the x86 is more difficult to build than computers like RISC-V and MIPS, but the large market meant in the PC era that AMD and Intel could afford more resources to help overcome the added complexity. What the x86 lacks in style, it rectifies with market size, making it beautiful from the right perspective. Its saving grace is that the most frequently used x86 architectural components are not too difficult to implement, as AMD and Intel have demonstrated by rapidly improving performance of integer programs since 1978. To get that performance, compilers must avoid the portions of the architecture that are hard to implement fast. In the post-PC era, however, despite considerable architectural and manufacturing expertise, x86 has not yet been competitive in the personal mobile device.

David Patterson and John Hennessy call the 68k elegant. Joe Circello chief architect of the 68060 calls the 68k architecture clean. Most authors I have read have described the 68k as orthogonal and I believe it is more orthogonal than RISC-V with embedded extensions now. IBM's bad choice and AIM to kill the more elegant, cleaner and more orthogonal architecture was a success.

minator Quote:

OTOH the 060 was cheap compared to the Pentium, but by the time the 060 shipped the Pentium was at 100MHz, and outperformed it. Even it had scaled with the Pentium, it would still be well behind the workstation chips and the Pentium Pro would have destroyed it the following year.

The 68060 has 40% better integer performance than the P5 Pentium at the same frequency according to Bytemark benchmark and should have been able to clock significantly faster due to the longer pipeline. This is not that far from the P6 Pentium int performance, the planned 68060+ claimed 20%-30% performance improvement which likely included doubling the cache sizes and the 68060 would have been much cheaper as the 68060 uses fewer than half the transistors of the Pentium Pro. The Pentium Pro was a very expensive chip with 2 dies in the same package. One die included the fat OoO CPU that could still only fit 8 kiB-i + 8kiB-d and a 2nd die with an L2 cache. Intel did not retire their in-order P5 Pentium but added a pipeline stage to 6-stage, doubled the caches and added MMX (SIMD unit) before the Pentium Pro because there was more free room on an affordable die. The lower priced P5 Pentium remained available for years. The 68060 had more available die area than the P5 Pentium and with a deeper 8-stage pipeline to out clock it. The Pentium Pro did have a deep superpipelined 14-stage pipeline which would have allowed it to out clock the 68060 but it was not refined enough to gain fully from it and similar designs returned to a more practical 10-12 stage pipeline later. The P5 Pentium suffers from lack of x86 orthogonality and x86 baggage so Intel moved to all OoO cores for awhile but returned with the in-order Bonnell (Atom) to try to be "competitive in the personal mobile device" but gave up, likely due to lower margins for the market.

minator Quote:

RISC wasn't an academic thing, it came from an IBM project to build a phone switch but turned into a very fast general purpose processor. All that became known as RISC was in the IBM 801.

MIPS and SPARC were products of academia and they were more popular and hyped than IBM, Intel, Motorola and HP RISC. ARM came about from Berkley RISC.

https://en.wikipedia.org/wiki/Arm_architecture_family#History Quote:

Two key events led Acorn down the path to ARM. One was the publication of a series of reports from the University of California, Berkeley, which suggested that a simple chip design could nevertheless have extremely high performance, much higher than the latest 32-bit designs on the market. The second was a visit by Steve Furber and Sophie Wilson to the Western Design Center, a company run by Bill Mensch and his sister Kathryn, which had become the logical successor to the MOS team and was offering new versions like the WDC 65C02. The Acorn team saw high school students producing chip layouts on Apple II machines, which suggested that anyone could do it. In contrast, a visit to another design firm working on modern 32-bit CPU revealed a team with over a dozen members who were already on revision H of their design and yet it still contained bugs. This cemented their late 1983 decision to begin their own CPU design, the Acorn RISC Machine.

Berkeley RISC led by David Patterson resulted in SPARC, inspired ARM and resulted in RISC-V.
Stanford RISC led by John Hennessy resulted in MIPS.

The "Computer Organization and Design" books by David Patterson and John Hennessy make RISC-V sound like a MIPS replacement. Earlier versions of the books were sometimes referred to as "P and H" with Patterson listed first while the RISC-V edition is sometimes referred to as "H and P" with Hennessy listed first. David Patterson was the big RISC promoter and author but it is clear they are collaborating to make RISC-V look like a replacement for both Berkeley and Stanford RISC. Despite RISC-I, RISC-II, etc. being predecessors of SPARC, SPARC is rarely mentioned but without register windows and a register indirect indexed addressing mode (base reg+index reg), RISC-V resembles MIPS more. DEC, HP, Intel, Motorola and IBM RISC failed before the better hyped SPARC and MIPS. ARM is the only long term survivor with RISC and they are only one generation behind the Berkeley RISC-V example of a Redone Instruction Set Computer (RISC).

ARM-I: original ARM/A32
ARM-II: Thumb
ARM-III: Thumb-2
ARM-IV: ARM64/AArch64

ARM has become less RISCy and more CISCy with every generation to improve performance and code density. RISC-V remains RISCy giving up performance and code density thus reintroducing a simple academia project that can't compete. A simple ISA has no chance at being competitive in performance so they made a mess of the ISA with embedded extensions trying to catch Thumb-2 in code density for the embedded market. How long before RISC-VI?

Last edited by matthey on 19-Jun-2026 at 04:42 AM.

I mentioned the ALU in my last post and feel like it deserves more explaining as related to performance, the RISC vs CISC debate and the history of computers. ALU stands for Arithmetic Logic Unit and they are the flexible workers of the computer which can be thought of as a small factory. The basic ALU has 2 number inputs and 1 number result output among various control and status bits. ALUs perform most of the arithmetic and logic operations of basic instructions. ALUs take resources but are where most of CPU performance comes from. Early CPUs had fewer and narrower ALUs due to the limited resources available on a silicon die back then. The Z80 CPU used by the Neo Geo only has a 4-bit ALU which needs to be used twice to perform an 8-bit operation. Most other 8-bit CPUs had an 8-bit ALU which provided better performance. Chip fab processes improved and increased resources allowed for more performance including more ALUs but new techniques needed to be developed to keep them busy. The assembly line like instruction pipeline was developed but early accumulator architecture CPUs had few registers and using memory was slow. More registers were needed for parallel operations and making them similar general purpose (GP) registers simplified use. The general purpose register architecture was born. Many early general purpose architectures could operate on either GP registers or memory which resulted in CISC CPUs. It was discovered that there was a small resource savings to separate GP register and memory load/store operations resulting in load/store architectures which were often called RISC CPUs after a paper by David Patterson called the "Case for the Reduced Instruction Set Computer". The paper promoted simplification of load/store architectures allowing them to be clocked up and using saved resources for instruction pipelining and caches which were good uses of very limited resources then. Simplification of instructions resulted in an increase of weak instructions with large code and clocking up RISC CPUs was not as successful as expected due to increased power and heat and the increased size of RISC code coming from memory creating a bottleneck. Academia research in the early 1980s from David Patterson and John Hennessy led to a proliferation of RISC ISAs and CPUs in the mid 1980s mostly following the principles set out by David Patterson in his paper.

CISC ISAs and CPUs had no guidelines to increase performance or minimally increase performance as David Patterson suggested of many CISC architectures. There were certainly mistakes and lessons to be learned from many early CISC architectures. Some early CISC architectures were a transition from 8-bit accumulator architectures like x86 which was barely a GP register architecture while others came from large minicomputers like the PDP-11 and VAX. The main CPU in the Neo Geo is a 16-bit 68000 introduced in 1979 as a new CISC architecture. The 68000 was most influenced by the 16-bit PDP-11 but it had a 32-bit ISA with 32-bit registers, 32-bit datatypes and 32-bit addresses/ pointers even though the 16-bit data bus defines it as a 16-bit CPU. Supporting 32-bit pointers was resource heavy and slowed performance but 68k developers realized and gambled that it was worth it to have a large flat address space that could address 4 GiB instead of 64 kiB. Their gamble paid off as the 68000 MPU created the workstation and 32-bit embedded markets while also being influential in the desktop and console markets. The 68000 used three 16-bit ALUs.

https://en.wikipedia.org/wiki/Motorola_68000 Quote:

The design implements a 32-bit instruction set, with 32-bit registers and a 16-bit internal data bus. The address bus is 24 bits wide and does not use memory segmentation, which made it easier to program for. Internally, it uses a 16-bit data arithmetic logic unit (ALU) and two 16-bit arithmetic units used mostly for addresses, and has a 16-bit external data bus. For this reason, Motorola termed it a 16/32-bit processor.

The 68000 used a fast to develop microcode design. Microcode is discouraged by RISC philosophy as it uses more resources but the 68000 was in some ways a fast to prototype experiment that ended up better than expected. It could have been more optimized using 32-bit internal data paths and a 32-bit ALU for addresses which likely would have improved performance. The 68000 is not pipelined but splits the register file between data and address GP registers with an attempt to allow more parallelism between data and address operations using the separate data and address ALUs. Performance was good for a non pipelined design but the design was not retained as later designs used more traditional pipelined designs and unified the register file. The 68000 was still out performing x86 in 1985 as the 8086, 80186 and 80286 could not match the 68000 performance (see "Benchmarking The 68000 and 80X86" in Micro Cornucopia, Number 24, June-July 1985). Performance was good enough that the 1985 Amiga, 1988 Sega Genesis/Mega Drive and 1990 Neo Geo still used the 68000 even though the higher performance 32-bit 68020 with a shallow pipeline, small instruction cache and 32-bit ALUs was already available. The 68020 32-bit ALUs had other upgrades too. The 68000 ALUs may have supported 3 inputs instead of 2 or microcode may have been used to iterate over the ALUs to provide the register indirect with index addressing mode (d8,An,Xn.SIZE) which was already more powerful than David Patterson's Berkeley RISC successor SPARC version of the addressing mode before removal for RISC-V. The 68000 did not have enough resources to support a barrel shifter in the ALUs so the 68000 required a cycle per bit of shift like most 8-bit CPUs at that time. The 68020 received a 32-bit barrel shifter improving shift performance and the 68020 ISA added scaling to the register indirect with index addressing mode (d8,An,Xn.SIZE*SCALE). This was possible with a load/store architecture too and HP PA-RISC research suggested it was very good but most listened to David Patterson that RISC should be simple with simple addressing modes, except for ARM.

https://www.researchgate.net/publication/3556351_Pathlengths_of_SPEC_benchmarks_for_PA-RISC_MIPS_and_SPARC Quote:

MIPS executed 38% more integer computation instructions than PA-RISC, while SPARC executed 79% more integer computation instructions, based on the total geometric means for this class of instructions. Looking at the detailed instruction counts, of the architectural features which could cause the reduction in integer computation instructions, scaled indexed loads was the most heavily used, followed by address updates, extract and deposit instructions, compute and branch, and shift and add instructions. However, PA-RISC's small static displacements for floating-point load and store instructions also increased the number of LDO instructions which were counted as integer computation instructions. The high percentage of PA-RISC load and store instructions which use addressing modes beyond the vanilla "base plus displacement" addressing mode in MIPS indicates the usefulness of indexed and update addressing modes.

It is possible to upgrade ALUs to support multiply operations and more than 32-bits. Simpler RISC ISAs were likely motivated to upgrade to 64-bit because the overhead of multi-precision arithmetic is higher with them but this makes further ALU upgrades more expensive, even though ARM64/AArch64 went all in with powerful 64-bit ALUs with barrel shifters and indexed addressing modes with scaling while RISC-V went back to simple MIPS with RISC performance handicaps (read the HP paper above to understand how deficient simple MIPS and SPARC architectures were). The 68k has upgraded ALUs to more powerful versions, designs like the 68060 have added more ALUs that operate in parallel, the 68k ISA was upgraded to better take advantage of the ALUs and caches made it possible to pipeline cached memory accesses. The 68k is more like ARM64 but the 68k chose a VLE and has load/store multiple register instructions. As someone commented in a RISC-V thread I linked not long ago, RVC (RISC-V compressed) is supported by $.10 MCUs. ARM Thumb-2 and now RISC-V extensions support load/store of multiple register instructions. There is a significant resource cost to performance but the MIPS like level of simple RISC David Patterson returned to with RISC-V is a mistake as scaling up with performance is more important than scaling down to 6502 like transistors/area, especially without good code density also lost in the pursuit of a simple ISA. RISC-V also suffers from lack of standardization and ease of use which are important too.

Instruction pipelining is a wonderful performance advancement but the gains are reduced by stalls or pipeline bubbles which are like affected ALUs taking a break due to them not receiving the resources they need. Deeper pipelines increase performance but also increase fowarding/bypassing logic needed to avoid stalls and some stalls can be increased like load-to-use and branch stalls.

https://blog.jyotiprakash.org/delving-deeper-into-the-mips-pipeline Quote:

Increased Forwarding Complexity The deeper pipeline necessitates more levels of forwarding for ALU operations. In the traditional five-stage MIPS pipeline, forwarding between two register-register ALU instructions could occur from the ALU/MEM or MEM/WB registers. In the R4000 pipeline, four potential sources for ALU bypassing exist: EX/DF, DF/DS, DS/TC, and TC/WB. This increased complexity ensures that data dependencies are correctly managed, maintaining the efficiency and accuracy of the pipeline. ... The following figures provide a breakdown of the pipeline Cycles Per Instruction (CPI) for the R4000 across the 10 SPEC92 benchmarks, presented both graphically and in tabular form. These data highlight the penalties associated with the deeper pipelining in the R4000. The pipeline has significantly longer branch delays compared to the classic five-stage pipeline, which substantially increases the cycles spent on branches, especially for integer programs with higher branch frequencies.

MIPS pulled a marketing deception with the low end 5-stage R4200 which should have had an R3xxx designation with its shallower R3000 like pipeline. The higher end 8-stage R4000 lacked efficiency as the increased load-to-use and branch stalls were handled as poorly as the R3000. The 68060 design avoids load-to-use stalls and branch prediction with dynamic prediction is a much better way to deal with branches than branch delay slots common for RISC ISAs which did not scale well with deeper pipelines. A scalar CPU core with single cycle throughput instructions and no stalls would have a theoretical 1 cycles per instruction (CPI) and a superscalar 2-way CPU core 0.5 CPI (a lower CPI is better). The R4000 has a 1.54 CPI for SPECint92 from the source above. The H & P book I also sourced earlier in this thread has the CPI of the most popular core in the world all time, the 8-stage in-order superscalar Cortex-A53.

Computer Organization and Design (RISC-V Edition)
https://www.cs.sfu.ca/~ashriram/Courses/CS295/assets/books/HandP_RISCV.pdf Quote:

Figure 4.73 shows the CPI of the Cortex-A53 using the SPEC2006 benchmarks. While the ideal CPI is 0.5, the best case achieved is 1.0, the median case is 1.3, and the worst case is 8.6. For the median case, 60% of the stalls are due to the pipelining hazards and 40% are stalls due to the memory hierarchy. Pipeline stalls are caused by branch mispredictions, structural hazards, and data dependencies between pairs of instructions. Given the static pipeline of the Cortex-A53, it is up to the compiler to try to avoid structural hazards and data dependences.

I calculated the geometric mean of the 12 SPECint2006 benchmarks for the Cortex-A53 to be 1.31 CPI which is better than using the median CPI. The chief architect of the 68060, Joe Circello, gave the CPI of the 68060.

The Superscalar Hardware Architecture of the MC68060
https://old.hotchips.org/wp-content/uploads/hc_archives/hc06/3_Tue/HC6.S8/HC6.8.3.pdf Quote:

Measured Performance o 1.2 CPI measured of a range of desktop and embedded applications o 45%-55% of instructions issued as pairs/triplets (existing 680X0 code) o 50%-65% of instructions issued as pairs/triplets (targeted 68060 code)

The 3 input ALUs for address generation and the 2 input ALUs for general execution in each int pipe are shown on the 3rd page too. The CPI benchmarks and CPU cores compared vary but most of the instructions and data were in L1 caches for all and if anything, the earlier 68060 and R4000 with smaller L1 caches and no L2 cache had to access old slow memory more often.

CPU/core | CPI I pipeline
R4000 1.54 8-stage scalar
68060 1.2 8-stage in-order superscalar
Cortex-A53 1.31 8-stage in-order superscalar

The 68060 has the best CPI which makes me wonder how it would perform with similar caches to the Cortex-A53 which uses roughly 10x the transistors of the 68060. The 8-stage superscalar pipeline and multiple advanced ALU costs are insignificant compared to the transistors/area used by caches and the 68060 code density would allow a 68060 32 kiB L1 i-cache to perform like a R4000 128 kiB L1 i-cache and a Cortex-A53 64 kiB L1 i-cache according to RISC-V research. The cache transistor savings from code density more than pays for the powerful 68060 enhancements. Did David Patterson not read the RISC-V research and the HP PA-RISC research or had he already drank too much of his own simple RISC is better Kool-Aid?

Last edited by matthey on 20-Jun-2026 at 01:04 AM.
Last edited by matthey on 20-Jun-2026 at 12:57 AM.

@matthey

Quote:

matthey wrote: cdimauro Quote: Right. IF you've the a good volume then an ASIC is much cheaper than any emulation-based system, for obvious reasons. Specifically, you need to embedded several cores for retro purposes. To support several 68k systems then you need at least: - a 68000 (better if it can support a 68010, and you can select at boot time if you want a 68000 or a 68010) with perfect cycle timings / behavior; - a 68020 (cycle timings are important, but they can be less precise here). Better if it can support a 68030 as well (selectable at boot time, of course), since they are very similar; - a super fast 68040/68060 (selectable at boot time). I propose to add another not-cycle-exact 68000 or 68020 (the cheapest to implement) as a "system processor", only used for controlling the entire platform and to implement the GUI / user interface with OSD graphics etc.. Since retro systems have other processors from different families, it'd be good to provide some cores of them (6502/6510/8502, 8085, 8086, z80, z180, ...) as well. I do not know about an extra 68020/68030 core. I suppose it depends on how well a modernized 68k core could be downgraded for compatibility.

Since transistors are cheap on ASICs and a 68020/30 core doesn't take so much space, I'd opt for adding one of such core and leave the high performance 68k core without constraints/patches to be applied to slow it down.
Quote:

The problem with 6502 family cores is that there were many variations and it would be difficult to have one super configurable core. A 65C816 would come close to gaining super valuable SNES and Apple IIGS compatibility but the SNES version is highly customized. A Z80 core is interesting as it was more standard and a common companion in 68k hardware like the NeoGeo, Sega Genesis/Mega Drive, Capcom CPS-1 & CPS-2 Arcade boards, Torch Unicorn and Cifer 68k Systems. Ok, maybe the last 2 are not so important but Arcade games could be a draw as MiSTer supports them. ASIC CPUs with FPGA chipsets would give a cost reduced MiSTer. Small 8-bit CPUs are cheap enough to provide in a FPGA depending on if and how much the FPGA resources are reduced. MiSTer can easily handle 8-bit CPUs with chipsets.

Fair enough, but a more capable FPGA might be required then.
Quote:

The problem is with high performance CPU cores where a 486 CPU alone barely fits in the MiSTer FPGA.

A 486 is quite standard and should be parte of the ASIC (since it requires around 1 million transistors).
Quote:

cdimauro Quote: So, all of the above is certainly doable, but it requires some experts to work on it and design this retro platform in a manner that it's usable to emulate most of the systems. Which means that the ASIC should also provide some "basic blocks" like embedded memories which are available and usable depending on the system to emulate. Another important thing is regulating the priorities on accessing the memory by the various components. As we know, retro simulation requires very precise timings, and the above cores need to be carefully controlled on when and how they can access the memory. I've no idea on how to do it, because there are plenty of systems which exists, and they have their own quirks (Amiga has its own due to the chip mem vs chipset vs fast mem). Anyway, ON PAPER it's possible to design a single, very cheap, ASIC which can support multiple systems, and that provides much better value compared to any existing solutions. But IMO it's very difficult to design and implement it. Experienced MiSTer developers like those working on the NeoGeo AES+ could provide universal retro system knowledge. There are many possible 68k Amiga hardware and FPGA experts. Most of the 68k Amiga developers are still alive. Good CPU architects are more difficult to come by but the original 68060 chief architect, Joe Circello, has connections to the Amiga as we found out in the recent Amiga Bill video. Architect Mitch Alsup likes the 68k better than RISC-V too. Obtaining the 68060 sources would be key as it would save a huge amount of time. Many other retro resources needed could likely be used from the MiSTer and other FPGA projects so they are less of a problem.

Mitch is 100% on his My 66000. Joe might be interested or, at least, could help on getting the 68k sources.

Anyway, I still think that there's a lot of work to do even taking the MiSTer sources and/or helpers for such "retro-platform", because mixing the ASIC static cores with the dynamic cores & chipset to be implemented in the FPGA part isn't trivial, considering the dependencies and, especially, the timings.
Quote:

cdimauro Quote: 68060's pipelining and clocking-up issues might be related to the intrinsic nature of its architecture. Joe called the 68k a clean architecture which he could not say about x86.

8086 is a clean architecture too, if you look at its design (opcodes structure) and when it was conceived. What happened after that, well, I prefer to don't comment.

However, you know much better than me the opcodes structure of all 68k family members: there are some quicks and patches already on the 68000, and many more on the 68020.

Why the 68060 needed a big (and slow, IMO) 16-bit LUT to decode its (main) opcode? If the architecture was clean then you would have needed only some logic circuits to decode & break down the main opcode to the simpler, internal macro-ops.
The reality is the big LUT and not the small logic circuits.
And the reality is that the 68060 was difficult to scale-up with the frequency, even on better/newer processes and with overclocking.

As I've said before, this can be verified implementing a similar 68k, x86, PowerPC, MIPS, whatever cores on the same FPGA with similar features (2-ways in order, same L1 caches, same TLBs, etc.) and checking how high they can with the frequency. It'd be a fair comparison, since the only change is the intrinsic core, leaving everything else the same.

@minator since Matt has already replied on most part, I only answer on a few things.

Quote:

minator wrote: @cdimauro Quote: And they decided to kill it, jumping on the RISC wagon due to the academic propaganda. RISC wasn't an academic thing, it came from an IBM project to build a phone switch but turned into a very fast general purpose processor. All that became known as RISC was in the IBM 801.

Sure, but I was referring to what happened after that, with the academic research and the other processors which were called "RISCs".
Quote:

It also wasn't propaganda. In the early to mid 80s Motorola dominated the workstation space. Then the Sun SPARC appeared and it destroyed the 68030 on performance. That's what killed the high end 68K.

Sorry, but what do you expected? The first SPARCstation arrived only on 1989, when Intel has already commercialized the 80486 and Motorola announced the upcoming 68040. New chips arrived after so many years, and it's obvious that the old ones were put in the trash...
Quote:

Quote: Second, there's really no RISC. In fact, they are all CISCs. I'd say the opposite, most if not all true CISCs went out of production decades ago.

There's no "true" CISC: there are only CISCs. And, to be more precise, there are ONLY CISCs since around 40 years. See below.
Quote:

Quote: The reason is very simple: they give up at the RISC's foundations / principles in order to delivery real-world products. What do you think the founding principles were?

I don't think: I'm not the one which defined them. Let me report the four foundations of RISC processors:
- only a reduced set = A FEW instructions should be present;
- instructions should be SIMPLE, mostly executed in one cycle.
- opcodes should only have a fixed length (no variable-length);
- memory should only be accessed using load and store instructions (no mem-op).
ALL those requirements should be present to define a chip as RISC. Otherwise, it's a CISC.

That's directly coming from the RISC propaganda (academic PAPERS and researches. For which Patterson got its Turing award a few years ago) which I was talking about.

Now, please pick all processors which were sold as "RISC", check the above four pillars, and tell me if they ALL apply. I'm quite sure that, besides some early products, none of them can be classified like that -> they are CISCs.
Quote:

Quote: A modern CISC architecture designed from scratch as well can easily draw circles around any so called RISC architecture. I've at least two proofs of that (my NEx64T architecture, and especially new one), but I can easily provide more (a 68k-inspired one, for example) A proof would be a functioning chip, or at least a simulation of one.

A simulation isn't enough, unless an entire microarchitecture is simulated.

Unfortunately, it requires expertise (hardware design. Which I haven't) and at least a compiler (which I planning to work on. But it takes some, since creating a complete backend for such complex architecture isn't trivial).

@matthey

Quote:

matthey wrote: minator Quote: OTOH the 060 was cheap compared to the Pentium, but by the time the 060 shipped the Pentium was at 100MHz, and outperformed it. Even it had scaled with the Pentium, it would still be well behind the workstation chips and the Pentium Pro would have destroyed it the following year. The 68060 has 40% better integer performance than the P5 Pentium at the same frequency according to Bytemark benchmark and should have been able to clock significantly faster due to the longer pipeline. This is not that far from the P6 Pentium int performance, the planned 68060+ claimed 20%-30% performance improvement which likely included doubling the cache sizes and the 68060 would have been much cheaper as the 68060 uses fewer than half the transistors of the Pentium Pro. The Pentium Pro was a very expensive chip with 2 dies in the same package. One die included the fat OoO CPU that could still only fit 8 kiB-i + 8kiB-d and a 2nd die with an L2 cache. Intel did not retire their in-order P5 Pentium but added a pipeline stage to 6-stage, doubled the caches and added MMX (SIMD unit) before the Pentium Pro because there was more free room on an affordable die. The lower priced P5 Pentium remained available for years. The 68060 had more available die area than the P5 Pentium and with a deeper 8-stage pipeline to out clock it.

Also because the Pentium offers many more features compared to the 68060 (whereas Motorola cut several things), and this required transistors.
Quote:

The Pentium Pro did have a deep superpipelined 14-stage pipeline which would have allowed it to out clock the 68060 but it was not refined enough to gain fully from it and similar designs returned to a more practical 10-12 stage pipeline later. The P5 Pentium suffers from lack of x86 orthogonality and x86 baggage so Intel moved to all OoO cores for awhile but returned with the in-order Bonnell (Atom) to try to be "competitive in the personal mobile device" but gave up, likely due to lower margins for the market.

No, it was because the mobile market was monopolized by ARM and JIT translating ARM binaries to x64 wasn't efficient (required much more power -> less battery available). So, the platform wasn't overall competitive with the ones which were natively running ARM core.

The Intel platform could have been competitive only when all Android applications (especially games) would have been natively available. Which was far away the case, unfortunately.
Quote:

ARM has become less RISCy and more CISCy with every generation to improve performance and code density.

ARM was CISC since day one (it was also fully microcoded).

AArch64 is more similar to MIPS/Alpha, but ARM was smart enough to borrow some complex addressing modes from the original ARM32 architecture, and add many more complex instructions to better address real-world use cases.
Quote:

RISC-V remains RISCy

Only the base ISA, which is practically useless in the real world: only good for the academia...
Quote:

giving up performance and code density thus reintroducing a simple academia project that can't compete. A simple ISA has no chance at being competitive in performance so they made a mess of the ISA with embedded extensions trying to catch Thumb-2 in code density for the embedded market. How long before RISC-VI?

It's difficult to change the ISA when now have a billions market.

Last edited by cdimauro on 20-Jun-2026 at 08:20 AM.

cdimauro Quote:

Since transistors are cheap on ASICs and a 68020/30 core doesn't take so much space, I'd opt for adding one of such core and leave the high performance 68k core without constraints/patches to be applied to slow it down.

The area of a 68020 core is not as much of a concern as what shape these cores are in. The development of these cores involved more manual tools. They are likely not full static designs, may not be synthesizable and may not even have HDL sources. Motorola/Freescale updated 68EC000 and 68040V cores to be full static designs so they likely have HDL sources and are sythesizable.

CPU | transistors | static design | synthesizable
68000 68,0000 68EC000 likely
68020 190,000 ? ?
68030 273,000 ? ?
68040 1,170,000 68040V likely
68060 2,530,000 yes yes

CPU32 cores were usually used instead of 68020 or 68030 cores in embedded designs. Maybe the 68020 and 68030 cores were updated before converting to a CPU32 core. They did start as CMOS designs which was better than the original NMOS 68000 but there are more unknowns about them than other 68k cores. It sounds like the 68060 sources and tools are in good shape if they can be recovered from the database or backups, but the 68020 and 68030 sources and tools are the most concerning of popular 68k cores.

cdimauro Quote:

Fair enough, but a more capable FPGA might be required then.

There would be advantages to retaining the same size and brand of FPGA as MiSTer hardware. There is still room for cost savings over MiSTer, better and better integrated retro features and the FPGA could be optional for an ASIC 68k SoC.

cdimauro Quote:

A 486 is quite standard and should be parte of the ASIC (since it requires around 1 million transistors).

I was using the existing MiSTer 486 core as an example of CPU sizes relative to the limits of the FPGA size rather than suggesting a 486 core should be included. A 68040 core would also be difficult to fit with enough room for chipset simulation. A 486SX or 68040V without FPU may fit better but many retro customers want performance, features and compatibility and MiSTer can only deliver on 2 out of 3. With an ASIC 68k SoC, DOSBox could be used with better than 486 performance. While adding x86, MIPS, SuperH, PPC etc. cores may be popular for retro hardware, it would make the SoC more specialized for retro use. Many CPU cores from about 2000 on were highly customized so one MIPS CPU core for the PS1, PS2 and N64 or one PPC core for the PS3, Xbox 360, Wii and Wii U would be difficult as well as GPU differences. An early x86 core may be easier and if the MiSTer 486 core is in good shape and free to use, it is tempting to include but probably not worth it as there are plenty of old PCs and DOSBox on modern x86-64 hardware can emulate x86 efficiently.

cdimauro Quote:

Why the 68060 needed a big (and slow, IMO) 16-bit LUT to decode its (main) opcode? If the architecture was clean then you would have needed only some logic circuits to decode & break down the main opcode to the simpler, internal macro-ops. The reality is the big LUT and not the small logic circuits. And the reality is that the 68060 was difficult to scale-up with the frequency, even on better/newer processes and with overclocking.

Maybe a 16-bit LUT is fast and cheap.

How many transistors would a 16-bit LUT use with CMOS?
Google AI Overview Quote:

A 16-bit Look-Up Table (LUT)—which is a 4-input, 1-output logic block—uses approximately 128 to 150 transistors in standard static CMOS. The Transistor Breakdown o Memory Elements (96 - 100 transistors): The truth table requires 16 bits of storage. Standard SRAM cells use 6 transistors each:16 bits × 6 transistors = 96 transistors. (Some configurations also use a pair of inverters per bit for local buffering, which can push this number up slightly). o Multiplexer Tree (32 - 48 transistors): A 16-to-1 multiplexer routes the correct memory bit to the output. In CMOS, this is typically constructed using transmission gates. A standard transmission-gate MUX uses about 2 to 3 transistors per equivalent 2-to-1 MUX.

Some things that are expensive in traditional programming languages are cheap on silicon. HDL code may look like existing languages and some of the logic still applies but some things are much different.

cdimauro Quote:

As I've said before, this can be verified implementing a similar 68k, x86, PowerPC, MIPS, whatever cores on the same FPGA with similar features (2-ways in order, same L1 caches, same TLBs, etc.) and checking how high they can with the frequency. It'd be a fair comparison, since the only change is the intrinsic core, leaving everything else the same.

There would still be different levels of optimization between CPU cores with different architectures. One of the remaining advantages of x86(-64) cores is that they were highly optimized with many incremental improvements over time which were reused in newer Intel and AMD designs. Sometimes acquired CPU designs and architect knowledge are incorporated too including for the 68k with the 68060 design and team coming from outside Motorola/Freescale. The CISC 68k often gets classified with the CISC x86 but they are more different than most RISC cores and require much different solutions to problems. It would be valuable to continue 68k development using the experience and design worked on by two 68k development teams.

cdimauro Quote:

No, it was because the mobile market was monopolized by ARM and JIT translating ARM binaries to x64 wasn't efficient (required much more power -> less battery available). So, the platform wasn't overall competitive with the ones which were natively running ARM core. The Intel platform could have been competitive only when all Android applications (especially games) would have been natively available. Which was far away the case, unfortunately.

ARM accepted lower margins in mobile and embedded markets than Intel in workstation/server and desktop markets. Businesses generally try to decrease less profitable business while increasing more profitable business. It is also expensive to enter new markets and take market share which usually requires undercutting competitor prices and/or spending more money on marketing. While I believe Intel Atom cores were competitive in the mobile market, the cores were larger than the ARM competition at the time which increased the price.

Android executes Dalvik bytecode not native ARM code. There should be a minimal disadvantage to switching from ARM to another architecture if the sources are available for the virtual machine.

cdimauro Quote:

ARM was CISC since day one (it was also fully microcoded). AArch64 is more similar to MIPS/Alpha, but ARM was smart enough to borrow some complex addressing modes from the original ARM32 architecture, and add many more complex instructions to better address real-world use cases.

I would not call ARM1 "fully microcoded" but more like partially or minimally microcoded.

Reverse engineering the ARM1 processor's microinstructions
https://www.righto.com/2016/02/reverse-engineering-arm1-processors.html Quote:

So is the ARM1 microcoded or not? The instruction decoder is clearly made up of microinstructions executed sequentially or with branching. It makes sense to look at this as microcode. But on the other hand, the microcode is fairly simple and forms a small part of the total control circuitry. A large amount of hardcoded logic interprets the microinstruction outputs to generate the control signals. My conclusion is the ARM1 should be called "partially microcoded" or maybe "hybrid microcode / hardwired control".

As I have stated before, I believe David Patterson provided RISC guide lines rather than immutable laws. If there was an immutable law, a "reduced instruction set" would be a good candidate as it is in the name but the 68k has a smaller instruction set than every load/store architecture I can think of today. RISC-V tries to get away with remaining RISC by making the base instruction set reduced but then the majority of RISC-V cores using the many extensions and instructions would not be RISC. ARM1 only had 45 instructions compared to the 56 instructions of the 68000. ARM1 was a reduced instruction set load/store GP register architecture. Besides some microcoding, more and more powerful addressing modes were used including index with shifted scale, which could be used on many non load/store instructions as well. The architects made the not so simple decision to add a barrel shifter to the ALU so decided to make best use of it. The CISC like addressing modes are useful and a good decision while allowing shift in many instructions although some instructions no longer had single cycle throughput. ARM would add multi-cycle MUL instructions in ARM2 and if having multi-cycle throughput instructions was no longer RISC then RISC died in the 1980s. HP was smart to put RISC in the name so there would be no question they remained RISC with PA-RISC despite how may instructions they added and despite also supporting scaled index registers and base register update, another ARM addressing mode feature. The classic RISC pipeline used 2 reg read and 1 reg write ports to the register file which an update breaks while being quite useful again. The 68k also uses this for post increment and pre decrement addressing modes and could easily add it generally with a free bit in the full extension word format as the HP research found it useful. The other weird thing about ARM1 was the conditional execution of instructions using predication which was useful but not worth the encoding space and limits designs to requiring support for predication. Despite some less than simple design decisions, ARM2 used only ~30,000 transistors. They saved transistors using simplifications like only having 14 GP registers with code density similar to 32 GP register RISC ISAs and combining the PC with flags in a register for faster interrupts even though this limited future addressing space. Some simplifications are just plain mistakes with or without RISC. Calling ARM1 CISC does not seem fitting but maybe a hybrid leaning more toward RISC is appropriate.

cdimauro Quote:

It's difficult to change the ISA when now have a billions market.

Changing the ISA is not a deal breaker for the embedded market. With the RISC-V VisionFive 2 SBC, you compile your own software and recompile your kernel as needed after installing new drivers. Actually, this is sometimes required with RPi SBCs and A1222 software too.

Raspberry Pi 500+: NOW we're gaming! (Jeff wears an "It has been 0 days since I recompiled the Linux kernel" t-shirt and has to recompile his RPi 500+ kernel in the video)
https://www.youtube.com/watch?v=Dv3RRAx7G6E

In contrast, there are plenty of 68k hardware users who never compiled a program in their life, maybe the majority. Cheap small footprint hardware used to be more standard and easier to use. Is RISC-V or ARM good enough or was Jay Miner right to insist on having the 68k and remains the future we were promised?

https://www.reddit.com/r/RISCV/comments/1loskj7/picture_this_a_new_official_commodore_computer/ Quote:

But they also want to make new, modern, products. The focus on "digital minimalism" and creating products that are "not just retro but also the future", aims to recapture this optimistic spirit while also innovating with new hardware and software. Historically, Commodore used the 6502 and 68000 CPUs. Had they survived a bit longer they might well have gone into either ARM (yay!) or IBM compatability (boo) ... but making a new start today, wouldn't RISC-V make more sense for them? It could also be a huge huge thing for RISC-V, if it happened. They apparently do have one or more new products in development, but we don't have any clues what they are.

The post is from Bruce Holt who is one of the more knowledgeable RISC-V supporters. Is simple non-standard RISC-V and bloated unfriendly Linux the future purgatory we were promised?

Last edited by matthey on 22-Jun-2026 at 12:05 AM.

@matthey

What's the problem with compiling software?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

kolla Quote:

What's the problem with compiling software?

Just in time compilation...

1. wastes time
2. wastes energy
3. reduces performance
4. requires more memory
5. is more error prone
6. requires sources or an intermediate language that is less efficient than native code
7. is more likely to use quick compiles that are less optimized

There are advantages to having the sources available for customization and better optimization for a particular target but it is possible to have both native executables and sources provided. After most early Amiga software not being released with sources, I expect the majority of Amiga software released on Aminet now includes both native executables and sources. This is both convenient and an advantage for a more standardized system like the 68k Amiga. Despite Amiga division into flavors making providing executables more difficult, executables still are often distributed. Ironically, providing Amiga executables remains standard even though the standard 68k Amiga that made this possible was abandoned or at least delegated to a universal Amiga base standard.

@matthey

You were talking about compiling software and Linux kernels, why do you bring in JIT?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

thread which was maliciously spammed by the usual troll and was mostly off topic anyway.

Oh my.
Possibly the singularly most palpably ironic thing Ive ever seen.

Do you have *any* sense of self awareness? Are you even aware of the concept?


Funny, funny stuff.

kolla Quote:

You were talking about compiling software and Linux kernels, why do you bring in JIT?

Are you talking about ahead of time compilation but not just in time compilation? I can not use 3 English words together without people assuming some specific meaning?

It was a joke but the disadvantages of any type of compiling ahead of time applies. Some of the disadvantages can be traded from switching from JIT to AOT compilation, as Android switched, or between user compilation or script compilation but there are still major disadvantages. This is especially a disadvantage for small footprint systems as compiling software after downloading can use more memory than the system has. A good example is most large 68k Amiga projects which use more memory compiling than most 68k Amigas have. Android bad decisions resulted in phones that required 8 GiB of memory when the 68k Amiga is comfortable with 8 MiB of memory. Android and Linux have virtual memory but it is not practical to compile with heavy page thrashing to some drive with such reduced performance.

How much memory is used to recompile a Linux kernel?
Google AI Overview Quote:

Compiling a Linux kernel requires about 2GB of RAM per parallel compilation thread. Therefore, for a standard system, a build needs between 4GB to 16GB of total RAM. If your system lacks sufficient memory, the build process will slow down significantly or fail entirely as it relies on disk swap. Memory utilization scales with the number of parallel jobs you run (e.g., using the -j flag in make). To determine your ideal RAM, consider these specific build scenarios: o Minimal Requirements: You can successfully compile with just 2GB to 4GB of RAM if you limit your build to a single thread (make -j1). However, this will take several hours. o Standard System Build: Compiling a standard desktop or server kernel (such as an Ubuntu or Fedora default configuration) uses roughly 8GB of RAM. o Heavy Multithreading: Modern processors utilize high core counts. If you use -j16 or higher to compile a heavily bloated kernel, the build process can easily use 16GB to 32GB of RAM or more. o Real-time & Custom Kernels: Real-time kernels or those heavily compiled with extensive hardware drivers require greater space and memory, occasionally exceeding standard desktop limits during heavy parallel run

Google AI actually used "heavily bloated kernel" in regard to Linux kernels. I quoted those 3 English words for you to help with understanding. Do RPi 512 MiB hardware owners recompile their own kernel? Half of RPi hardware is used for the embedded market so more than half of small memory footprint RPi hardware is used for that purpose. Small footprint RPi hardware likely receives software updates of already compiled software. The greater CPU performance and memory footprint needed by Linux is likely why x86-64 hardware became so popular for Linux users. RPi hardware can be used like cheaper desktop hardware but much more memory is highly recommended or much customer time and energy will be wasted. I say energy too for low power ARM hardware as heavy memory and drive access uses higher power for extended periods of time instead of sleeping most of the time. The memory requirements of Linux result in requiring a 64-bit OS which then uses at least 20% more memory. The Ouya ARM based microconsole with Android failed with 1 GiB of memory back in 2015 after raising $8.5 million USD via Kickstarter. Ouya used a 32-bit OS and Thumb-2 for a smaller memory footprint but it likely required native executables to have acceptable performance and enough memory.

What were the biggest complaints of the Ouya microconsole?
Google AI Overview Quote:

The Ouya microconsole’s biggest complaints centered on its notoriously flawed controller, an underwhelming software library, and sluggish hardware that struggled to deliver a premium living-room gaming experience. ... Hardware Limitations o Underwhelming Power: The mobile hardware (an Nvidia Tegra 3 processor) was outdated shortly after release. o Performance Drops: Players regularly experienced poor frame rates and long load times, and the system's cooling fan was notoriously loud

This was with an OoO 4xCortex-A9@1.7 GHz CPU with cores roughly similar performance to entry level in-order Cortex-A53 cores. A 68k Amiga would fly with 68060+@1.7GHz cores and 1 GiB of memory would feel spacious. A 68k microconsole would have a large library of retro games which use a much smaller memory footprint than Android smartphone games. Too bad the Amiga and now Commodore are about sticking labels on heavily bloated foreign hardware when the 68k Amiga on fresh silicon could make it possible again.

Last edited by matthey on 23-Jun-2026 at 01:20 AM.

PA🛞🛞ING

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK