@Lou

Quote:

So yes, once again - I re-iterate that Amiga on 65816 would have naturally led to more success and eventually ARM instead of 68K and PPC death.

I doubt that.
In fact, the 65816 suffers from the same "diseases" as the x86, not to mention that 16-bit was predicatably a dead end in the PC niche already at that time.
One problem is the architecture, which is mostly geared towards single-address instructions. This made sense with early 8-bit processors with severe technological constraints. Having an implicit address (the accu register) for many instructions shortened those instructions and thus increased fetch throughput. OTOH it required a lot auxiliary instructions just to move values /results around into other registers.
The address space segmentation is another significant disadvantage it shares with all other 16-bit processors and MCUs. I am still occasionally dealing with this issue on MCUs. Especially with larger application requiring more than 64k, the memory model issues become a real nightmare.

In that light, a 8086 (or 286) would have been an equivalent, if not better choice.

@Lou

Quote:

Lou wrote: So yes, once again - I re-iterate that Amiga on 65816 would have naturally led to more success and eventually ARM instead of 68K and PPC death.

1st you would need to establish a timeline where either HiTorro gets early access to the chip and sees it as superior to the 68k.
Or one where C= spend the resources to reengineer the A1000 and AOS from 68k to 65816 without even more delays.
Thats is a hard.

Next you have to remember that a big part of the A1000s (limited) early success was the combo of a multitasking OS in non segmented memory.

Now you'd have to find a way to establish a healthy market for accelerators based on an alien ARM chip, not readily available 020/030 which C= eventually followed up with the A2500 and A3000.

We are in nightmare mode.

More plausible:
The Amiga would have morphed into something like the C65 with AOS being an optional extra and no successor.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos
Quote:

Now you'd have to find a way to establish a healthy market for accelerators based on an alien ARM chip, not readily available 020/030 which C= eventually followed up with the A2500 and A3000.

If I remember correctly, the Acorn Archimedes was out around this time. With a quite good performance in comparison, but far beyond mass market prices. I don't think this ever was an option for C=.

I then followed the development of ARM with very limited interest for the next 20 years.
Until the rise of Cortex M, when I got deeper into microcontrollers, both as hobby and professionally.

@codis

Archimedes appeared in 87.

3rd party CPU cards for the A1000 existed before that. Which was no problem as they could just run 99% of all 68k code with no extra SW needed.
Which in turn helped developers to create SW utilizing that extra performance.

With a theoretical ARM upgrade you'd have a chicken&egg situation lacking the insufficient momentum the Phase5 PPC cards had a decade later.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

As mentioned in an earlier post, at that time all things Amiga were just hypothetical for me, because they were inaccessible. They became real and tangible after the wall fell in '89.
So I had (and have) only very cursory information about this issues, except for some arcane systems hardly anybody here knows or even heard of ...

When Commodore finally disappeared, different issues had taken precedence in my life, and my Amiga got shelved in a safe place. Only now I found the time and leasure to reactivate it, one way or another.
And I'm mostly here to learn, not to debate

Quote:

With a theoretical ARM upgrade you'd have a chicken&egg situation lacking the insufficient momentum the Phase5 PPC cards had a decade later.

Having followed the IT market in general and the developments around the Commodore, I instinctively knew that the Amiga - and Commodore - had no commercial future at that point. Even the PPC projects of IBM and other giants turned out to be nonstarters around that time.
Just saying ...

@Kronos

Quote:

Kronos wrote: @Lou Quote: Lou wrote: So yes, once again - I re-iterate that Amiga on 65816 would have naturally led to more success and eventually ARM instead of 68K and PPC death. 1st you would need to establish a timeline where either HiTorro gets early access to the chip and sees it as superior to the 68k. Or one where C= spend the resources to reengineer the A1000 and AOS from 68k to 65816 without even more delays. Thats is a hard. Next you have to remember that a big part of the A1000s (limited) early success was the combo of a multitasking OS in non segmented memory. Now you'd have to find a way to establish a healthy market for accelerators based on an alien ARM chip, not readily available 020/030 which C= eventually followed up with the A2500 and A3000. We are in nightmare mode. More plausible: The Amiga would have morphed into something like the C65 with AOS being an optional extra and no successor.

An Amiga is just a slower ST with custom chips. How well did 68k->PPC work out?

That's my point about the cpu...does the cpu make the system? No. 68k is not magical. There are pre-emptive multi-tasking OS(es) available for the 8/16bit cpus.

