Cortex-M3 vs PIC32 divide instruction

On Tue, 6 Sep 2011 12:40:00 +0000 (UTC),
Anders.Montonen@kapsi.spam.stop.fi.invalid wrote:

>Jon Kirwan <jonk@infinitefactors.org> wrote:
>
>> I still need to find out if the DIV can be interrupted.
>
>Footnote e to table 18-1 in the Cortex-M3 r2p0 TRM states that
>"DIV is interruptible (abandoned/restarted), with worst case latency of
>one cycle."
>
>-a

Thanks!

Jon

On 06/09/2011 13:30, Jon Kirwan wrote:
> On Tue, 06 Sep 2011 12:21:08 +0200, David Brown
> <david@westcontrol.removethisbit.com>  wrote:
> The purpose is due diligence and to illuminate speculations I
> may yet develop.  It's not a crystal clear process that I can
> readily explain.  But I do know _what_ I want to know.
>
> If it helps, imagine that I'd like to develop a cycle-
> accurate simulator.
>
>>> I simply need very detailed information.  I've been having a
>>> little difficultly laying hands on it in the Cortex-M3 case.
>>> I'm hoping someone can point me well.
>>
>> I would be surprised if you can get the detailed information you would
>> like - such implementation details tend to be well hidden from mere mortals.
>
> Appears to be hidden from me, tonight.  So maybe you are
> right.
>
> I _am_ able to garner better information from the M4k.  I
> still need to find out if the DIV can be interrupted.
>

The M4K is an older architecture (or at least it is closer to the older 
MIPS architectures), with a simpler structure and lots more information 
about it.  You'll get better luck there.

>> One thing you might be able to find out about is how the division
>> affects pipelining - but on an M3, with its short pipeline, that won't
>> make a big difference.
>
> Yes, 3 stage vs 5 stage on the M4k.  I also took note that
> Microchip licensed the M14k, too.
>
>> Regarding interrupts, AFAIK instructions on the M3 (and MIPS) are not
>> interruptable (unlike some m68k cpus, for example), so maximum interrupt
>> latency will be affected by division instructions.
>
> Yes, that is one of several considerations I have in mind.
> Only one of them.  But an important one.  I am not yet
> certain about the M4k on this point.
>

The key thing to look for here is the data that is stored on the stack, 
or in dedicated registers, when an interrupt or other exception hits. 
On the m68k, for example, the processor can generate a rather extensive 
stack frame including the state of internal registers that are not 
otherwise accessible, holding partial results for division, progress 
counters for move-multiple instructions, etc.  On RISC architectures you 
don't get a stack frame for exceptions, but critical context data is put 
into dedicated registers that must be preserved if you are going to 
enable nested interrupts.  You should be able to see from the details of 
these registers where things can be interrupted.

> Anyway, thanks for the thoughts.  I will see what I can find
> out there.  It is an omen that you don't know.  So that
> suggests your earlier point about the difficulty here may be
> correct.
>

While I know many things, I don't know everything!  My knowledge of MIPS 
is based on a book on the "MIPS RISC Microarchitecture" I found in a 
second hand bookstore 20 years ago, and read for fun before I had even 
thought of doing embedded programming as a job.

> Jon
>
>>>
>>> But thanks for the time.  It is appreciated.
>>>
>>> Jon

On 06/09/2011 14:40, Anders.Montonen@kapsi.spam.stop.fi.invalid wrote:
> Jon Kirwan<jonk@infinitefactors.org>  wrote:
>
>> I still need to find out if the DIV can be interrupted.
>
> Footnote e to table 18-1 in the Cortex-M3 r2p0 TRM states that
> "DIV is interruptible (abandoned/restarted), with worst case latency of
> one cycle."
>

OK, it is interruptible in that way - that's good for avoiding long 
interrupt latency.  Some cpu's (such as some m68k devices) can be 
interrupted in the middle of an instruction like divide, and then 
continue where they left off rather than starting anew.

On Tue, 06 Sep 2011 15:31:58 +0200, David Brown
<david@westcontrol.removethisbit.com> wrote:

>On 06/09/2011 13:30, Jon Kirwan wrote:
>> On Tue, 06 Sep 2011 12:21:08 +0200, David Brown
>> <david@westcontrol.removethisbit.com>  wrote:
>> The purpose is due diligence and to illuminate speculations I
>> may yet develop.  It's not a crystal clear process that I can
>> readily explain.  But I do know _what_ I want to know.
>>
>> If it helps, imagine that I'd like to develop a cycle-
>> accurate simulator.
>>
>>>> I simply need very detailed information.  I've been having a
>>>> little difficultly laying hands on it in the Cortex-M3 case.
>>>> I'm hoping someone can point me well.
>>>
>>> I would be surprised if you can get the detailed information you would
>>> like - such implementation details tend to be well hidden from mere mortals.
>>
>> Appears to be hidden from me, tonight.  So maybe you are
>> right.
>>
>> I _am_ able to garner better information from the M4k.  I
>> still need to find out if the DIV can be interrupted.
>
>The M4K is an older architecture (or at least it is closer to the older 
>MIPS architectures), with a simpler structure and lots more information 
>about it.  You'll get better luck there.

ARM has been around a LONG time.  But I worked on MIPS R2000
back circa 1986/1987.  Was that before the ARM/Acorn?  I
don't recall when the R4000 came out but it must have been
after the Acorn.  I think trying to decide which is older is
going to be a bunch of quibbling.

>>> One thing you might be able to find out about is how the division
>>> affects pipelining - but on an M3, with its short pipeline, that won't
>>> make a big difference.
>>
>> Yes, 3 stage vs 5 stage on the M4k.  I also took note that
>> Microchip licensed the M14k, too.
>>
>>> Regarding interrupts, AFAIK instructions on the M3 (and MIPS) are not
>>> interruptable (unlike some m68k cpus, for example), so maximum interrupt
>>> latency will be affected by division instructions.
>>
>> Yes, that is one of several considerations I have in mind.
>> Only one of them.  But an important one.  I am not yet
>> certain about the M4k on this point.
>
>The key thing to look for here is the data that is stored on the stack, 
>or in dedicated registers, when an interrupt or other exception hits. 
>On the m68k, for example, the processor can generate a rather extensive 
>stack frame including the state of internal registers that are not 
>otherwise accessible, holding partial results for division, progress 
>counters for move-multiple instructions, etc.  On RISC architectures you 
>don't get a stack frame for exceptions, but critical context data is put 
>into dedicated registers that must be preserved if you are going to 
>enable nested interrupts.  You should be able to see from the details of 
>these registers where things can be interrupted.

There's a point for me to go look up.

>> Anyway, thanks for the thoughts.  I will see what I can find
>> out there.  It is an omen that you don't know.  So that
>> suggests your earlier point about the difficulty here may be
>> correct.
>
>While I know many things, I don't know everything!  My knowledge of MIPS 
>is based on a book on the "MIPS RISC Microarchitecture" I found in a 
>second hand bookstore 20 years ago, and read for fun before I had even 
>thought of doing embedded programming as a job.

Mine all comes from working with the R2000 and a nice, long
lecture for a couple of days from Hennessey when I visited
them back when they first opened up an office near Weitek
(their first office.)  I'm very comfortable with the R2000.

Jon

On 09/06/2011 03:31 PM, David Brown wrote:

> The key thing to look for here is the data that is stored on the stack,
> or in dedicated registers, when an interrupt or other exception hits. On
> the m68k, for example, the processor can generate a rather extensive
> stack frame including the state of internal registers that are not
> otherwise accessible, holding partial results for division, progress
> counters for move-multiple instructions, etc. On RISC architectures you
> don't get a stack frame for exceptions, but critical context data is put
> into dedicated registers that must be preserved if you are going to
> enable nested interrupts. You should be able to see from the details of
> these registers where things can be interrupted.

Interestingly, the Cortex isn't very pure RISC anymore, and it does have 
a stack frame for exceptions. It doesn't save partial results, but it 
does save a couple of registers, which allow an interrupt handler to be 
written in pure C, and it allows hardware nesting of interrupts. The 
link register which normally contains the return address is set to a 
magic value, so on function return, the core knows to do a return from 
exception instead.

