CPU comparisons sought

We all know and agree that x86 is crap. For embedded designs and otherwise, we have many options on which CPU to use, and the associated MCUs, boards and systems built on those architectures.

So which CPU is best?

ARM is real tiny and efficient. Awesome for embedded stuff. For sheer power, we'll have to resort to Athlons for the price. Ultrasparcs and POWERs are harder to compare, Ultrasparcs have better bandwidth and floating performance, but I havent seen embedded versions beyond the Ultrasparc IIe in some netras. POWERs have many versions in embedded applications. Ive always seen them as desktop-oriented CPUs too big compared to the ARM, but recently saw some tiny chips with power that impressed me.

The 68000 is old and bad, almost as bad as the x86. But newer versions arent too shabby like the 683xx, Dragonball etc.

Is there any source out there that compares these CPU cores for efficiency, and relative strengths as well as say pipelines, bandwidth, floating performance and so on? Everyone is jumping on the ARM bandwagon, but I'd like to have a set of CPU archs under my belt ready for the job. Is there an UNBIASED source of info out there?

Reply to
Ghazan Haider
Loading thread data ...

No we don't. Lots and lots of embedded x86 out there happily running. Lots of developers happy to develop with it. Lots of companies happily making money selling x86 solutions.

For embedded designs and

What do you mean by tiny and efficient? I've studied the ARM instruction set in-depth and I'm convinced I could code up just about anything in less bytes in x86 than in ARM assembly.

I'll give you that there are some very cute ARM chips out there, but I've not been that impressed with the efficiency of the ARM instruction set.

Why would you want an UNBIASED source since you are so clearly biased against x86?

Reply to
Jim Stewart

By efficient, I assume he means throughput per unit power. MIP/W if you will. The ARM implimentations I've see are a couple orders of magnitude more power-efficient than Intel or AMD x86 implimentations.

ARM thumb mode isn't bad if you're worried about program size.

Ah, c'mon, the 8086 architecture was a lousy mess in 1980 and it's just a bigger, lousy mess today.

--
Grant Edwards                   grante             Yow!  Nipples, dimples,
                                  at               knuckles, NICKLES,
 Click to see the full signature
Reply to
Grant Edwards

If you mean "the 8086 has a different addressing mode for every instruction", well, then yes, I'd laugh and say you're pretty much right.

But a big, lousy mess, no. The compilers and assemblers have been sufficiently beaten that they produce good code.

The "lousyness" of a particular processor should be measured by it's overall fit for a given application, not by it's architectural beauty.

Reply to
Jim Stewart

[...re: claim that x86 is a mess...]

The x86 is "great" for the same reason the PIC and the 8051 are "great." It's widely used, well-supported, and there's a large base of programmers who know how to use it well enough to do something useful with it. Despite whatever other shortcomings the architecture may have.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

That, a severe lack of general-purpose registers, plus the whole segmented address space debacle. It was an architectural nightmare compared to the 68000 family.

We're discussing CPUs.

Right. IMO, the 8086 was a very bad fit for a desktop computer, a bad fit for all embedded applications I've seen, and the x86 family continues to be a bad fit for just about everything it's used for.

--
Grant Edwards                   grante             Yow!  .. I see TOILET
                                  at               SEATS...
 Click to see the full signature
Reply to
Grant Edwards

Very true. Though I have to say that when I first used the

8051 (1983) it was pretty good compared to the competition. IMO, that wasn't true about the 8086

Of which there are plenty.. ;)

--
Grant Edwards                   grante             Yow!  Fold, fold,
                                  at               FOLD!! FOLDING many items!!
 Click to see the full signature
Reply to
Grant Edwards

......

Ah, c'mon they are used in so many places by nearly everybody so they must be the panacea for everything, including sliced bread..

Just like millions of landmines are used throughout the world so they must also be good for everything.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

If you mean that given the benefit of 20 years of hindsight, and a clean sheet of paper, then yes. If you mean should not be used in new designs, then no.

