@megol Quote:

megol wrote: This thread again?

I don't know what are you talking about : there was no code density thread here, or even on other forums.

If you're referring to the microprocessors discussion which came out, then it's normal when talking about this argument: it's normal to make comparisons, it's normal to talk about what-ifs, and it's also normal to talk about possibilities. Isn't it a discussion forum?

However we can try to stick as much as possible to the topic, attempting to avoid other "sub-discussions".
@matthey: maybe it's more interesting to open another thread discussing specifically about the 68K and its future, with a more structured approach, like I'm trying to do in this thread. So, with some "summary posts" used to collect/recap specific information.
We had some nice discussions about 68K and its future on Olaf's forum, but unfortunately it's closed, and the threads aren't accessible anymore...

Previously I forgot to reply to this:
@Fl@sh Quote:

Fl@sh wrote: My recent replies are targeted to not consider only code density in a cpu, there are a lot of other things who can make huge difference.

Yes, but besides the pure performances the only other big topic / very sensible argument when talking about microprocessors is only the code density. That's at least what I can think about...

@cdimauro @matthey

I was worried when I saw all the TBD posts, but I've found this interesting, so I hope it will continue. I don't see why it should go into another for the 68K but if it does I'll follow it.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

cdimauro Quote:

Yes, but there's no other choice unfortunately: almost all applications are compiled nowadays, and we can't even think of fully converting them to hand-optimized code. The good thing is that 68K support was recently added to CLang/LLVM, which is the most promising compiler. So, there's chance that generated code can improve a lot .

Popular architectures with lots of hardware available are the ones that receive the most development. The 68k continued support in GCC and new support in Clang/LLVM after about 25 years with barely any new hardware shows just how popular the 68k was but I still hold little hope of support improving to where GCC 2.95.3 was and even less to the standard of support for popular architectures with mass produced processors today. The 68k may have been the most popular 32 bit processor in the world but popular processors now can sell several times what it did due to expansion of the embedded market.

cdimauro Quote:

Unfortunately and incredibly the 6800 family wasn't considered by Dr. Weaver, so there's no data. It's quite strange, because it was one of most used microprocessor in the embedded world.

The 6800 was one of the most popular processors until the 6502 completely overshadowed it. The 6502 is estimated to have shipped 5 to 10 billion units and hundreds of millions of units are still shipped annually for embedded use.

https://www.westerndesigncenter.com/wdc/

It's hard to believe that CBM owned MOS and employed Chuck Peddle yet had such incompetent management. The 6502 family was used everywhere anyway due to the low cost.

Apple II
Atari 2600, 8 bit family, Lynx
BBC Micro
CBM Pet, C64
NES

What was the 6800 used in? Nothing memorable. It did make some what of a comeback with the nice but expensive 6809 in 1978. The 68000 was launched in 1979 which was quite a bit more powerful and expensive but the price had dropped to about $15 by 1984 due to mass production which was cheaper than the 6809 had been in the early 1980s.

The following document, "Classifying Instruction Set Architectures", mentions the 6809 as an example of an accumulator architecture on the first page of the pdf.

http://cs.uccs.edu/~cs520/S99ch2.PDF

It later does some code size comparisons using accumulator code on page 5. This example uses multiply which the 6809 had and is unusual in early 8 bit processors but it also shows a divide instruction so this is maybe a hypothetical accumulator architecture that may resemble the 6809? In any case, hardware multiply and divide make a difference in code density as the code wouldn't fit on one page without them. There is a comparison of the different architectures on page 9. The accumulator architecture used had better code density than the load/store architecture (MIPS) which had the worst code density.

cdimauro Quote:

68000 has only very limited memory-memory support, with a few instructions allowing memory reference for both source and destination.

Move memory to memory is common though.

move mem,mem
+ smaller code
+ fewer instructions
+ fewer registers used
+ sometimes saved cycles
- larger instructions

A dual ported data cache would likely be necessary to see the full performance advantage on a superscalar core. The 68060 did not have much of a performance advantage other than the smaller code and reduced register usage.

cdimauro Quote:

8086 has also very limited accumulator support, with just a few instructions which uses only the accumulator, and some which have short encoding when using it. It has also a few memory-memory instructions. 68H12 is accumulator (but has many registers), register-memory, and also memory-memory (but limited to a few instructions as well).

Implicit ops sound like they could be good for code density but they often take extra instructions to move to the expected location. The decreased orthogonality makes compiler support more difficult as well.

cdimauro Quote:

That's why the embedded world is abandoning the 8 and 16-bit families: 32-bit ones became cheaper to produce, and with much less constraints. So, it's also easier to develop. Combined with a good code density, they are the most favorite.

Yes, an 8 bit core is a pain to develop for. Only 256 bytes can be addressed without bank switching and any kind of OS is very difficult. Embedded systems using 8 bit cores are very simple, very low power usage and/or very low price. They still likely account for billions of processors used annually even though they are only used in about 10% of embedded systems. Many embedded systems would be fine with 16 bit cores but it is easier for OSs to support 32 bit architectures and they often have a performance advantage with little extra cost.

cdimauro Quote:

Only starting from the Pi 2 the Raspberry have a 64-bit architecture. But this platform isn't selling a lot: only a few millions, compared to a market of billions of devices.

Raspberry Pi units sold looks pretty healthy to me.



I could overlay the AmigaOS 4 hardware units sold but just use the bottom horizontal line to represent their units sold.

