EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

dsPIC33CH Vs dsPIC33F divide.

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - Electronics Design - dsPIC33CH Vs dsPIC33F divide.

Clive Arthur
Guest

Thu Jan 03, 2019 12:45 pm   



I posted this on comp.arch.embedded, but there's little action there,
all the clever people must be here...

The new dsPIC33CH parts have a 6 cycle divide whereas the older dsPIC33F
takes 18 cycles. The number of cycles is not data dependent.

So I guess more Silicon for fewer cycles, but used how?

Cheers
--
Clive

David Brown
Guest

Thu Jan 03, 2019 3:45 pm   



On 03/01/2019 12:18, Clive Arthur wrote:
Quote:
I posted this on comp.arch.embedded, but there's little action there,
all the clever people must be here...


No, there are plenty of clever people on comp.arch.embedded. But they
tend to stick to on-topic posts, and ones that interest them. I don't
expect there are a great many people using the dsPIC devices, and I
expect very few of these people are interested in how the new versions
do their division. They might be happy that new versions are faster at
division - but why is it of interest /how/ this is implemented?

Division hardware can be implemented in a variety of ways - wikipedia
will give you some suggestions. And if you are really interested in the
details, comp.arch is a better newsgroup.


Quote:
The new dsPIC33CH parts have a 6 cycle divide whereas the older dsPIC33F
takes 18 cycles.  The number of cycles is not data dependent.

So I guess more Silicon for fewer cycles, but used how?

Cheers


Clive Arthur
Guest

Thu Jan 03, 2019 4:45 pm   



On 03/01/2019 14:30, David Brown wrote:
Quote:
On 03/01/2019 12:18, Clive Arthur wrote:
I posted this on comp.arch.embedded, but there's little action there,
all the clever people must be here...


No, there are plenty of clever people on comp.arch.embedded. But they
tend to stick to on-topic posts, and ones that interest them. I don't
expect there are a great many people using the dsPIC devices, and I
expect very few of these people are interested in how the new versions
do their division. They might be happy that new versions are faster at
division - but why is it of interest /how/ this is implemented?


So you don't know either and you don't want to know, thanks for that
insight.

Quote:
Division hardware can be implemented in a variety of ways - wikipedia
will give you some suggestions.


It doesn't really help, unfortunately.

Quote:
And if you are really interested in the
details, comp.arch is a better newsgroup.


Thanks.

Quote:
The new dsPIC33CH parts have a 6 cycle divide whereas the older dsPIC33F
takes 18 cycles.  The number of cycles is not data dependent.

So I guess more Silicon for fewer cycles, but used how?


Cheers
--
Clive

David Brown
Guest

Thu Jan 03, 2019 9:45 pm   



On 03/01/2019 16:12, Clive Arthur wrote:
Quote:
On 03/01/2019 14:30, David Brown wrote:
On 03/01/2019 12:18, Clive Arthur wrote:
I posted this on comp.arch.embedded, but there's little action there,
all the clever people must be here...


No, there are plenty of clever people on comp.arch.embedded.  But they
tend to stick to on-topic posts, and ones that interest them.  I don't
expect there are a great many people using the dsPIC devices, and I
expect very few of these people are interested in how the new versions
do their division.  They might be happy that new versions are faster at
division - but why is it of interest /how/ this is implemented?

So you don't know either and you don't want to know, thanks for that
insight.


I know some ways of doing division in hardware, and I know where to look
for more details. (I've pointed you at a couple of good starting points
- one website, and one newsgroup.)

I haven't the faintest idea what method is used in the dsPIC devices,
and I don't expect anyone outside the inner circle of Microchip's design
team know either.

Does that help?


Quote:

Division hardware can be implemented in a variety of ways - wikipedia
will give you some suggestions.

It doesn't really help, unfortunately.

And if you are really interested in the
details, comp.arch is a better newsgroup.

Thanks.


Another possible choice would be comp.arch.fpga. Those folks don't make
chips like the dsPIC, but they make algorithms in FPGAs.

Quote:

The new dsPIC33CH parts have a 6 cycle divide whereas the older dsPIC33F
takes 18 cycles.  The number of cycles is not data dependent.

So I guess more Silicon for fewer cycles, but used how?


Cheers



Guest

Thu Jan 03, 2019 9:45 pm   



Clive Arthur wrote
Quote:
I posted this on comp.arch.embedded, but there's little action there,
all the clever people must be here...

The new dsPIC33CH parts have a 6 cycle divide whereas the older dsPIC33F
takes 18 cycles. The number of cycles is not data dependent.

So I guess more Silicon for fewer cycles, but used how?

Cheers


I am looking at the datasheet, and indeed it says on page 1
Fast 6-Cycle Divide

But searching for 'cycles' in the pdf finds this on page 45:
3.1.8.2 Divider
The divide block supports 32-bit/16-bit and 16-bit/16-bit
signed and unsigned integer divide operations with the
following data sizes:
32-bit signed/16-bit signed divide
32-bit unsigned/16-bit unsigned divide
16-bit signed/16-bit signed divide
16-bit unsigned/16-bit unsigned divide
The 16-bit signed and unsigned DIV instructions can
specify any W register for both the 16-bit divisor (Wn)
and any W register (aligned) pair (W(m + 1):Wm) for
the 32-bit dividend.

The divide algorithm takes one <-----------------------
cycle per bit of divisor,

so both 32-bit/16-bit and 16-bit/
16-bit instructions take the same number of cycles to
execute. There are additional instructions: DIV2 and
DIVF2. Divide instructions will complete in six cycles.


So, one would expect 16 cycles for a 16 bit divisor????
Could it be a typo (6 being 16?)
Did you measure the delay?

I do not have the chip else I would measure it.

John Larkin
Guest

Fri Jan 04, 2019 12:45 am   



On Thu, 03 Jan 2019 20:31:30 GMT, <698839253X6D445TD_at_nospam.org>
wrote:

Quote:
Clive Arthur wrote
I posted this on comp.arch.embedded, but there's little action there,
all the clever people must be here...

The new dsPIC33CH parts have a 6 cycle divide whereas the older dsPIC33F
takes 18 cycles. The number of cycles is not data dependent.

So I guess more Silicon for fewer cycles, but used how?

Cheers

I am looking at the datasheet, and indeed it says on page 1
Fast 6-Cycle Divide

But searching for 'cycles' in the pdf finds this on page 45:
3.1.8.2 Divider
The divide block supports 32-bit/16-bit and 16-bit/16-bit
signed and unsigned integer divide operations with the
following data sizes:
32-bit signed/16-bit signed divide
32-bit unsigned/16-bit unsigned divide
16-bit signed/16-bit signed divide
16-bit unsigned/16-bit unsigned divide
The 16-bit signed and unsigned DIV instructions can
specify any W register for both the 16-bit divisor (Wn)
and any W register (aligned) pair (W(m + 1):Wm) for
the 32-bit dividend.

The divide algorithm takes one <-----------------------
cycle per bit of divisor,

so both 32-bit/16-bit and 16-bit/
16-bit instructions take the same number of cycles to
execute. There are additional instructions: DIV2 and
DIVF2. Divide instructions will complete in six cycles.


So, one would expect 16 cycles for a 16 bit divisor????
Could it be a typo (6 being 16?)
Did you measure the delay?

I do not have the chip else I would measure it.


We have gone to The Dark Side and do most embedded-system math in
floats these days. Some of the modest ARMs have hardware vector fp.


--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

elektroda.net NewsGroups Forum Index - Electronics Design - dsPIC33CH Vs dsPIC33F divide.

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map