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?

Ghazan Haider wrote:
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?

On 2004-09-30, Jim Stewart <jstewart@jkmicro.com> wrote:

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,
visi.com wrinkles, pimples!!

Grant Edwards wrote:
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.

On 30 Sep 2004 22:13:30 GMT, Grant Edwards <grante@visi.com> wrote:

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.

On 2004-09-30, Jim Stewart <jstewart@jkmicro.com> wrote:

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...
visi.com

On 2004-09-30, Dave Hansen <iddw@hotmail.com> wrote:

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!!
visi.com

On 30 Sep, in article
<415c850a$0$6022$a1866201@newsreader.visi.com>
grante@visi.com "Grant Edwards" wrote:
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
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate

Ghazan Haider wrote:

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

Grant Edwards wrote:
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 <http://www.linet-network.com>, and
get the controller data sheet (lic04.pdf).

Tauno Voipio
tauno voipio (at) iki fi

"Grant Edwards" <grante@visi.com> wrote in message
news:415c92c5$0$8155$a1866201@newsreader.visi.com. ..
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.

On Fri, 1 Oct 2004 09:03:56 +0200, "David Brown" <david@no.westcontrol.spam.com>
wrote:

See:
http://www.nd.edu/~milind/arch/pc.design

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

Ghazan Haider <ghazan.haider@gmail.com> wrote:
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.

On 2004-10-01, David Brown <david@no.westcontrol.spam.com> wrote:

Exactly. compared to things like the Z8K family, the 68K
family, the NS 32K family, and the AT&T 16<whatever> 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.
visi.com

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.

The IBM PC used an 8088, not an 8086.

-->Neil

Neil Bradley wrote: (*** and omitted attributions ***)
That affects nothing except the external buss width.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

How many x86 MIPS do you get for $5 ;-)


--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

"David Brown" <david@no.westcontrol.spam.com> skrev i meddelandet
news:cjiups$e4d$1@news.netpower.no...
I think one of the main reasons why the x86 was selected was the presence of
the 8088
with an 8 bit bus. The MC68008 was late to market, as was the NS32008.
It is a REAL pity that last one was not available in time...




--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

Ghazan Haider wrote:
The Intel 4004 is best for all purposes, projects, pricing and
performance goals.

You're welcome.

Ed