The Raspberry Pi, Pi Zero and Pi Pico have 32 bit cores while the the Raspberry Pi 2, 3 and 4 have 64 bit cores. Raspberry Pi Foundation has started making their own custom SoC with ARM M0+ 32 bit cores (partial Thumb 1 and 2 support) for the $4 U.S. Pi Pico so 32 bit is still alive by choice. The Pi Pico has 264 kiB of SRAM and 2MiB of flash. A command line only RISC OS Pico runs on it but the full RISC OS needs 4 MiB of flash memory (ROM). The Amiga 1000 had a preemptive multitasking AmigaOS with GUI using 256 kiB of memory and 256 kiB of WCS/ROM. Amiga Nowhere is only going big fat and expensive today though.

cdimauro Quote:

x86-64 sucks because on average you have 0.8 bytes more per instruction compared to IA-32. It has really a poor code density, and nothing can be made to change this. So, the embedded market for 64-bit devices should take a look at different ISAs.

x86 was used some for embedded devices but that was probably as much about cheap prices and good developer tool support from mass production. The x86-64 architecture is less appealing as can be seen by the Intel Atom processors being limited to only the highest performance embedded systems despite many offerings.

cdimauro Quote:

Yes, but those are products for nano-niche markets. Nothing which generates large volumes. That's why I consider them dead. BTW FIDO isn't even 100% 68K-compatible.

Fido is CPU32 compatible which is still considered 68k unlike ColdFire. It's actually a pretty good cut down standard which is better than the 68000 or ColdFire ISAs in my opinion. Supervisor mode is much different than Motorola 68k processors which is probably the reason it hasn't been used for an Amiga. The fast auto preemptive hardware task switching is a clever idea but maybe it should have been done for an OS rather than replacing an OS. Industrial Control/Automation is the biggest embedded market so Fido may be more successful than you think.

1. Industrial Control/Automation 32%
2. Consumer Electronics 29%
3. Internet of Things (IoT) 25%
4. Communications/Networking/Wireless 19%
5. Automotive 17%
6. Medical 16%
7. Electronic Instruments 14%
8. Military/Aerospace 14%
9. Audio 10%
10. Computers and Peripherals 10%

cdimauro Quote:

Absolutely agree. The problem is: who'll do it to address the embedded market (AKA large volumes)?

Someone that needs it should do it. I didn't have any trouble finding embedded players interested in the 68k and needing enough volume to make ASICs. It would require professional development but I had a chip architect in mind at one point (*not* Gunnar and much better reputation). It would require some investment but I've talked to people about investing. Gunnar wasn't interested but he's oblivious, especially when it comes to business. Everyone has different needs and expectations which makes it difficult to put together but maybe I would try again someday with favorable conditions.

Last edited by matthey on 06-May-2021 at 01:39 AM.

@matthey

Quote:

It's hard to believe that CBM owned MOS and employed Chuck Peddle yet had such incompetent management.

I think I can do you one better.

Motorola employed Chuck Peddle first. He helped design the 6800, then went to MOS to design the 6502 because Motorola's management wouldn't heed him on the need for a more affordable 6800. So one might well argue that it's hard to believe that Motorola owned what became Freescale and employed Chuck Peddle yet had such incompetent management.

Both CBM and Motorola Semiconductor seem to have shot themselves in the foot largely by taking their eyes off the ball and losing sight of their core business. CBM thought it had to break into the PC-compatible market, and Motorola thought it had to abandon 68k and enter the RISC market. A student of mine once said that Motorola simply didn't listen to its customers, so they lost both the desktop market (which they looked poised to dominate in the mid-80s) and the embedded market (which they dominated for quite a while).

My father once said that the 68060 proved that a well-designed CISC could outperform RISC. He's an embedded engineer who thinks Motorola made a mistake with the 68K; he's a huge fan of the 6809 & thinks they should have continued in that direction. I'd be interested in what you guys think of that. I can provide an extended quote on his explanation of the latter if it would help explain what he means.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

@matthey

Quote:

I believe the 68k is more alive than PPC.

68k speed is still as it was in 1995.
ppc is faster and easier to get. So, ppc is more alive than 68k.
Even if You don't like this.

@cdimauro
To see how important it really is for mainstream computing Itanium and x86 are good examples: for Itanium which wastes many bytes in a normal, optimal(!), instruction stream the bad density wasn't a problem. For x86 it's so important that compilers and operating systems doesn't care about adding waste bytes - it's not important.

And of course we can add the argument that 68k most likely would have moved in the same direction as x86 to optimize performance like aligning critical loops to cache line boundaries to maximize decode throughput. This and several other standards is part of what makes modern x86 binaries code density bad.

We have so much memory that operating systems and programs can waste it without problem, caches are large enough that density doesn't improve performance etc. etc.

And those arguments and a lot more have been talked about before thus the "This thread again".

@megol

I tried to rise same exceptions about cache sizes and today's memory speed/abundance, I hope your reply will be more considered.

We all know in todays programming practices nearly all code is written in C/C++ or other high level languages.
Sometimes only few critical parts of code is still written in assembly.

So compilers can make a big difference in code generation, but sadly compilers will never produce same quality code a skilled human coder can do.

Anyway microprocessors are quite complex and you should know very well, for each architecture, instructions clock cycles and applicable addressing modes, and a lot of other things too..
What can be faster on on a cpu is slower in another one, a classic example is Intel vs Amd war where some code is faster on a brand and slower on the other.
Often remaining still on same brand, code can be the best for a generation of cpu and worst for another.
What I want to evidence is that coders can't be locked to hand optimize on a particular ISA implementation, next microprocessors have to be much simpler to program with less instructions and less addressing modes.