Commodore's engineers were pretty good at making custom 6502's. Better than Bill Mensch I'd argue. 68000 was an expensive boat anchor. The 65CE02 was amaZing but they gimped it by making it pin-compatible with a 6502 hence the need for an MMU for larger memory addressing. They gave it 2 more registers, a 16bit stack pointer, 5 16bit instructions to manipulate WORD(s) in memory, relocatable base-page addressing (via new B register vs MMU on C128) to speed up memory r/w even more and extended branch jumps to 16bit addresses.

Hombre was going to be HP PA-RISC. Yeah, the writing was on the wall for 68K. They weren't looking at PPC. So the AAA Amiga wasn't going to be Amiga-compatible. Was it even gonna be called an Amiga? Might as well have called it a C5000. C for Commodore.

If Commodore had gone the ARM-like route in making their own 32bit successor to the 65816, they could have actually been ARM. Remember, the ACORN's BBC Micro? They only developed ARM because Bill Mensch was lacking/lagging. Commodore could/should have been ARM.

3 people created the ARM cpu.

3.

I'm pretty sure Commodore had more than 3 engineers.

@Lou

See thats the problem, you start with a "good" result but show no plausible way to achieve it.


There is a good reason why Jay and co went with 68k, mainly because it was available when they started.

Without acquiring Amiga on the cheap C= would never have invested into such an high end system.

There is also a good reason why the SW crew in Amiga were so motivated to test out new designs on a non segmented CPU.

Without the OS being in a half baked state when C= acquired Amiga on the cheap they would have just slapped a BASIC onto it and called it a day.

Without 3rd party HW and SW showing the way C= would have never gotten of their ass and Amiga would have been just the basic A500 with Kick1.2 till the end.

So you need to explain how and why choosing a different chip would have made sense in 82-85 and how that would have lead to a better outcome.

C= for sure had plenty engineers but they were all under the order not use/create chips that couldn't be made in the aging MOS plant. Hence no "Ranger" and the delays on AA. Them doing any CPU worth 10$ in the 90s was simply out of the question.

And sure you could do a lot in segmented memory and when you were confined to it either by low end HW or legacy support it might make sense, but for a brand new system it would been just utter stupidity.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

Lou Quote:

Apple was close to abandoning Mac on 68K but Bill Mensch's suppliers couldn't deliver faster 65816 cpus in quantity...meanwhile other manufacturers were producing much faster versions in quantity. So the Apple IIgs never got a successor and always gimped to 2.8MhZ in fast mode. Jobs wanted an 8MhZ 65816 and Mensch's suppliers didn't deliver. This video documents it pretty well: https://www.youtube.com/watch?v=UDUQEKxfGEw Apple IIgs was hobbled by talking down to the 1MhZ bus for I/O and Apple II compatibility. I have documented this in another post/thread. For (1) reference see the Nintendo SA-1 chip (RF5A123) at 10.74MhZ. Ricoh's 65816 had DMA and MUL and DIV...and fixed REP and SEP commands. The CMD SuperCPU128 used a 20MhZ 65816 in 1997. Accelerator cards for the Apple IIgs have existed since 1990. SANYO created their own 65816 design that could run at 15MhZ in 1992 for WDC.

Did you watch the video yourself? The 6502 family designs were closely tied to memory timing like later ARM designs. While this increased performance, it required more expensive memory. Dave Haynie's response in your video link to a 65816 Apple IIGS being an Amiga killer follows.

Dave Haynie Quote:

Yeah, right. You're going to grow very old waiting for 65816s that can compete with the latest 680x0s. Way back in '85 when I was looking around for a follow-up for the C128 for Commodore, I looked at 65816 chips. We had actually received specs on them from WDC several years earlier. At that time, they had fully speced 8MHz parts, yet in '85, GTE (the only company actually MAKING 65816s) had all they could do to make enough 4MHz parts. Rumor is that Apple managed get enough for the IIGS by actually having a special 2.8MHz version tested. I needed 4.08MHz parts, but enough of that. It really doesn't matter if WDC eventually comes out with a 20MHz part (neat trick; with a memory cycle time of 60ns, you'll need a 35ns-45ns SRAM to talk to the thing), it's not going to compete with newer machines. It's just going to lose based on architecture - each instruction does so little work compared to the 680x0. Same reason you aren't seeing serious competition from fast 8088s anymore.

One of the video comments is the following.

john_ace Quote:

I had a talk once with an ex-Apple employee who did work on the IIgs Rom. He said that they did experiments with 4MHz and 7MHz (and even higher clock speeds) with engineering samples. The system did work at those speeds but at more than 4MHZ, faster Dram was needed, which would have increased costs. The 65816 was still unstable at higher speeds and more importantly not available in volume in the foreseeing future. The early versions of the 65816 did have some severe bugs that became apparent at higher clock speeds. Applied Engineering had to work around those bugs with their GAL-logic to archive 7 and 8MHz. I suspect that early revisions of the FPI did have 4MHz and 7MHz options but those were removed in the final revisions. In the end they went with the absolute safe option of slightly under 3MHz and may have hoped to update the IIgs with a higher cpu-clock later on with a new revision. Sadly that never materialized.

The increased performance from aggressive memory timing was not as important as more tolerant and flexible memory timing of 68k CPUs. Aggressive memory timing did not scale either as memory clock speeds did not keep up with CPU core clock speeds. A high clocked 6502 family MCU with up to 64kiB of SRAM is fine but anything more is better off with a different and better architecture.

The video has Steve Jobs and John Sculley preferring the 68k Mac over the more limited Mac II. It was mainly the Woz pushing for a faster 6502 family Apple II. A higher clock speed 65816 was possible but the higher price of higher clock rated CPUs and higher priced DRAM was a bad combo for a low end computer and the late arrival was a no go.

Lou Quote:

While Bill M. did have the beginnings of a 32bit design, he started recommending ARM in the late 80's/early 90's to customers who asked for 32bit solutions. I find it 'funny' that the 68K is so great that 'Amiga' uses 65CE02 in the CDTV CDROM controller and A2232 serial card. Speaking of Apple, they had a skunkworks project called Mobius - for an 8MhZ ARM-based APPLE III (yes 3!) that could emulate 6502, 65816 and 68000) and the 68000 emulation was faster than an actual 68000 (cuZ it sucks) ... https://web.archive.org/web/20050208095510/http://www.advanced-risc.com/art1stor.htm Well, what comes around goes around and the best 68K accelerator is a 68K emulator on ARM. LMFAO! So yes, once again - I re-iterate that Amiga on 65816 would have naturally led to more success and eventually ARM instead of 68K and PPC death.

Where do you find these fantasy links? The 65816@8MHz does not have the same performance as a 68030@25MHz.

https://web.archive.org/web/20050208095510/http://www.advanced-risc.com/art1stor.htm Quote:

In frustration, I went off to Redwood City to work with some insanely great guys, building black computers. Interesting to note - the first NeXT (25Mhz 68030) had the same Dhrystone rating (6000) as the 8 Mhz ARM based A310 computer - showing the inherent ARM efficiency.

ARM2 had good performance efficiency (performance/MHz) for the time due to generally better timing of instructions and more aggressive memory timing but the 68030 had caches and a better ISA by performance metrics, especially fewer instructions to execute and better code density.

Year | CPU | DMIPS/MHz
1987 68030 .36
1987 ARM2 .33

More expensive memory with aggressive memory timing makes a large difference for performance.

https://developer.arm.com/documentation/ka001236/latest/ Quote:

Wait-states | Cortex-M3 DMIPS/MHz | Cortex-M4 DMIPS/MHz 0 1.24 1.25 1 0.95 0.95 (-24%) 2 0.69 0.69 (-45%) 3 0.53 0.53 (-58%) 4 0.43 0.43 (-66%) 5 0.36 0.36 (-71%) 6 0.31 0.31 (-75%)

Commodore liked cheap memory and the 68k Amiga outsold the ARM Archimedes based on price. Sure, the 1987 ARM2 could emulate a 1979 68000 reasonably well but a 1987 68030 could outperform it. The 68030 was based on the older 68020 so could have had better instruction timings. Later 68k CPUs were more pipelined and then it was ARM that struggled to keep up in performance efficiency with 68k CPUs like the 1994 68060 which was not surpassed by an in-order 8-stage CPU until the 2011 Cortex-A7, 17 years later.

Lou Quote:

An Amiga is just a slower ST with custom chips. How well did 68k->PPC work out? That's my point about the cpu...does the cpu make the system? No. 68k is not magical. There are pre-emptive multi-tasking OS(es) available for the 8/16bit cpus.

You have no respect for a clearly superior Amiga chipset and AmigaOS.

Lou Quote:

Commodore's engineers were pretty good at making custom 6502's. Better than Bill Mensch I'd argue. 68000 was an expensive boat anchor. The 65CE02 was amaZing but they gimped it by making it pin-compatible with a 6502 hence the need for an MMU for larger memory addressing. They gave it 2 more registers, a 16bit stack pointer, 5 16bit instructions to manipulate WORD(s) in memory, relocatable base-page addressing (via new B register vs MMU on C128) to speed up memory r/w even more and extended branch jumps to 16bit addresses.

