Re: Does 32 bitter code pack less efficiently than 16 bitters?
- From: D Yuniskis <not.going.to.be@xxxxxxxx>
- Date: Wed, 25 Aug 2010 09:06:29 -0700
Hi John,
John Speth wrote:
What is the real world comparison of 16 bit vs. 32 bit code footprint among popular professional grade MCU cores and tools?
Thanks in advance for your discussion.
As you would expect, there is no "real" comparison to be
made, here. The problem lies in deciding "what's an apple"
(let alone, an "orange"!)
What you have to look at is how long *instructions* are,
not the "size" of the processor. E.g., if every instruction
for the "32 bit" processor is exactly one "(32b) word" but
the "16b CPU" often needs two or three "(16b) words", then
the average instruction in the 16b case is longer.
[Of course, "average" can be defined a lot of ways!]
You can **naively** try to get an idea for the relative
efficiencies of various architectures by cross-compiling a
"large-ish" project for each and looking at the sizes of
the resulting (stripped) binaries.
But, this is truly a naive approach because it assumes:
- you have compilers for each architecture
- the compilers are "equally good" at code generation
- there are no variations in data types, etc. across
platforms (e.g., 32b ints in one, 16b ints in the other)
etc.
However, a more insidious issue regards how well the
"application" *fits* the particular implementation (CPU).
E.g., if you are dealing with IP addresses, then the
ability to handle 32b values economically can give
preference to a 32b architecture. OTOH, if you are
processing strings or other small data types, the
overhead that comes with a 32b CPU may represent a
lot of waste.
In "the real world" (per your query), you fit the
implementation to the application (C.A.E typically
having less "spare resources" than the desktop world).
Or, modify the application to fit the implementation
available (!).
In my own *personal* experience, I have found 16b
implementations tend to use 40-50% more "resources"
than "equivalent" 8b implementations. The same sort
of ratio (ballpark) applies to 16b vs 32b.
BUT, THIS IS JUST A ROUGH GUIDELINE. I use it to
gauge the approximate cost of moving up/down the
"wideness" hierarchy (or should that be "left/right"?)
when a project looks like it may straddle a particular
"decision point" (e.g., something that taxes the
abilities of a 16b -- but would underutilize those of
a 32b, etc.).
In actuality, once the decision is made to cross such a
threshold, the scope of a project is often adjusted,
accordingly. E.g., adding features/capabilities if
moving upwards; removing/reducing if moving downwards.
(i.e., so the resulting implementation better *fits*
the resources available).
If you are *lucky*, you'll find yourself right smack in the
"center" of a particular technology's capabilities and
won't be faced with this choice: "This is what we *need*.
Anything less won't work; anything more is waste"
.
- References:
- Does 32 bitter code pack less efficiently than 16 bitters?
- From: John Speth
- Does 32 bitter code pack less efficiently than 16 bitters?
- Prev by Date: Re: Any ideas for an embedded renewable/energy project?
- Next by Date: Marking engines
- Previous by thread: Re: Does 32 bitter code pack less efficiently than 16 bitters?
- Next by thread: Need datasheet for Qualcomm MSM8660
- Index(es):
Relevant Pages
|