All this to reach the goal to produce less complex cpus, with less transistors and an easy way to choose/manage instructions by compilers.

My hope is to get less but at best of possibilities.

PowerPC has three addressing modes and full orthogonality, it was future proof for 32bit->64bit change, it had SIMD units from start and it's ISA can be easily expanded.
For me PowerPc project was much better than any 68k, x86-64 or ARM ISA.

Today IBM is developing POWER (mostly back compatible with old PowerPC ISA) and it's features are, at least for me, the most impressive among others (Power 10).
IBM POWER cpus are currently developed mainly for supercomputers/high end servers, but if we are discussing in theory "how should be a good CPU" this technology can't be excluded from discussion.

Last edited by Fl@sh on 06-May-2021 at 03:15 PM.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@cdimauro

Quote:

Matt already replied, but I add some things which deserve. First, the numbers that you criticized are coming from compiler-generated code. Specifically, when compiling the SPEC suite.

The goal for the SPEC benchmark suite is to reach the highest score and the smallest code doesn't automatically yield the fastest code path.

Quote:

Whereas your above considerations are taking a specific contest where only manually-written code was used and compared. So, you're comparing apples and oranges (despite that 8086 wasn't running Linux, as it was reported).

There's https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset a.k.a Linux-8086

Quote:

Second, this contest is of very limited use for comparing architectures, because: - assembly code is rarely used (even on embedded systems); - the used program was really tiny (in the order of 1KB); - it isn't using so much real-life code; - the provided solutions aren't all equally "top-notch". Regarding the last and for example, the 68K code provided by Matt and ross reorganized the LZSS code (removing one branch instruction) and used a net trick (using the X flag as a flag/signal). Something similar can be used on x86/x64 as well, but I had no time to adapt their code (I only did for my ISA). Anyway and as I've said, those kind of contests are just for fun: IMO the important thing is to look at compiler-generated code.

Code density is also dependant on the compiler (e.g. ICC vs VC++ vs GCC) and the OS.

With the PS4 programming guide, Sony (Naughty Dog dev team) recommends
1. keeping high-performance data small and contiguous within the data cache.
2. keeping high-performance code small within the instruction cache.


PPT slide from Sony's Naughty Dog team.

Last edited by Hammer on 06-May-2021 at 02:31 PM.
Last edited by Hammer on 06-May-2021 at 02:27 PM.

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

@matthey

Quote:

x86 was used some for embedded devices but that was probably as much about cheap prices and good developer tool support from mass production. The x86-64 architecture is less appealing as can be seen by the Intel Atom processors being limited to only the highest performance embedded systems despite many offerings.

Intel Atom CPU is not a small chip when compared to AMD embedded CPU counterpart.

Intel Atom Pine View = 9.7mm2 on 45 nm process
AMD Bobcat = 4.6 mm2 on 40 nm process GoFlo

Intel Atom Clovertrail = 5.6 mm2 on 32 nm process
AMD Jaguar = 3.1 mm2 on 28 nm process TSMC, includes out-of-order processing with dual 128 bit SIMD units. Used for MS's Xbox One and Sony's PS4.

ARM Cortex A15 = 2.7 mm2 on 28 process TSMC.
-----
PS5 CPU's Zen 2 CPU was customized e.g. FADD SIMD units were removed, hence creating embedded Zen 2 CPU lite.

Last edited by Hammer on 06-May-2021 at 02:51 PM.

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

@matthey


Quote:

Raspberry Pi units sold looks pretty healthy to me. I could overlay the AmigaOS 4 hardware units sold but just use the bottom horizontal line to represent their units sold. The Raspberry Pi, Pi Zero and Pi Pico have 32 bit cores while the the Raspberry Pi 2, 3 and 4 have 64 bit cores. Raspberry Pi Foundation has started making their own custom SoC with ARM M0+ 32 bit cores (partial Thumb 1 and 2 support) for the $4 U.S. Pi Pico so 32 bit is still alive by choice. The Pi Pico has 264 kiB of SRAM and 2MiB of flash. A command line only RISC OS Pico runs on it but the full RISC OS needs 4 MiB of flash memory (ROM). The Amiga 1000 had a preemptive multitasking AmigaOS with GUI using 256 kiB of memory and 256 kiB of WCS/ROM. Amiga Nowhere is only going big fat and expensive today though.

I have a few Vulkan IGP capable ARM-based SOCs rendered obsolete (unsupported) by Google e.g. Nexus 5, Pixel 1 and Pixel 2. Pixel 3 on it's last year for Google support. They are all Qualcomm's ARM-based SoCs. Planned obsolescence by Google while preaching about climate change. LOL

I can't do a near-brain dead OS install on Google-branded unsupported hardware like on X86 PC hardware and Windows 10 e.g. year 2010 1st gen Core i7 Dell XPS Studio laptop installed with Windows 10 X64.

PS; I'm aware of unofficial Aosp Android builds which require additional skills to install the unofficial OS.

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

@Fl@sh

Quote:

PowerPC has three addressing modes and full orthogonality, it was future proof for 32bit->64bit change, it had SIMD units from start and it's ISA can be easily expanded. For me PowerPc project was much better than any 68k, x86-64 or ARM ISA. Today IBM is developing POWER (mostly back compatible with old PowerPC ISA) and it's features are, at least for me, the most impressive among others (Power 10). IBM POWER cpus are currently developed mainly for supercomputers/high end servers, but if we are discussing in theory "how should be a good CPU" this technology can't be excluded from discussion.

Can you install AmigaOS 4.1 FE PowerPC for AmigaOne X5000 on Power 9 + Raptor's Blackbird motherboard?

I don't recall Windows 10 X86/X64 being X86 motherboard brand specific.

PowerPC's balkanized ecosystem sucks. PowerPC's balkanized ecosystem reminds me of 68K's ecosystem fragmentation. I can't expect more from Motorola/Freescale/NXP, AMCC and IBM.

It's LOL episode for AmigaOS 4.1 "ported" for A1222.

I know Windows NT 4 PowerPC edition wouldn't install on AmigaOne, PowerMac, Pegasos and Blackbird. PowerPC's future proof.. is garbage.

Last edited by Hammer on 06-May-2021 at 03:44 PM.
Last edited by Hammer on 06-May-2021 at 03:42 PM.
Last edited by Hammer on 06-May-2021 at 03:40 PM.
Last edited by Hammer on 06-May-2021 at 03:37 PM.
Last edited by Hammer on 06-May-2021 at 03:36 PM.
Last edited by Hammer on 06-May-2021 at 03:35 PM.
Last edited by Hammer on 06-May-2021 at 03:29 PM.

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

@Hammer

Quote:

I have a few Vulkan IGP capable ARM-based SOCs rendered obsolete (unsupported) by Google e.g. Nexus 5, Pixel 1 and Pixel 2. Pixel 3 on it's last year for Google support. They are all Qualcomm's ARM-based SoCs.

Have you looked into LineageOS? You mentioned something else but I didn't recognize it, but I thought LineageOS was pretty good about running on more popular devices. I installed it to a Raspberry Pi 3 a year and a half ago, and it ran pretty well. (Someone else had created the distribution.) I'd like to install it to my 2016-era phone which is stuck on Android 5.1 but that phone isn't so popular and I'm not willing to risk bricking it.

Quote:

Planned obsolescence by Google while preaching about climate change. LOL

Pretty much all social posturing by both large corporations and political parties consists of preening / virtue signaling / what have you to separate fools from their money. The best you can say is that it's posturing they've adopted in an attempt to stave off Twitter mobs. Perversely, though, Twitter is largely populated by people who work at large corporations and political parties; i.e., a highly niche audience. Sort of like a company that wanted to have great success in technology deciding to take their marketing and R&D cues from Amigaworld.net. The actual market for that sort of thing has very different priorities.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

@cdimauro

So in the old day, code used to be mostly 16bit, now more often using 32bit data, we waste more memory, but we have more memory to waste.

in some case you can use 1 x 32bit instruction, to do work of 2 x 16bit instructions, or 4 x the work of 8-bit instructions, but that is not how its commonly done.

We do it with AltiVec instructions, but don’t do it with normal instructions.
you just need to get your head around thinking this way, then you see that 16bit and 8bit is almost redundant instructions.

the idea behind fixed length instruction is simplified decoding path, reducing transistors, and latency. A more complex design will be none fixed length instruction, but why not put in a larger cpu cache instead.

Smaller code does not equal, faster code, that’s a misconception, for example tight loops will be slower then unrolled loops. But unrolled loops will take up more space. You can test this yourself with compiler flag -OS and -O3 on GCC; optimize for size or try optimizing for speed, the one optimized for speed will be more often larger.

Next up large ELF files vs small HUNK files, hunk files do not normal contain debug symbol, it’s something you need to enable in VBCC, on GCC you always get at least function name, unless you strip the binary, generally we get larger files so we can debug the files, if the program crashes, We also get larger files because we include clib or newlib, while 680x0 days it more common keep it clib clean, only Amiga lib was linked in. using clib or newlib make programs more portable / standardized, easier to code for.

And Yes including a FPU make allow faster calculation of floating point values, you might not notice any speed improvement, If use too old benchmark tool, don’t do any 3D work, or do not use computer for any complex math.

And yes, a MMU is useful for debugging, virtualization and emulation, and security, not having a MMU is a minus.

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

simplex Quote:

I think I can do you one better. Motorola employed Chuck Peddle first. He helped design the 6800, then went to MOS to design the 6502 because Motorola's management wouldn't heed him on the need for a more affordable 6800. So one might well argue that it's hard to believe that Motorola owned what became Freescale and employed Chuck Peddle yet had such incompetent management. Both CBM and Motorola Semiconductor seem to have shot themselves in the foot largely by taking their eyes off the ball and losing sight of their core business. CBM thought it had to break into the PC-compatible market, and Motorola thought it had to abandon 68k and enter the RISC market. A student of mine once said that Motorola simply didn't listen to its customers, so they lost both the desktop market (which they looked poised to dominate in the mid-80s) and the embedded market (which they dominated for quite a while).

All true. Motorola and CBM both had multiple opportunites to become the IBM of personal and embedded computing but didn't understand what they had or listen to the people who did understand.

simplex Quote:

My father once said that the 68060 proved that a well-designed CISC could outperform RISC. He's an embedded engineer who thinks Motorola made a mistake with the 68K; he's a huge fan of the 6809 & thinks they should have continued in that direction. I'd be interested in what you guys think of that. I can provide an extended quote on his explanation of the latter if it would help explain what he means.