You have no respect for the 68000 which was the highest performance MPU when it was released in 1979 and created the workstation market replacing mini computers and the 32-bit embedded market. You do not seem capable to understand the advantage of a large flat address space, PC relative addressing and separate user and supervisor mode stack pointers for OSs or the orthogonality and GP register advantage for compilers.

Lou Quote:

Hombre was going to be HP PA-RISC. Yeah, the writing was on the wall for 68K. They weren't looking at PPC. So the AAA Amiga wasn't going to be Amiga-compatible. Was it even gonna be called an Amiga? Might as well have called it a C5000. C for Commodore.

AAA was mostly compatible with OCS/ECS and partially compatible with AGA. AAA was replaced by AGA and AA+ so was unlikely to ever see the light of day. It was too expensive early and too late and incompatible later. A 68k Amiga SoC with AA+ was the way forward which Commodore planned but failed to deliver with a $100 cost reduction, improved chipset features and better performance. The Hombre chipset with PA-RISC was incompatible and not a 68k Amiga but it could have been a 3D GPU for an Amiga and a 68k Amiga SoC could have been included for Amiga compatibility, both options considered if not planned by Commodore along with the 68k Amiga SoC.

Lou Quote:

If Commodore had gone the ARM-like route in making their own 32bit successor to the 65816, they could have actually been ARM. Remember, the ACORN's BBC Micro? They only developed ARM because Bill Mensch was lacking/lagging. Commodore could/should have been ARM.

ARM was a failure for the desktop and console markets and struggled even for the embedded market while the 68k was a major success in the embedded market and workstation market and a moderate success in the desktop and console markets. ARM was the #4 32-bit embedded architecture behind the #1 68k, #2 MIPS and #3 SuperH as late as 1997. This is after the Thumb ARM ISA was released in 1994 licensed from Hitachi SuperH, a 2nd supplier of 68k CPUs and using technology borrowed from the 68000 for better code density. Thumb-2 circa 2003 was a major improvement, and along with persistence and 68k absence due to the fat PPC replacement, gained ARM the embedded market.

Last edited by matthey on 18-Apr-2025 at 07:14 AM.

@Kronos

Quote:

Next you have to remember that a big part of the A1000s (limited) early success was the combo of a multitasking OS in non segmented memory.

I would argue a significant part of the Amiga's general success was the decision to sacrifice CPU performance for graphics + IO performance, i.e. ChipMem and DMA. The target audience was much more interested in good graphics and sound, and din't care about calculating spreadsheets or doing statistical analyses. And to my knowledge, the majority of machines sold in the first years had only ChipMem installed.

@codis

Quote:

codis wrote: I would argue a significant part of the Amiga's general success was the decision to sacrifice CPU performance for graphics + IO performance, i.e. ChipMem and DMA.

Yes and no. The OCS was designed that way because the 68000 had that quirk where it could only use 50% of the memory bandwidth in a best case scenario.

The split between odd and even cycles meant that the 68000 would only loose when executing an opcode in an odd number of cycles. Or if you pushed the chipset beyond taking just half the cycles.

So in a usual 4 color WB running an application you'd see almost no downside while a game developer would need to balance his code for either GFX or CPU.

That all went away with faster CPU and got completely perverted with AGA where the memory was clocked at half the CPUs speeds meaning the CPU only had a 25% chance to get that RAM access without some waitstates thrown in.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@matthey

I find you're post mostly ridiculous. I answer your questions as to where the problem was: Bill Mensch and HIS manufacturers.
The solution: other manufacturers who used their own masks.

So Commodore was making better "6502's" than Mensch and so was basically everyone else.

How does the TG-16 release a 7.16 65C02 in 1987? Did they use a WDC chip? No - they used a CMOS version manufactured by SEIKO and NEC. Their SiP contained their custom mmu for 2MB of addressable space. How much of a stretch would it be to make a fast 65816? That wasn't their goal/need and would have potentially negated the need for the MMU since it can address 16MB natively.

Other manufacturers were making 65816's without the bugs of the WDC version and they were faster. FYI the 68000 is buggy, hence the 68010.

The ARM emulator was emulating a 68000 not a 68030. So, was a 68030 affordable in 1987? It was barely affordable in 1990. ARM2 in 1987 was 12MhZ and was 7x better than the A500/2000's lame 7.14MhZ 68000. You really should get your #'s straight.