AMD have just released more in their Geode family, and their latest Mobile Athlon sounds like a good step toward embedded use. x86 Motherboards keep shrinking, and are low cost.

In the Single Chip Microcontroller space, I know of no x86 variants with on-chip Flash, so that comparison is simplified.

Easy => The best CPU is one that :

** You can get mature tools for, & develop easily with ** You can still buy when you need it ** Can comfortably run the last software revision before the product is frozen / obsoleted.

but if you like to agonise over the finer details, or bragging rights, try a google for Embedded Microprocessor Benchmark.

-jg

Reply to
Jim Granville

I was faced with the problem of replacing an Intel 80186 with something more modern. After considerable tries (including Motorola 68332), the selection is ARM, the Atmel AT91 series.

I have practical experience of porting an Intel 80186 application into ARM/Thumb. I guessed that the ARM code would be some 50% longer than the 80186 code, but the esults show that the length was practically equal. The original 80x186 code was 40032 bytes, and the ARM/Thumb code was 40096 bytes.

The code was written mostly in C, except for processor start-up and multithread kernel switcher. For 80186, the compiler was Borland C with Paradigm Locate to produce the ROM image. For ARM/Thumb the compiler was GCC 2.95. The current GNU compiler, GCC 3.x produces still somewhat better code.

For a picture of the card, see , and get the controller data sheet (lic04.pdf).

Tauno Voipio tauno voipio (at) iki fi

Reply to
Tauno Voipio

If I remember my history correctly, it was generally agreed at the time of the first IBM PC that the 8086 was a dead-ender - it was a rotten architecture, overly complex, register-starved and inefficient, and with no sensible future expansion path. The technical guys at IBM all wanted to use the 68000 (why the o/p referred to the 68000 as "old and bad" is beyond me - "old", yes, but the "bad" sounds like it comes from someone who has never seen the 68000 architecture), but some PHB decided to choose the 8086 as it was cheaper. At the time, IBM thought of the PC as an experiment which would only sell in small numbers - it did not matter if there was no future in the architecture chosen, since there were not going to be any compatibility issues with this one-off marketing experiment.

The modern x86 line (at least, on the AMD side :-) is a brilliant example of a terrible design with an excellent implementation - after a *lot* of time and money.

Reply to
David Brown

See:

formatting link

Where the architect and design team leader for the IBM PC project, Lewis Eggebrecht, writes in part:

"There were four major concerns with the 68000. First, because it was a true 16-bit data and 24-bit address device, it would require a more expensive system board design, including more bus buffer chips and TTL glue chips, larger expansion slot connectors, and a more complex circuit board design (more layers). Second, the 16-bit bus required twice the memory chips (ROM and RAM) for a minimum system implementation; the minimum memory size and memory increments would always be twice the size and cost of an 8-bit bus. Third, benchmark analysis of the 68000 indicated a performance edge over the 8086, but it was not as memory efficient as the 8086 architecture, making a small-system implementation less competitive. Fourth, the 68000 lacked companion peripheral and support chips comparable to what was provided by Intel and third-party vendors for the Intel bus compatible microprocessors.

"The most damaging concern with the 68000 was its lack of software support, including development tools, languages, operating system, and applications. This was also somewhat true of the 8088/8086 processors. Intel, however, provided a migration strategy from the

8080 architecture and software to the 8086 architecture. The 8086 preserved the 8080 register architecture and condition codes and provided a software utility that converted 8080-based code to 8086 code. This provided the opportunity to convert the existing the 8080 software base to the 8086, and in actuality, most initial PC software was converted 8080 software.