Indeed. The 68060 (1994) outperformed most of the processors of the day in PPA (Power, Performance, Area) including the Pentium P54C (1994) and PPC 601 (1993).

68060 2.5 million transistors (8 stage in order, 8kiB ICache 8kiB DCache)
Pentium P54C 3.3 million transistors (5 stage in order, 8kiB ICache 8kiB DCache)
PPC 601 2.8 million transistors, (4 stage OoO, 32kiB unified cache)

68060@75MHz 3.3V, 0.6um, 2.5 million transistors, ~5.5W max
Pentium@75MHz 80502, 3.3V, 0.6um, 3.2 million transistors, 9.5W max
PPC 601@75MHz 3.3V, 0.6um, 2.8 million transistors, ~7.5W max

Performance was close between these 3 processors but the 68060 is easily the leader when comparing power and area. I guess back then they didn't do PPA analysis like is done for embedded systems today. Neither did Motorola clock up the 68060 much despite the deeper pipeline making it the best candidate of the 3 CPUs above. It's pretty clear that the switch to PPC was a upper level management decision and the 68060 was not to compete with the PPC, especially on the desktop. Despite the low clock speed, the 68060 was still a success in the embedded market where high clock speeds are less desirable because of increased power usage and the need for more cooling.

From my limited knowledge of 8 bit CPUs, the 6800 ISA was nicer than that of the stripped 6502. It was probably not necessary to castrate the 6800 into the 6502 but there was some dead weight that needed to be removed. The huge game changer was the change in chip process which dramatically increased chip yields. The 6809 was a nice enhancement of the 6800. It received some of the same support for position independent code (PC relative addressing modes) as the 68000 which allows for more modular and shared code. There was an independent Supervisor and User stacks like the 68000. There was hardware multiply like the 68000. Most of the registers and the address bus were 16 bit. I expect it was easier to program than many 8 bit CPUs but all this came at a cost.

6502 - 3500 transistors
6800 - 4100 transistors
Z80 - 8500 transistors
6809 - 9000 transistors
8086/8088 - 29000 transistors
ARM2 - 30000 transistors
68000 - 68000 transistors

Transistor cost started dropping as Moore's Law kicked in but the chip needed to be popular enough to mass produce in order to benefit. Other 8 bit CPU designs were earlier than the 6809 and had become more popular and 16 and 32 bit CPUs were coming to market and more in demand. Cheap systems likely used the cheap old processors while systems which needed the performance likely went with newer 16 bit and 32 bit CPUs. That didn't leave much for a late to market 8 bit CPU no matter how nice it was. Obviously a few developers like your father used the 6809 and came to respect it though.

Last edited by matthey on 07-May-2021 at 05:56 PM.

megol Quote:

To see how important it really is for mainstream computing Itanium and x86 are good examples: for Itanium which wastes many bytes in a normal, optimal(!), instruction stream the bad density wasn't a problem. For x86 it's so important that compilers and operating systems doesn't care about adding waste bytes - it's not important.

The Itanic wasted caches and was one of the most costly failures ever in processor design so it is a good example?

How about the case of the PPC 603? It had 8kiB ICache and 8kiB DCache the same as the 68060 and Pentium yet fell on it's face in performance. It couldn't outperform the 68060 despite using a smaller die size. Apple Macs using it were considered the worst Macs ever and it forever tarnished PPC's reputation on the desktop. The PPC 603e was quickly introduced with double the cache sizes and yet another die shrink but now used more transistors than the 68060 despite having only a 4 stage pipeline compared to the 68060 8 stage pipeline. PPC had a reputation for not clocking up do to the shallow pipeline designs so clocked up with die shrinks instead. It's funny how many PPC users accuse Intel of die shrinks to get ahead but PPC was actually ahead of the game at one point only sabotaged by the shallow pipeline designs.

megol Quote:

And of course we can add the argument that 68k most likely would have moved in the same direction as x86 to optimize performance like aligning critical loops to cache line boundaries to maximize decode throughput. This and several other standards is part of what makes modern x86 binaries code density bad.

Natural alignment of data has performance benefits for all members of the 68000 family. The 68020+ benefits from aligning branch targets to 4 byte alignment and likely to cache boundaries in some cases. 68k designs have usually done a good job of minimizing misalignment penalties which is good for code density. There are some major differences between the 68k and x86-64.

1. code is always 2 byte aligned on the 68k which helps with cache alignment, instruction fetch alignment and branch target efficiency
2. adding instructions on x86-64 makes code density worse as instructions are longer while the 68k can improve code density by adding instructions (x86-64 has 256 base encodings while 68k has 65536)
3. x86-64 is still optimized for stack usage and byte sizes which are not used much in code optimized for performance so longer instructions which enlarge code are used instead; the 68k is optimized for general purpose use and code density does not drop as much when optimizing for performance and performance doesn't suffer as much when optimizing for size
4. decoding is simpler on the 68k so instructions don't need to be broken down as far saving energy and micro-op caches which may benefit from increased code alignment are more likely to be avoidable

megol Quote:

We have so much memory that operating systems and programs can waste it without problem, caches are large enough that density doesn't improve performance etc. etc.

The larger the cache the slower it is which is why we have multi-level caches. According to RISC-V research, every 25%-30% improvement in code density is like doubling the ICache size. Do you think there is no difference in performance between having code in the L1 vs retrieving it from L2 or memory if there is no L2 as is the case in some embedded systems? Do you think the 68060 having an instruction cache that was the rough equivalent of 4 times the size of the PPC603 made a difference in the 68060 outperforming the 603? Do you think it is cost effective to add "so much memory" to embedded systems? Do you have maxed out memory on all your computers so you can "waste it without problem"?

