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

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

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

Guest

Thu Jan 03, 2019 3:45 pm

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

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.

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

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 4:45 pm

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?

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.

Division hardware can be implemented in a variety of ways - wikipedia

will give you some suggestions.

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.

details, comp.arch is a better newsgroup.

Thanks.

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?

takes 18 cycles.Â The number of cycles is not data dependent.

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

Cheers

--

Clive

Guest

Thu Jan 03, 2019 9:45 pm

On 03/01/2019 16:12, Clive Arthur wrote:

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.

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?

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.

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

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

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.

Guest

Fri Jan 04, 2019 12:45 am

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

wrote:

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.

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.**