"A number of other circumstances affected the decision to use the 8088. The PC design is often viewed as IBM's first encounter with Intel, but IBM had an ongoing relationship with Intel. IBM was using Intel processors in a number of products prior to the PC design. The 8080 was used as a communications controller in the IBM 5100 portable computer, the 8086 was used in the IBM Display writer, the 8085 was used in the 5250 terminals for the System 3X mainframes and the IBM Data Master, and the 8048 was used in IBM keyboards. Thus, IBM had extensive experience with Intel and Intel technology. To be used in IBM products, Intel parts had to pass IBM's quality standards and tests. Another strong motivation was Intel's capability to offer a kit price for the majority of the PC chip set.

"In summary, the 8088 was selected because it allowed the lowest cost implementation of an architecture that provided a migration path to a larger address space and higher performance implementations. Because it was a unique choice relative to competitive system implementations, IBM could be viewed as a leader rather than a follower. It had a feasible software migration path that allowed access to the large base of existing 8080 software. The 8088 was a comfortable solution for IBM. Was it the best processor architecture available at the time? Probably not, but history seems to have been kind to this decision."

Jon

Reply to
Jonathan Kirwan

We all know and agree that this question is crap.

Pardon the French, but it's essentially as simple as that. No CPU is best, for the question asked like that. A given CPU can be best for a very precisely specified application (and if none is, the best is quite certainly the one that you have designed and tailored specially for that application), but *no* CPU is "best" for all tasks.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Exactly. compared to things like the Z8K family, the 68K family, the NS 32K family, and the AT&T 16 the 8086 was a poorly told joke. It was just a 16-bit wide version of the 8080 (which had been obsolete for years).

IIRC, there were availability issues with the 68K that made it a riskier choice (from a manufacturing POV). IBM also didn't really like to deal with outside companies (I was shocked they didn't use one of their internal uP designs). Motorola was too big to buy a significant chuck of. Intel wasn't.

The modern implimentations are still awful when it comes to power consumption.

--
Grant Edwards                   grante             Yow!  It's OKAY --- I'm an
                                  at               INTELLECTUAL, too.
 Click to see the full signature
Reply to
Grant Edwards

Right. I understand the codebase value, and will consider the x86 for that reason, and its pervasiveness. However, the original question was about the capabilities of the CPU core.

The geode, and ATPC etc, have been interesting for me, but the wattage is too high and performance crap. If I'm not tied to the code base, I just couldnt find another reason to use these chips. Its all made worse by the fact that there are no 32-bit-only x86 out there, and the

16-bit baggage in there is lots.

The BIOS setup to make it PC compatible is also a pain, the bios also takes a lotta space. Perhaps linux can be booted via boot-block only, not sure.

These are the market points to consider when choosing a CPU. I have a better understanding of these points than the merits of the CPU core itself. Some chips have similar market share, code base, so the decision will depend on the core. spec.org is nice in comparing desktops based on those cores.. but its hard to carry that into modern embedded chip, for example the SH11 is not included.

Will try. thanks.

Reply to
Ghazan Haider

The Intel 4004 is best for all purposes, projects, pricing and performance goals.

You're welcome.

Ed

Reply to
Ed Beroset

Availability is getting a bit thin...

--
Grant Edwards                   grante             Yow!  Did I say I was a
                                  at               sardine? Or a bus???
 Click to see the full signature
Reply to
Grant Edwards

Perhaps, but that's probably not a consideration for someone who asks "Which CPU is best?"

Ed

Reply to
Ed Beroset

:)

One of the projects I worked on in 1984/5 was designing a new generation of a PBX-like product. We were planning on replacing the currently-shipping 4004-based product line with someting that used the then-brand-spanking new 8051. IIRC, the

4004 was only available on the secondary market back then. 8751's with 4K of UV-EPROM were something like $200-$300 each.
--
Grant Edwards                   grante             Yow!  Someone in DAYTON,
                                  at               Ohio is selling USED
 Click to see the full signature
Reply to
Grant Edwards

Seems you can still buy them, (for the price of a high end Pentium :) see comments at

formatting link
and you can use Alred Arnold's AS to assemble code, and there are even ones still running !

-jg

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.