Fl@sh Quote:

All this to reach the goal to produce less complex cpus, with less transistors and an easy way to choose/manage instructions by compilers.

Most transistors of high performance CPUs are for the caches. It sounds like you need an older computer that didn't waste all those transistors on caches.

Fl@sh Quote:

My hope is to get less but at best of possibilities.

Simpler instructions means more instructions need to be executed to keep pace with cores which execute more powerful instructions. The RISC solution was to clock up the core to execute simple instructions faster but this causes more heat. More simple instructions bloats code which creates an instruction fetch bottleneck and wastes caches. Larger caches, wider instruction fetch and OoO can be added to RISC to take care of the problem but this is more complex and generates more heat. Simple RISC cores can be tiny and low power but when turning up the performance they are no longer simple or low power.

Fl@sh Quote:

PowerPC has three addressing modes and full orthogonality, it was future proof for 32bit->64bit change, it had SIMD units from start and it's ISA can be easily expanded. For me PowerPc project was much better than any 68k, x86-64 or ARM ISA.

PPC didn't get an SIMD unit until the G4 which isn't even early and it is far from standard as many PPC CPUs don't have it including some used in AmigaOnes.

Fl@sh Quote:

Today IBM is developing POWER (mostly back compatible with old PowerPC ISA) and it's features are, at least for me, the most impressive among others (Power 10). IBM POWER cpus are currently developed mainly for supercomputers/high end servers, but if we are discussing in theory "how should be a good CPU" this technology can't be excluded from discussion.

The first POWER processor design used a simple "pure RISC" philosophy but the newest POWER processor is more complex than any 68k processor ever was and competes with modern x86-64 processors as one of the most complex ever.

@matthey Quote:

matthey wrote: cdimauro Quote: Unfortunately and incredibly the 6800 family wasn't considered by Dr. Weaver, so there's no data. It's quite strange, because it was one of most used microprocessor in the embedded world. The 6800 was one of the most popular processors until the 6502 completely overshadowed it. The 6502 is estimated to have shipped 5 to 10 billion units and hundreds of millions of units are still shipped annually for embedded use. https://www.westerndesigncenter.com/wdc/ It's hard to believe that CBM owned MOS and employed Chuck Peddle yet had such incompetent management. The 6502 family was used everywhere anyway due to the low cost. Apple II Atari 2600, 8 bit family, Lynx BBC Micro CBM Pet, C64 NES What was the 6800 used in? Nothing memorable. It did make some what of a comeback with the nice but expensive 6809 in 1978. The 68000 was launched in 1979 which was quite a bit more powerful and expensive but the price had dropped to about $15 by 1984 due to mass production which was cheaper than the 6809 had been in the early 1980s.

I don't know how much processors from the 6800 family were sold, because I've found no numbers. Certainly the 6502 took most of the market because of its very low price.
Quote:

The following document, "Classifying Instruction Set Architectures", mentions the 6809 as an example of an accumulator architecture on the first page of the pdf. http://cs.uccs.edu/~cs520/S99ch2.PDF

I see. But the problem with the 6800 is that it has two 8-bit accumulators.
Quote:

It later does some code size comparisons using accumulator code on page 5. This example uses multiply which the 6809 had and is unusual in early 8 bit processors but it also shows a divide instruction so this is maybe a hypothetical accumulator architecture that may resemble the 6809? In any case, hardware multiply and divide make a difference in code density as the code wouldn't fit on one page without them. There is a comparison of the different architectures on page 9. The accumulator architecture used had better code density than the load/store architecture (MIPS) which had the worst code density.

I've no time now to make a code example using 68HC12's instruction set, and I don't know if it makes sense, because the example has no constraints: there's no size defined for the data, so 8 or 16-bit can be used, which gives very different results on a such processor.

Anyway, this comparisons is too simple to make a general statement about different computer architecture families.
I also don't like the fact that it reports only some bits for the instructions instead of the full size. For example, the instructions size for 68020 is 28 bytes = 224 bits, and for VAX is 24 bytes = 192 bits.
Quote:

Quote: cdimauro [quote] 68000 has only very limited memory-memory support, with a few instructions allowing memory reference for both source and destination. Move memory to memory is common though. move mem,mem + smaller code + fewer instructions + fewer registers used + sometimes saved cycles - larger instructions A dual ported data cache would likely be necessary to see the full performance advantage on a superscalar core. The 68060 did not have much of a performance advantage other than the smaller code and reduced register usage.

Indeed, but move was the only memory-memory instruction that allowed to use any addressing mode. The few others are very limited.

BTW the 68HC12 had general purpose memory-memory move instruction, like the 68K.
Quote:

Quote: cdimauro [quote] That's why the embedded world is abandoning the 8 and 16-bit families: 32-bit ones became cheaper to produce, and with much less constraints. So, it's also easier to develop. Combined with a good code density, they are the most favorite. Yes, an 8 bit core is a pain to develop for. Only 256 bytes can be addressed without bank switching and any kind of OS is very difficult.

Usually 8-bit cores allow to access 64KB of memory.
Quote:

Quote: cdimauro [quote] Only starting from the Pi 2 the Raspberry have a 64-bit architecture. But this platform isn't selling a lot: only a few millions, compared to a market of billions of devices. Raspberry Pi units sold looks pretty healthy to me. I could overlay the AmigaOS 4 hardware units sold but just use the bottom horizontal line to represent their units sold.

LOL However the RPi are selling some millions, whereas the embedded market is much larger.
Quote:

The Raspberry Pi, Pi Zero and Pi Pico have 32 bit cores while the the Raspberry Pi 2, 3 and 4 have 64 bit cores. Raspberry Pi Foundation has started making their own custom SoC with ARM M0+ 32 bit cores (partial Thumb 1 and 2 support) for the $4 U.S. Pi Pico so 32 bit is still alive by choice. The Pi Pico has 264 kiB of SRAM and 2MiB of flash. A command line only RISC OS Pico runs on it but the full RISC OS needs 4 MiB of flash memory (ROM). The Amiga 1000 had a preemptive multitasking AmigaOS with GUI using 256 kiB of memory and 256 kiB of WCS/ROM. Amiga Nowhere is only going big fat and expensive today though.

Also without modern features. But this is another argument (and not so much interesting for the embedded market).
Quote:

Quote: cdimauro [quote] Absolutely agree. The problem is: who'll do it to address the embedded market (AKA large volumes)? Someone that needs it should do it. I didn't have any trouble finding embedded players interested in the 68k and needing enough volume to make ASICs. It would require professional development but I had a chip architect in mind at one point (*not* Gunnar and much better reputation). It would require some investment but I've talked to people about investing. Gunnar wasn't interested but he's oblivious, especially when it comes to business. Everyone has different needs and expectations which makes it difficult to put together but maybe I would try again someday with favorable conditions.

Do you "only" need a chip architect = HDL/RTL expert?

@simplex Quote:

simplex wrote: My father once said that the 68060 proved that a well-designed CISC could outperform RISC. He's an embedded engineer who thinks Motorola made a mistake with the 68K; he's a huge fan of the 6809 & thinks they should have continued in that direction. I'd be interested in what you guys think of that. I can provide an extended quote on his explanation of the latter if it would help explain what he means.

Yes, please: sounds interesting.

@ppcamiga1 Quote:

ppcamiga1 wrote: @matthey Quote: I believe the 68k is more alive than PPC. 68k speed is still as it was in 1995. ppc is faster and easier to get. So, ppc is more alive than 68k. Even if You don't like this.

So if for you alive = speed matters, then both PPC and 68K are equally dead nowadays...

@matthey Quote:

matthey wrote: simplex Quote: My father once said that the 68060 proved that a well-designed CISC could outperform RISC. He's an embedded engineer who thinks Motorola made a mistake with the 68K; he's a huge fan of the 6809 & thinks they should have continued in that direction. I'd be interested in what you guys think of that. I can provide an extended quote on his explanation of the latter if it would help explain what he means. Indeed. The 68060 (1994) outperformed most of the processors of the day in PPA (Power, Performance, Area) including the Pentium P54C (1994) and PPC 601 (1993). 68060 2.5 million transistors (8 stage in order, 8kiB ICache 8kiB DCache) Pentium P54C 3.3 million transistors (5 stage in order, 8kiB ICache 8kiB DCache) PPC 601 2.8 million transistors, (4 stage OoO, 32kiB unified cache) 68060@75MHz 3.3V, 0.6um, 2.5 million transistors, ~5.5W max Pentium@75MHz 80502, 3.3V, 0.6um, 3.2 million transistors, 9.5W max PPC 601@75MHz 3.3V, 0.6um, 2.8 million transistors, ~7.5W max Performance was close between these 3 processors but the 68060 is easily the leader when comparing power and area.

We already discussed it sometimes, so I quickly report my opinion here: not a fair comparison with the Pentium, which has 64-bit data bus, no 4-bytes limits when fetching instructions, a fully pipelined FPU, all instructions & features of previous processors, and new instructions. All of this takes silicon and consumes energy.

But what I'd like to know is SPEC results for the above processors.
Quote:

I guess back then they didn't do PPA analysis like is done for embedded systems today. Neither did Motorola clock up the 68060 much despite the deeper pipeline making it the best candidate of the 3 CPUs above. It's pretty clear that the switch to PPC was a upper level management decision and the 68060 was not to compete with the PPC, especially on the desktop. Despite the low clock speed, the 68060 was still a success in the embedded market where high clock speeds are less desirable because of increased power usage and the need for more cooling.

From this PoV I still don't understand why Motorola decided to kill its most loved (and used, after x86) architecture...
Quote:

6502 - 3500 transistors 6800 - 4100 transistors Z80 - 8500 transistors 6809 - 9000 transistors 8086 - 20000 transistors ARM2 - 30000 transistors 8088 - 40000 transistors 68000 - 68000 transistors

Nice table. However there might be an error: 40000 transistors for the 8088 look too many. BTW and AFAIR ARM1 used 25000 transistors.

P.S. Sorry, no time today to reply to other comments.

@cdimauro

Quote:

Quote: (My father)'s an embedded engineer who thinks Motorola made a mistake with the 68K; he's a huge fan of the 6809 & thinks they should have continued in that direction. I'd be interested in what you guys think of that. I can provide an extended quote on his explanation of the latter if it would help explain what he means. Yes, please: sounds interesting.

OK, here's what he wrote 3 years ago when I asked him about this.Quote:

It took Intel several years to catch up with the 6809. It also irritated me no end when Motorola built a new, inferior design rather than expanding the 6809. ...Indeed it was the 68K. Rather than expand the elegant 8/16-bit architecture to 16 and/or 32 bits, they cobbled together a (to me) haphazard collection of special and general purpose registers with a (to me) haphazard instruction set, and dumped the elegant software interrupt with its inherent safety features. Yes, it was much inferior.

To be honest, at this point I wondered if he was misremembering Motorola's products, but be spent decades doing this and I'm at best a software guy, so I dropped the subject.

Last edited by simplex on 07-May-2021 at 04:16 PM.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

cdimauro Quote:

I see. But the problem with the 6800 is that it has two 8-bit accumulators.

True. One of the 6502 simplification was to remove one of the acculators.

cdimauro Quote:

I've no time now to make a code example using 68HC12's instruction set, and I don't know if it makes sense, because the example has no constraints: there's no size defined for the data, so 8 or 16-bit can be used, which gives very different results on a such processor.

The pdf page 3 says, "Assume all six variables are 4-bytes integers." This would mean the accumulator architecture would be 32 bits with hardware multiply and division. It certainly looks like a hypothetical ISA. Maybe the example should have used the default integer size as used by C of the architecture.

cdimauro Quote:

Anyway, this comparisons is too simple to make a general statement about different computer architecture families. I also don't like the fact that it reports only some bits for the instructions instead of the full size. For example, the instructions size for 68020 is 28 bytes = 224 bits, and for VAX is 24 bytes = 192 bits.

I agree. The code size calculations are strange. It also takes away from the memory traffic calculation which includes instruction and data traffic. The architecture comparison idea was good but it has some flaws. VAX code density is good and sometimes beats the 68k. It would be interesting to see what a modern micro-op OoO VAX CPU would look like.

cdimauro Quote:

LOL However the RPi are selling some millions, whereas the embedded market is much larger.

Sure, it is just a small piece of the big embedded market pie. It is impressive that a little hobbyist board took substantial embedded market share and created what has likely become the most popular embedded form factor standard by introducing cheap hardware. Another hobbyist board form factor based on the Arduino (project started in Italy) was the previous most popular embedded form factor and the clear target of the new Raspberry Pi Pico (with new Raspberry Pi Foundation custom SoC) which you seem to think is primitive (it is but that is not the point). I expect the board to take market share from Arduino as the price is a fraction of that of the Arduino. The Raspberry Pi Foundation management is really smart. Why can't the Amiga have management like that?

cdimauro Quote:

Do you "only" need a chip architect = HDL/RTL expert?

HDL proficiency is not enough. Someone with processor design understanding and experience is needed. The chief architect is not the place to be cheap. The right person would give instant credibility to such a project.

cdimauro Quote:

Nice table. However there might be an error: 40000 transistors for the 8088 look too many. BTW and AFAIR ARM1 used 25000 transistors.

You are correct.

6502 - 3500 transistors
6800 - 4100 transistors
Z80 - 8500 transistors
6809 - 9000 transistors
8086/8088 - 29000 transistors
ARM2 - 30000 transistors
68000 - 68000 transistors

8088 has the same transistors as the 8086 (kind of like the 68008 is to the 68000). The narrower data bus allows for simpler embedded boards and cheaper memory. Of course the 8088 is famous for being used in the IBM PC model 5150. I listed popular processors. ARM1 was never used as a primary processor. ARM2 was the CPU of the successful Acorn Archimedes A3000 introduced in 1987. ARM2 added hardware multiply but lacked other nice features like hardware division, misaligned memory access support and caches despite the late introduction date (68030 was also released in 1987). Theoretical maximum performance was quite high but difficult to obtain.

Last edited by matthey on 08-May-2021 at 05:14 AM.

simplex Quote:

OK, here's what he wrote 3 years ago when I asked him about this.Quote: It took Intel several years to catch up with the 6809. It also irritated me no end when Motorola built a new, inferior design rather than expanding the 6809. ...Indeed it was the 68K. Rather than expand the elegant 8/16-bit architecture to 16 and/or 32 bits, they cobbled together a (to me) haphazard collection of special and general purpose registers with a (to me) haphazard instruction set, and dumped the elegant software interrupt with its inherent safety features. Yes, it was much inferior. To be honest, at this point I wondered if he was misremembering Motorola's products, but be spent decades doing this and I'm at best a software guy, so I dropped the subject.

It sounds like your father knows what he is talking about. The 6809 was already practically an 8/16 bit CPU and a good design so it looks like it would be natural to enhance it to a full 16 bit design.

The 68000 address data register split is unusual but all 16 registers are usually considered to be general purpose. Some programmer's first impressions are that they don't like it but it actually works out pretty well and is one of the keys to the 68k's good code density. The reg-mem architecture with so many GP registers and addressing modes is more powerful than most accumulator architectures and supports compiler use better. I don't see any problem with the instruction set until the 68020 ISA which had some highly questionable additions and many of the encodings were added in a haphazard way. The 68000 ISA was great but the 68000 CPU design was not. The 68000 was designed to be quick to market, had mediocre performance as a result and there were mistakes. The 68000 could not recover from a failed memory access (address or bus error) because it did not include enough processor state data to resume the faulted instruction. This prevented the use of virtual memory where the 68000 was being used by workstations (some used dual 68000 processors as a workaround). The 68010 fixed this problem. Your father has some legitimate but possibly exaggerated gripes about the 68k likely do to bias against it for replacing the 6809.