是PowerPC还是ColdFire?

larrylin

如题。

larrylin

1# larrylin
转一个经典的关于ARM，ColdFire，POWERPC的讨论原贴是comp.arch.embedded上的一个讨论，英文不好的要费点劲：


Didi wrote:
I want to upgrade from 8 bit to 32 bit microcontrollers.
Which is the best platform to invest on?

回复：
The real choice you should be considering is Power PC vs. the
rest.
Years ago I had to switch from CPU32 to something newer and
I considered the Coldfire, V4 was on its way to become soon
available.
Can you clarify what CPU32 is ?
-jg

larrylin

2# larrylin

接着回复：
Sure, Jim, perhaps I should have done so at the beginning.
CPU32 is the processor core found in the 683xx products of
Motorola (now Freescale); most basically, it is a 68020 minus
the bitfield instructions and perhaps some other things (I think
they never had the coprocessor interface implemented although
the related instructions do trap properly for emulation etc., all that
by memory - I wrote the FPU emulation stuff about 10 years ago...).

Dimiter

larrylin

3# larrylin

The CPU32 also has a couple of additions compared to the 68020, such as a fast loop mode, and a bit more optimised division (the 68020 has a large hardware division unit - the CPU32 uses a microcode software loop, which turns out to be faster!). But basically it's the core used in most of Freescale/Motorola's 68k microcontrollers.

The ColdFire core is basically a completely new implementation of the same CPU32 instruction set and programmer's model. They dropped a few of the more expensive (in terms of hardware) addressing modes and opcodes, and produced a new implementation that is very much more efficient (in terms of power, space, and work per clock cycle). Later ColdFire cores have added functionality (including some of the instructions originally dropped).

mvh.,

David

larrylin

4# larrylin

Okay, I'll bite. What is "fast loop mode"? I know what loop mode,
introduced on the 68010, is.


~Dave~

4# larrylin

It's a mode when you have a single-word instruction followed by a DBcc instruction in a tight loop, such as generated by the code:
unsigned short int n = 1000;
while (n--) { *p++ = *q++; }

Of course, it could well be that the 68010 has this mode - the CPU32 manual isn't very clear on which features are new compared to the 68000, or compared to the 68020 (the 68010 was not much used, was it?)

According to the CPU32 manual (I've got it open at the moment anyway), the extra features of the CPU32 include low-power modes, and table lookup and interpolate instructions. Missing instructions include the bit-field instructions, compare-and-set, coprocessor control, and BCD instructions.

I don't remember (perhaps I never knew) what it was on the 010, but I
do remember the loop mode on the CPU32 - it is when you use
the dbcc instruction with an offset of $fffc (-4), so the loop repeats
a single single-word opcode. The CPU stops fetching, does just
the data accesses (CPU32 has no cache memory).
I have used it here and there, I remember using it in an LZW compress
(the inner-most search loop); while it yielded a noticeable
improvement, the same code ran times more efficiently on the
PPC - just sligthly modified to take advantage of the ctr register.

Was loop mode the same on the 010?

Dimiter

4# larrylin

Yes. If you do just an instruction trace on a logic analyzer, the
processor appears to have entered a black hole for some period of time,
then it "escapes" and resumes normal execution. Makes for an interesting
trace for a junior engineer to explain. ;-)

larrylin

5# larrylin

Yup the 68010 operates in a similar manner. It looks like the CPU stops
fetching the opcodes but continues to test for the loop termination
condition. Well this is what I got from Motorola's docs (they print 'em
and send em to you for free if you didnt know already).

-Isaac


--------------------------

Hey, I knew that :-). But last time I considered the 68010 was during
the 80-s...
Whatever literature I have needed from Motorola I have
received it - except for things they want to keep secret (like the
JTAG based debug port data, they did not give them to me while I had
an active NDA, it is for much narrower circles...).

Dimiter


--------------