A500 was just an A1000CR. A600 was basically a CDTV-CR. It's ridiculous that Amiga kept using a 68000 in so many products for so long. "For Compatibility" - really? Once the C128 was released, many publishers RE-released C64/128 versions of their software because if your software poked the 2mhZ register in 64mode, you'd lose the VIC display. "Compatibility" was a lame excuse. That's a software developer/publisher problem - not a hardware manufacturer.

Re:compatibility of the AAA Amiga
the developers said it themselves - they'd have an Amiga on a card. So just like running a PC on a card and that's how it would have been "compatible". AA, aka AGA was just a tweak to ECS. AAA is nothing like AGA. AGA Amigas were still gimped by a 3.57MhZ bus, just wider. That's why the new architecture was needed.

@Kronos

Quote:

Kronos wrote: @codis Quote: codis wrote: I would argue a significant part of the Amiga's general success was the decision to sacrifice CPU performance for graphics + IO performance, i.e. ChipMem and DMA. Yes and no. The OCS was designed that way because the 68000 had that quirk where it could only use 50% of the memory bandwidth in a best case scenario. The split between odd and even cycles meant that the 68000 would only loose when executing an opcode in an odd number of cycles. Or if you pushed the chipset beyond taking just half the cycles. So in a usual 4 color WB running an application you'd see almost no downside while a game developer would need to balance his code for either GFX or CPU. That all went away with faster CPU and got completely perverted with AGA where the memory was clocked at half the CPUs speeds meaning the CPU only had a 25% chance to get that RAM access without some waitstates thrown in.

Wait states were somewhat masked by the fact that the fastest instruction executed in 4 clocks. If you used the 'fancy' addressing modes, not you're up to 8+(and much higher) clocks making your 7.14MhZ cpu no faster than a 1MhZ 6502. Go look at how many clocks it takes to use MUL and DIV, LOL! The blitter fools you into thinking the cpu was great. Adding an REU to a C64/128 gives it a blitter too. That's why this is possible: https://www.youtube.com/watch?v=UPlGtSpSt3w

@Lou

[/quote]
Wait states were somewhat masked by the fact that the fastest instruction executed in 4 clocks. If you used the 'fancy' addressing modes, not you're up to 8+(and much higher) clocks making your 7.14MhZ cpu no faster than a 1MhZ 6502. Go look at how many clocks it takes to use MUL and DIV, LOL!
[/quote]
This is an area where I have just very superficial knowledge.
A fancy (complex) instruction set can map relatively complex HL constructs to very few machine instructions. That looks great on paper, but how many cycles those instructions require, especially for memory accesses, is a different question.
This is were RISC's load-store architecture made its mark.

@Lou

Just the usual nonsense...


Noone in their right mind used DIV/MUL and saying that some better 8bit CPU would have been available in 87 really doesn't help with a design that was started 5 years prior and ended up late to the party.

Sure you can construct cases were that beefed up 8bit beats an 68k. If you ignore the extra man hours needed to unlock that power in contrast to the ease of coding on the 68k.

You can also rant endlessly bout hypothetical even better 8bit that could've, would've and surely should NOT have been.

When the Amiga was started 68000 was the best choice.
During it's development both before and at C= there were no resources and surly no time to be wasted on a major HW overhaul.

Once it was released no other CPU option available at that time would have justified an architecture change.
When updates were needed no viable alternative to 020/030/040(/060) was available.
When the 68k line was declared EOL PPC was a viable solution that just made perfect sense with the information available at that time.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Lou

Quote:

Lou wrote: 3 people created the ARM cpu. 3. I'm pretty sure Commodore had more than 3 engineers.

And they did it all for free because all it took is one magical weekend.

It's not the mere presence of engineers, it's having the right engineers to make anything. Also, higher quantity of engineers does not necessarily, if ever, improve the outcome.

C= would have to have wanted to be an innovator in the microprocessor space to then go on to retain the small team of quality IC engineers to accomplish what ARM had. C='s actions scream at us over the chasm of time that they did not care to be a player in this space.

And then they'd need lots of money, because other than modifying RISC V, this industry not unlike to auto industry works on the time scale of decades. It's not cheap now, and it was orders of magnitude more expensive then to be a significant/relevant player in the microprocessor industry. By the mid '80s, C= had zero hopes of entertaining the possibility of dreaming about perhaps considering the idea of giving their company a chance at maybe having a microprocessor division.

Last edited by agami on 20-Apr-2025 at 02:58 AM.
Last edited by agami on 20-Apr-2025 at 02:57 AM.
Last edited by agami on 20-Apr-2025 at 02:56 AM.