On 06/09/2011 15:51, Jon Kirwan wrote:
> On Tue, 06 Sep 2011 15:31:58 +0200, David Brown
> <david@westcontrol.removethisbit.com>  wrote:
>
>> On 06/09/2011 13:30, Jon Kirwan wrote:
>>> On Tue, 06 Sep 2011 12:21:08 +0200, David Brown
>>> <david@westcontrol.removethisbit.com>   wrote:
>>> The purpose is due diligence and to illuminate speculations I
>>> may yet develop.  It's not a crystal clear process that I can
>>> readily explain.  But I do know _what_ I want to know.
>>>
>>> If it helps, imagine that I'd like to develop a cycle-
>>> accurate simulator.
>>>
>>>>> I simply need very detailed information.  I've been having a
>>>>> little difficultly laying hands on it in the Cortex-M3 case.
>>>>> I'm hoping someone can point me well.
>>>>
>>>> I would be surprised if you can get the detailed information you would
>>>> like - such implementation details tend to be well hidden from mere mortals.
>>>
>>> Appears to be hidden from me, tonight.  So maybe you are
>>> right.
>>>
>>> I _am_ able to garner better information from the M4k.  I
>>> still need to find out if the DIV can be interrupted.
>>
>> The M4K is an older architecture (or at least it is closer to the older
>> MIPS architectures), with a simpler structure and lots more information
>> about it.  You'll get better luck there.
>
> ARM has been around a LONG time.  But I worked on MIPS R2000
> back circa 1986/1987.  Was that before the ARM/Acorn?  I
> don't recall when the R4000 came out but it must have been
> after the Acorn.  I think trying to decide which is older is
> going to be a bunch of quibbling.
>

Yes, ARM has been around for ages - it was probably around 1988 that I 
first used an ARM (Acorn Risc Machine) on an Archimedes.  But the 
architecture has gone through a great many changes since then - the 
Cortex M3 is significantly different both in programming model and in 
implementation.  MIPS has remained a lot more constant.  So the M3 is 
really one a few years old, while the R4000 is /much/ older, and much 
more studied.

>>>> One thing you might be able to find out about is how the division
>>>> affects pipelining - but on an M3, with its short pipeline, that won't
>>>> make a big difference.
>>>
>>> Yes, 3 stage vs 5 stage on the M4k.  I also took note that
>>> Microchip licensed the M14k, too.
>>>
>>>> Regarding interrupts, AFAIK instructions on the M3 (and MIPS) are not
>>>> interruptable (unlike some m68k cpus, for example), so maximum interrupt
>>>> latency will be affected by division instructions.
>>>
>>> Yes, that is one of several considerations I have in mind.
>>> Only one of them.  But an important one.  I am not yet
>>> certain about the M4k on this point.
>>
>> The key thing to look for here is the data that is stored on the stack,
>> or in dedicated registers, when an interrupt or other exception hits.
>> On the m68k, for example, the processor can generate a rather extensive
>> stack frame including the state of internal registers that are not
>> otherwise accessible, holding partial results for division, progress
>> counters for move-multiple instructions, etc.  On RISC architectures you
>> don't get a stack frame for exceptions, but critical context data is put
>> into dedicated registers that must be preserved if you are going to
>> enable nested interrupts.  You should be able to see from the details of
>> these registers where things can be interrupted.
>
> There's a point for me to go look up.
>
>>> Anyway, thanks for the thoughts.  I will see what I can find
>>> out there.  It is an omen that you don't know.  So that
>>> suggests your earlier point about the difficulty here may be
>>> correct.
>>
>> While I know many things, I don't know everything!  My knowledge of MIPS
>> is based on a book on the "MIPS RISC Microarchitecture" I found in a
>> second hand bookstore 20 years ago, and read for fun before I had even
>> thought of doing embedded programming as a job.
>
> Mine all comes from working with the R2000 and a nice, long
> lecture for a couple of days from Hennessey when I visited
> them back when they first opened up an office near Weitek
> (their first office.)  I'm very comfortable with the R2000.
>
> Jon

On Tue, 06 Sep 2011 09:54:00 +0200, David Brown wrote:

> On 06/09/2011 09:39, Jon Kirwan wrote:

>> snip <<

> If you want to do very fast floating point, get a processor that has
> hardware floating point (Cortex-M4 will be available soon, there are
> real MIPS cpu's available instead of PIC32, there are plenty of
> PPC-based microcontrollers with hardware floating point, etc.).