The real choice you should be considering is Power PC vs. the
rest.
Years ago I had to switch from CPU32 to something newer and
I considered the Coldfire, V4 was on its way to become soon
available.
All my code (between 10 and 15 megabytes of source text at that time,
IIRC) was written in CPU32 assembly (with many environmental
extensions) and it looked like the Coldfire would have been
the closest option - but after a closer look it became obvious
that I would have to do a lot of emulation because of the unsupported
address modes etc.
So I bit the bullet and switched to the Power PC - and I have not
regretted that for a minute. I wrote an assembler (or is it a
compiler?)
which produced PPC object code out of my CPU32 sources, added
some new features (now I call it VPA... Virtual Processor Assembler),
and it is a really powerful tool along with the entire DPS environment.
The emulated CPU32 code - with no optimisation at all, that is,
maintaining all the CCR modifications wherever necessary and
wherever not necessary - is 3.5 times longer than the original
CPU32 code - a negligible price to pay for all that. Several years
later,
with much more code written no longer backwards CPU32
compatible, dps.syst is about 100 kilobytes - this is the kernel, with
VM/MMU, file system, scheduler etc. - the OS, basically speaking - then
there is the graphics interface support which is another 130 k or so,
with al the window, off-screen buffer, drawing primitives etc. support.
Hey, I got a bit carried away - sorry, I'll leave it unedited though,
someone might be curious enough to read that.
My advice would be in favour of the PPC - more than a single
manufacturer, by far the best architecture from a technical point of
view I know of (not that ARM or Coldfire are bad, PPC is just
ages ahead), a clear migration path 32 -> 64 bit which is already
being exploited, lots of peripherals and devices (just check the
Freescale site; then the AMCC site; then IBM; and then even
Xilinx have FPGAs with PPC cores inside).

Dimiter


----------

I think your particular example is pretty unusual, and could hardly be used as a recommendation for others. Sometimes a tool that converts from one assembly to another, your "virtual processor assembler", can make sense - but it's very rare, and only suitable in the case when you have very large quantities of assembly software that you must use without change on a new platform, and even then it is only a stop-gap until a real maintainable solution is found. Hopefully the OP is not in this situation!

As for your choice of going to the PPC instead of the ColdFire, I find it hard to understand. The ColdFire has something like 80-90% match at the assembly level with the 68k devices, and Motorola/Freescale have tools to convert the rest (combined with an emulation library for really obscure stuff). All your VPA work would be unnecessary using the ready-made tools. There may have been some mismatch in the operating modes (ColdFires have slightly different user/supervisor models from 68k devices), but I'd expect it to be closer than any corresponding PPC modes.

The PPC architecture has it's strong points - being easy to understand, easy to use, and suitable for a small device as a step up from 8-bit are not among them. If the OP is used to the simplicity of devices such as the AVR or the 8051, but needs a bit more processing power, then a PPC-based micro would come as a very big shock. In itself, the PPC architecture is nice if you are thinking big - for example, the condition code system is much more scalable than in the ColdFire ISA. If you are thinking small to medium, however, the PPC is overly complex, especially at an assembly level. Migration to 64 bits is possible, but hardly "clear" - an address bus that runs from A31 "up" to A-8 is not exactly pretty, and it's hardly in the OP's sights as a step up from 8-bit.

Finally, there's the question of suitable microcontrollers based on the PPC core. About the simplest and cheapest are the Freescale MPC5xx line. These are powerful devices, and well suited to some applications, but they in terms of ease-of-learning they are not in the same class as a small ColdFire or Arm.

David

larrylin

6# larrylin

Obviously it is unusual indeed, how many houses are there which
do not need any software from outside to do their development.

It is very rare indeed, and it is quite maintainable. It is by far not
just an assembler, it is an entire environment you live in. Times more
efficient than existing C based alternatives.

Having written many megabytes of sources for both CPU32 and PPC,
I can say that PPC is beyond reach for competing architectures
nowadays.
Using its native assembly makes no sense at all,
if you don't have VPA you are stuck with C or other HLL.
And I agree it may be overkill for many applications, and will
likely be for another while until power consumption drops by
another factor of 10 or so - perhaps not so far in the future.
After all, the OP can make his own judgement, we can help
only by sharing our experiences.

Dimiter