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.

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.

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.

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~

> 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

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~

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

> 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~

"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 

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