Sometimes the goal is to write fast-enough floating point in a processor 
that won't otherwise break the system budget, be it power consumption/
dissipation, size, BOM cost, etc.

Jon's asking about _writing_ a floating point library, so I assume he's 
working at a project front-end, counting clock cycles to make sure that 
things will work.

-- 
www.wescottdesign.com

On Sep 6, 11:17=A0pm, Jon Kirwan <j...@infinitefactors.org> wrote:
> On Tue, 6 Sep 2011 10:32:53 +0000 (UTC),
>
> Anders.Monto...@kapsi.spam.stop.fi.invalid wrote:
> >Jon Kirwan <j...@infinitefactors.org> wrote:
> >> Also, it's been a bit of a pain searching for good assembler docs on t=
he
> >> Cortex-M3. =A0But I've only been at it for about an hour or so,
> >> so it's likely I am just slow and ignorant -- not that there
> >> aren't good caches out there I should have found.
>
> >You want the ARMv7-M Architecture Reference Manual off of ARM's website.
>
> I think I have that for the assembly part of things. =A0If you
> are referring to the near-end where the Appendices are at,
> then I'm already aware of those sections (B, C, F, G, H.) =A0I
> did also look at the timing information in Chapter 18-1, for
> example, of DDI0337 on the Cortex-M3 for r1p1, r2p0, and
> r2p1. =A0Though perhaps I haven't read it well enough.
>
> I think I have been there. =A0But I may have missed something,
> too, and I appreciate the suggestion
>
> Jon

 If the speed of this matters a lot, you are best to simply get a
device, and try it.
 'Modern data' tends to be more and more superficial, and that is one
reason there are more cheap Eval/Starter kits.
 Note that other  devices are not standing still either - I see both
TI and ADI are now boasting of sub $2 DSPs (tho RAM based)

 TI's strangely lacks Timer capture, (they must want you to buy other
variants there) but does have high speed USB for a small cost adder.
 ADIs has good timers, but no USB.
 Both, of course, have very fast maths support, and quite large ROMS
with Floating point as well.
 -jg

On Sep 7, 2:42=A0pm, Jim Granville <j.m.granvi...@gmail.com> wrote:
> On Sep 6, 11:17=A0pm, Jon Kirwan <j...@infinitefactors.org> wrote:
>
>
>
> > On Tue, 6 Sep 2011 10:32:53 +0000 (UTC),
>
> > Anders.Monto...@kapsi.spam.stop.fi.invalid wrote:
> > >Jon Kirwan <j...@infinitefactors.org> wrote:
> > >> Also, it's been a bit of a pain searching for good assembler docs on=
 the
> > >> Cortex-M3. =A0But I've only been at it for about an hour or so,
> > >> so it's likely I am just slow and ignorant -- not that there
> > >> aren't good caches out there I should have found.
>
> > >You want the ARMv7-M Architecture Reference Manual off of ARM's websit=
e.
>
> > I think I have that for the assembly part of things. =A0If you
> > are referring to the near-end where the Appendices are at,
> > then I'm already aware of those sections (B, C, F, G, H.) =A0I
> > did also look at the timing information in Chapter 18-1, for
> > example, of DDI0337 on the Cortex-M3 for r1p1, r2p0, and
> > r2p1. =A0Though perhaps I haven't read it well enough.
>
> > I think I have been there. =A0But I may have missed something,
> > too, and I appreciate the suggestion
>
> > Jon
>
> =A0If the speed of this matters a lot, you are best to simply get a
> device, and try it.
> =A0'Modern data' tends to be more and more superficial, and that is one
> reason there are more cheap Eval/Starter kits.
> =A0Note that other =A0devices are not standing still either - I see both
> TI and ADI are now boasting of sub $2 DSPs (tho RAM based)
>
> =A0TI's strangely lacks Timer capture, (they must want you to buy other
> variants there) but does have high speed USB for a small cost adder.
> =A0ADIs has good timers, but no USB.
> =A0Both, of course, have very fast maths support, and quite large ROMS
> with Floating point as well.
> =A0-jg