_________________
All the way, with 68k

@agami

Quote:

And they did it all for free because all it took is one magical weekend.

2 people are generally mentioned: Sophie Wilson did the architecture (instruction set) and Steve Furber did the microarchitecture (the silicon design). They did it over a period of 18 months but there were others involved. It first powered up almost exactly 40 years ago (26th April 1985) and worked first time.

Quote:

It's not the mere presence of engineers, its having the right engineers to make anything. Also, quantity of engineers does not necessarily, if ever, improve the outcome. C= would have to have wanted to be an innovator in the microprocessor space to then go on to retain the small team of quality IC engineers to accomplish what ARM had.

Commodore did have chip designers and according to the docs, Commodore were planning to design the PA-RISC CPU in the Hombre, but that's was starting with an existing architecture and they probably could have got help from HP.

Quote:

C='s actions scream at us over the chasm of time that they did not care to be a player in this space.

Even if they did, I doubt they would have got very far given Commodore's management.

Give the original topic of this thread, it's slightly amusing to find that Arm's first CEO was an ex-Motorola guy.

_________________
Whyzzat?

codis Quote:

This is an area where I have just very superficial knowledge. A fancy (complex) instruction set can map relatively complex HL constructs to very few machine instructions. That looks great on paper, but how many cycles those instructions require, especially for memory accesses, is a different question. This is were RISC's load-store architecture made its mark.

It is RISC that looks better on paper than CISC but RISC has a memory bottleneck that was especially detrimental to performance in the early days of MPUs without caches. The small cores and pipelines with single cycle execution throughput of ALU instructions was appealing but the instructions have to be loaded before executed and they have to be fetched first. Without caches, they were fetched from memory. Accumulator architecture CPUs often had small instructions, usually 8-bit variable length instructions. They often had few registers and used implicit ops to keep the instruction size to a minimum which was more important than minimizing the code size and number of instructions executed. They often used 8-bit memory. CISC CPUs reduced the code size and number of instructions executed but instruction sizes generally increased and more area was required for GP registers. CISC CPUs were more efficient using 16-bit memory and caches for the larger instructions and instruction fetches. Early RISC architectures decreased execution cycle times and added more GP registers but instruction sizes and code sizes increased while the number of instructions executed was similar or higher than CISC architectures. Most early RISC architectures used 32-bit fixed length encodings making all instructions 32-bit and practically requiring more expensive 32-bit memory to maintain performance.

Fetching instructions from memory
ISA | Instruction size | 8-bit memory | 16-bit memory | 32-bit memory
ARM 32-bit 4 cycles 2 cycles 1 cycle
Thumb 16-bit 2 cycles 1 cycle 1 cycle

Early RISC architectures tried to minimize this expensive disadvantage. Early MIPS cores had multiplexed busses to reduce the cost and ARM used a cheaper von Neumann shared instruction and data bus.

The ARM RISC Chip - A Programmer's Guide
https://arcarc.nl/archive/Books/The%20ARM%20RISC%20Chip%20-%20A%20Programmer%27s%20Guide%20-%20Alex%20Van%20Someren%20&%20Carol%20Atack/The%20ARM%20RISC%20Chip%20-%20A%20Programmer%27s%20Guide%20-%20Alex%20Van%20Someren%20&%20Carol%20Atack.pdf Quote:

2.2 The ARM6 data path The ARM6 CPU has a 32-bit address bus, 32-bit internal data paths and a single 32-bit external data interface through which both instructions and data pass during program execution. This traditional design approach, known as a 'von Neumann' architecture, imposes limits on the processor performance but was adopted for the ARM due to its simplicity and low cost of implementation (Furber, 1989). As a result, instructions which load data from or store data to memory must take at least two clock cycles to execute (the first one for the instruction, the second for the load or store itself). Although it is possible to reduce instruction execution time by using separate instruction and data paths (the so-called Harvard architecture) the ARM approach has the counter-advantage that it allows multi-stage addressing operations such as indexing or stack operations to be implemented without increasing the complexity of the CPU. ARM6 exploits this valuable side-effect by providing many instruction formats which can exploit these addressing styles.

