Reply by Everett M. Greene April 6, 20062006-04-06
David Brown <david@westcontrol.removethisbit.com> writes:
> Dave wrote: > > On Wed, 05 Apr 2006 13:54:38 +0100, David Brown wrote: > > > >> The CPU32 also has a couple of additions compared to the 68020, such as > >> a fast loop mode > > > > Okay, I'll bite. What is "fast loop mode"? I know what loop mode, > > introduced on the 68010, is. > > 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.
ABCD and SBCD are indicated as being 68K family instructions.
Reply by David Brown April 6, 20062006-04-06
Didi wrote:
>> Thus Freescale's MPC5xx line of PPC-based microcontrollers >> have a BDM interface for debugging, and a JTAG interface for boundary >> scanning. I don't know about any other Freescale PPC devices. > > None of the newer ones (8xxx, 5xxx etc.) have separate BDM, all > has gone JTAG - which is good enough an interface, my sole issue > with it is the data secrecy. They claim to keep it secret because > it would be a great support effort, which is of course nonsense. > Some people do get enough data to make debugging equipment. >
I'll take your word for it - I haven't used any PPC chips other than the MPC5xx line. I do see, however, that the MPC55xx line have dropped the BDM, and have JTAG only for boundary scan. For debugging, they use a Nexus interface (which is also available on the MPC5xx, but I haven't tried it). The Nexus interface seems to be able to provide real-time tracing, like the BDM, but runs faster and has more pins (the old BDM is too limited to handle real-time tracing at higher speeds, with features such as pipelining and speculative execution). Again, this is a dedicated debugging interface rather than a simple serial backdoor such as JTAG. As to how well it is documented, I don't know - I've never had occasion to look at the details.
Reply by David Brown April 6, 20062006-04-06
Dave wrote:
> On Wed, 05 Apr 2006 13:54:38 +0100, David Brown wrote: > >> The CPU32 also has a couple of additions compared to the 68020, such as >> a fast loop mode > > Okay, I'll bite. What is "fast loop mode"? I know what loop mode, > introduced on the 68010, is. > > > ~Dave~
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.
Reply by Dave April 6, 20062006-04-06
On Wed, 05 Apr 2006 17:11:01 -0700, Didi wrote:

>> Okay, I'll bite. What is "fast loop mode"? I know what loop mode, >> introduced on the 68010, is. > > 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). > ... > Was loop mode the same on the 010?
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. ;-) ~Dave~
Reply by Didi April 5, 20062006-04-05
> 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.
Thanks, apparently same thing.
> 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).
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 ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Isaac Bosompem wrote:
> Didi wrote: > > > Okay, I'll bite. What is "fast loop mode"? I know what loop mode, > > > introduced on the 68010, is. > > > > 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 > > > > ------------------------------------------------------ > > Dimiter Popoff Transgalactic Instruments > > > > http://www.tgi-sci.com > > ------------------------------------------------------ > > > > > > > > > > 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
Reply by Dave April 5, 20062006-04-05
On Wed, 05 Apr 2006 13:54:38 +0100, David Brown wrote:

> The CPU32 also has a couple of additions compared to the 68020, such as > a fast loop mode
Okay, I'll bite. What is "fast loop mode"? I know what loop mode, introduced on the 68010, is. ~Dave~
Reply by Isaac Bosompem April 5, 20062006-04-05
Didi wrote:
> > Okay, I'll bite. What is "fast loop mode"? I know what loop mode, > > introduced on the 68010, is. > > 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 > > ------------------------------------------------------ > Dimiter Popoff Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------ > > > >
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
Reply by Didi April 5, 20062006-04-05
> Okay, I'll bite. What is "fast loop mode"? I know what loop mode, > introduced on the 68010, is.
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 ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Dave wrote:
> On Wed, 05 Apr 2006 13:54:38 +0100, David Brown wrote: > > > The CPU32 also has a couple of additions compared to the 68020, such as > > a fast loop mode > > Okay, I'll bite. What is "fast loop mode"? I know what loop mode, > introduced on the 68010, is. > > > ~Dave~
Reply by Wilco Dijkstra April 5, 20062006-04-05
"Didi" <dp@tgi-sci.com> wrote in message 
news:1144075938.870483.194470@j33g2000cwa.googlegroups.com...

>> 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. > > 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.
In what way more efficient? I can imagine it assembles faster but it sounds unlikely that it can produce more efficient code than a good C compiler - writing assembler is a lot more tedius than C, and compilers are really good at brain damaging tasks like register allocation, parameter passing, data layout etc. There has been a lot of research into universal assemblers, and the result is often something similar to C (C-- for example, others consider C an assembly language), or a high level assembler with some macro facilities to get loops, if and switch statements, structures etc. Who does the data layout and register allocation? Do you have a description of VPA and what it looks like?
>> 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. >> .... > > Having written many megabytes of sources for both CPU32 and PPC, > I can say that PPC is beyond reach for competing architectures > nowadays.
PPC has some pretty good implementations as they were targeting desktops, and they are indeed high-end (and as a result high-power). However there is no reason to believe other architectures can't produce high-end implementations with similar performance. Many embedded architectures already have fast superscalar implementations or are working on them (eg MIPS, ARM, SH). It is now possible to do 1GHz with less than 1 Watt, so you'll see more high-end implementations. Wilco
Reply by Jim Granville April 5, 20062006-04-05
David Brown wrote:

> Roberto wrote: > >> Thank you for all the replies. >> >> Since my next designs will involve Ethernet and Can I think I will choose >> Freescale with its >> new MCF5223x (ethernet MAC+PHY, CAN, onboard 128Kb or 256Kb flash, >> 32Kb ram) >> >> Roberto >> > > I haven't heard anything about the pricing and availability of these > chips yet, but they look *very* nice.
You've probably now seen http://www10.edacafe.com/nbc/articles/view_article.php?section=ICNews&articleid=258015 Funny how LOTS of devices announce around ESC time :) -jg