Last (only...:) ) time I used a TI DSP was apr. 10 years ago,
the 5420. Their divide was straight forward, use "subtract
conditionally"
in a repeat (penalty free) loop.
I also have wondered - just vaguely, though - how do they accelerate
division on various architectures, e.g. the power core I use now
needs only 14 (or was it 16?) cycles for a 32/32, older
implementations
of that core (the original 603e, that is) needed 30+, 37 IIRC.
I have been moaning so many times of having to write yet another
division - I think the only architecture which saved me that was the
68k, ppc didn't, it does not have the 64/32 68k has, not on 32 bit
machines) that I use the chance to ask Jon to share his findings,
I am also really curious about it.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

On Wed, 7 Sep 2011 04:42:13 -0700 (PDT), Jim Granville
<j.m.granville@gmail.com> wrote:

>On Sep 6, 11:17&#4294967295;pm, Jon Kirwan <j...@infinitefactors.org> wrote:
>> On Tue, 6 Sep 2011 10:32:53 +0000 (UTC),
>>
>> Anders.Monto...@kapsi.spam.stop.fi.invalid wrote:
>> >Jon Kirwan <j...@infinitefactors.org> wrote:
>> >> Also, it's been a bit of a pain searching for good assembler docs on the
>> >> Cortex-M3. &#4294967295;But I've only been at it for about an hour or so,
>> >> so it's likely I am just slow and ignorant -- not that there
>> >> aren't good caches out there I should have found.
>>
>> >You want the ARMv7-M Architecture Reference Manual off of ARM's website.
>>
>> I think I have that for the assembly part of things. &#4294967295;If you
>> are referring to the near-end where the Appendices are at,
>> then I'm already aware of those sections (B, C, F, G, H.) &#4294967295;I
>> did also look at the timing information in Chapter 18-1, for
>> example, of DDI0337 on the Cortex-M3 for r1p1, r2p0, and
>> r2p1. &#4294967295;Though perhaps I haven't read it well enough.
>>
>> I think I have been there. &#4294967295;But I may have missed something,
>> too, and I appreciate the suggestion
>>
>> Jon
>
> If the speed of this matters a lot, you are best to simply get a
>device, and try it.

Jim, there is a difference between knowing something through
theory and knowing something only through experimental
result.  Although it is _practical_ and often _sufficient_ to
know through result, it is also true that all I'd learn is
the results for the specific cases I'm able to spend time
testing.  Theory informs a volume.  Results inform specific
points within that volume.  I want both.  Just buying a
device only gives me a few data points.  That's not enough.

In the case of the PIC32, I have the theory.  So I am fully
able to predict just about any situation I'm given.  (Except
that I still don't have the theory about what happens in the
presence of an exception -- but I will get that from
Microchip directly.)

Anyway, I know you are being practical.  But I want to go
beyond knowing only what a few tests may tell me.

> 'Modern data' tends to be more and more superficial, and that is one
>reason there are more cheap Eval/Starter kits.

Yes, but the designers _know_ the theory.  So it is available
somewhere.  And I'm not really wanting to poke out
experimental results and try and develop theories of my own
that match what I observe when it might just be nice to get
the low-down from someone who actually knows what is going
on.  Which is why I decided to just ask here.  (The other
option would be to write ARM, I suppose -- and I will do that
if nothing comes of the details here and simply hope they are
moved to respond to me.  I _know_ Microchip will respond,
from past experience with them.)

> Note that other  devices are not standing still either - I see both
>TI and ADI are now boasting of sub $2 DSPs (tho RAM based)
> TI's strangely lacks Timer capture, (they must want you to buy other
>variants there) but does have high speed USB for a small cost adder.
> ADIs has good timers, but no USB.
> Both, of course, have very fast maths support, and quite large ROMS
>with Floating point as well.

I am familiar with older families from both through coding
applications -- the ADSP-21xx from ADI; the TMS320C30 and C40
from TI.  I'm not completely unaware of newer parts, too.

But like most projects, there are a number of boundary
conditions involved and the DIV details I mentioned is only
one of many.  But DSP processing is decidely NOT the main
focus nor is floating point.  I merely mentioned FP as a
segue, because I felt that anyone writing assembly coded FP
would possibly know the theory I was looking for.  That
doesn't mean that is my focus.  I also mentioned interrupt
latency issues, later.  There are many considerations.

Jon