ARM6 was after ARM3 so this was still early. Caches were a big improvement for RISC but the large code size meant more instruction cache misses and the RISC memory bottleneck. This is why Thumb was so important for ARM to enter the embedded market but the number of instructions executed could increased by 30% which was a problem for other 16-bit RISC encodings as well like SuperH which it was copied from. The 68k number of instructions executed is competitive with 32-bit fixed length encoded RISC architectures while it has code density better than most compressed RISC ISAs. The compressed RISC ISAs allowed to use 16-bit memory like the 68k and finally compete in the embedded market at least but they sacrificed more performance than good CISC architectures like the 68k. The 68020 and 68030 used a Harvard architecture with separate instruction and data accesses, did not used multiplexing, had a small but effective instruction cache and ARM code was more than 50% larger than 68k code. That is a huge difference, especially with less than 32-bit wide memory and memory with wait states as was common. Eventually, CISC architectures increased pipelining so not only ALU operations had single cycle throughput but even pipelined cached memory accesses too. RISC architectures still had a memory bottleneck in comparison resulting in increased cache misses and more memory traffic than good CISC architectures like the 68k.

Early ARM instruction cycle latencies were not all single cycle either.

ALU 1 +1 if you use a register-specified shift Rs, +2 if Rd is pc.
B, BL, BX 3
CDP 1+B
LDC 1+B +N
LDR/B/H/SB/SH 3 +2 if Rd is pc.
LDM 2+N +2 if pc is in the register list.
MCR 2+B
MLA 2-5
MRC 3+B
MRS, MSR 1
MUL 2-5
STC 1+B +N
STR/B/H 2
STM 1+N
SWI, trap 3
SWP/B 4

Instruction latencies were generally better than the 68020 and 68030 but ARM timings in memory suffered more from early typical cheap memory. ARM instruction latencies did not improve much from increased pipeline lengths where 68k instruction latencies improved with increased pipeline depth eventually surpassing most of these timings with the 68060. The RISC major advantage is simpler and easier to design cores but the major disadvantage is the memory bottleneck which still exists today.

The original ARM architecture had other issues and inefficiencies.

o early 26-bit address space hardware limitation
o PC in GP register file and LR only leave 12-13 GP registers which is low for a RISC architecture
o poor code density despite only encoding 16 registers
o shift is not as cheap as sign and zero extension for decompressing immediates
o 32-bit fixed length instructions and poor code density was bad for embedded use
o Only 12-13 GP register performance handicap and 26-bit address space was bad for desktop and workstation use

The solutions were to change ISAs and drop mistakes at the expense of compatibility. The 68k has fewer issues and inefficiencies than the original ARM and replacement Thumb ISA. ARM Thumb-2 and AArch64 ISA replacements are better ISAs and closer in efficiency to the 68k ISA. A variable length Thumb-2 ISA was required to compete in code density with the 68k and it still had more instructions to execute and lower performance than the 68k ISA. AArch64 competes in performance with a 32-bit fixed length encoding, ~32 GP registers, CISC like addressing modes and finally similar if not slightly fewer instructions executed but does not compete in code density with the 68k ISA. The 68k CISC ISA is not such a bad trade off and there is room for improvement as it now looks less complex and more reduced than some so called Reduced Instruction Set Computers (RISC).

Last edited by matthey on 20-Apr-2025 at 04:47 AM.
Last edited by matthey on 20-Apr-2025 at 04:35 AM.

@minator

Quote:

minator wrote: Give the original topic of this thread, it's slightly amusing to find that Arm's first CEO was an ex-Motorola guy.

The OP's argument was that Motorola deserved to be hated for 'getting fat and lazy', which is not incompatible with ex-Motorola engineers doing great things after leaving them - even with RISC.

Acorn weren't fat and lazy, they were thin and lazy. ARM was a lazy design. They spent the minimum amount of effort they could to develop it. The real reason ARM made it big was the low power high speed process they used, which had nothing to do with Acorn. Motorola and Commodore both produced their own chips so they had to put a lot more effort into it.

Motorola didn't just make CPUs. They had different process lines for a wide variety of semiconductors. They were into communications chips and other stuff more than desktop microprocessors - which were just a sideline for them. Motorola was fat, but they weren't lazy.

The OP hates Motorola because they ultimately couldn't compete against Intel in the PC market. But there was only room for one architecture and Intel got there first with a lazy design for IBM's lazy PC. Motorola's 68000 was a far better design - too much so for IBM who just wanted something cheap that would make porting CP/M code easier. The result was that Intel got all the cash and could justify investing heavily in x86, while Motorola had their other product lines to consider and would have a much harder time getting enough income to continue 68k development.

If it hadn't been for Intel and IBM's laziness 68k would probably would have been the leading desktop CPU architecture and Motorola would have the funds to develop it more - and we wouldn't be having this conversation.

@Lou

Quote:

Lou wrote: @Hammer Quote: CRAP [...] PADDING Apple was close to abandoning Mac on 68K

Source?
Quote:

but Bill Mensch's suppliers couldn't deliver faster 65816 cpus in quantity...meanwhile other manufacturers were producing much faster versions in quantity. So the Apple IIgs never got a successor and always gimped to 2.8MhZ in fast mode.

The Apple IIGS never claimed to replace the Macintosh: that is pure fantasy from fanatics like you.
Quote:

Jobs wanted an 8MhZ 65816 and Mensch's suppliers didn't deliver.

Job was a manager, and not a technical guy: he could have wanted the Moon, and get it is a completely different story.
Quote:

This video documents it pretty well: https://www.youtube.com/watch?v=UDUQEKxfGEw

Nothing that could prove your thesis.

From your video "unsource claim on wikipedia"...
Quote:

Apple IIgs was hobbled by talking down to the 1MhZ bus for I/O and Apple II compatibility.

Guess what: it was made for replacing the Apple IIs AND reusing its software and components.

Compromises were an absolute necessity for achieving that goal.
Quote:

I have documented this in another post/thread. For (1) reference see the Nintendo SA-1 chip (RF5A123) at 10.74MhZ. Ricoh's 65816 had DMA and MUL and DIV...and fixed REP and SEP commands. The CMD SuperCPU128 used a 20MhZ 65816 in 1997. Accelerator cards for the Apple IIgs have existed since 1990. SANYO created their own 65816 design that could run at 15MhZ in 1992 for WDC.

And? Do they go to full speed when accessing the Apple II' I/O cards, or they still had the 1Mhz limit?

Even the C64 had 65816 accelerators, but
Quote:

While Bill M. did have the beginnings of a 32bit design, he started recommending ARM in the late 80's/early 90's to customers who asked for 32bit solutions.

The reason is very simple: a 32-bit bit design of already crappy 16 and 8 bit designs, wouldn't have changed the situation. In fact, it would have still being a crappy architecture, unsuitable for modern needs.
Quote:

I find it 'funny' that the 68K is so great that 'Amiga' uses 65CE02 in the CDTV CDROM controller and A2232 serial card.

Not funny, rather it's a concrete example of correctly using a component for what's needed: the 65CE02 was good for a small and cheap microcontroller, so it was well deserved to be the slave of the main computer for handling such I/O stuff.
Quote:

Speaking of Apple, they had a skunkworks project called Mobius - for an 8MhZ ARM-based APPLE III (yes 3!) that could emulate 6502, 65816 and 68000) and the 68000 emulation was faster than an actual 68000 (cuZ it sucks) ... https://web.archive.org/web/20050208095510/http://www.advanced-risc.com/art1stor.htm

And? Apple made several projects and some of them were mistakes.

Talking about computer architectures, have you ever eared (only eared: I don't expect that you've studied it) of Apple's Scorpion processor? Clearly not. It was the equivalent of Intel's APX432.
Quote:

Well, what comes around goes around and the best 68K accelerator is a 68K emulator on ARM. LMFAO!

Only in your wet dream of blind fanatical. 68k had much better accelerator which had equivalent performance of such ARM processors.

But I reveal you a secret: 68040 first and 68060 put ARM processors in the dust in terms of pure performance, showing the advantages of CISC processors.
Quote:

So yes, once again - I re-iterate that Amiga on 65816 would have naturally led to more success and eventually ARM instead of 68K and PPC death.

LOL. You're completely detached from the reality: you need someone really good for you.

First of all, and as I've already said you went you have written the same load of b@ll, Amiga engineers needed a time machine for getting a 65816 just for designing the computer. So, not even talking about the final production, which as well would have required a version of such processor with decent clock speed (and WITHOUT bugs).

Second, and even more important (well, getting a time machine was already THE showstopper for such stupid idea), a 65816 is pure crap for the requirements of a modern computer which isn't classified like a toy. In fact, dealing with complex types / data structures is simply a nightmare for such crappy processor.
In fact, YOU issued a challenge to increase the value of a vector, but when I showed you the code in C and requested your version for the 65xx, you completely disappeared. I wonder why...
And it was a very simple, trivial example of handling a more complex data type (compared to just scalar values of simple types like integer). You can't imagine how much more complex data structures are needed, and how pathetic the performance of the higher-performance 65816 would be.

In short: those are your usual wet dreams of a 65xx Taliban, which is trying to satisfy his (heavily) violated ego by miserably and stupidly TRYING (that's the most that you could do) bashing the hated 68k processors which, unfortunately for you, slapped your beloved crappy processors two a the time until it made odd (cit.).