PIC 18F family - CORDIC division algorithm: dividend (up to 48 bits) / divisor (up to 32 bits)

[atferrari]

I recently became aware of the so called CORDIC division algorithm thanks to a post of an AAC's member which brought me to this site.

Instead of limiting myself to 16 bits I decided to greedily work out a routine able to cope with up to 48 bits (dividend) and 32 bits (divisor). The algorithm gives de facto the remainder whether you need it or not.

Two hours ago I completed the first tests with valid results. Had to struggle with lot of clerical errors and a printed flow diagram was invaluable.

Code is not optimized in any way albeit seems to be correctly debugged but I do not plan to show it yet.

The calculations for the initial alignment of both MS bits plus the subsequent shiftings make for a lot of code, lot of RAM registers and a lot of T cycles.

My request: before deciding whether to stop here or to continue improving my code, I would like to hear comments if it sounds reasonable simply maybe because this CORDIC variety is not the way to go for huge numbers.

Gracias.

F2 79 D8 94 65 31 / BC = 01 4A 2E 16 93 9A | 19

 

[gophert]

What is the maximum resolution (bits) possible on an 8-bit PIC with c in MPLab? I assume you are doing this with 8-bit chips, correct?

 

[atferrari]

18 F family - 8 bits, gophert.

Sorry, I am not C conversant.

 

[Ian Rogers]

atferrari What's wrong with the bit shift algorithm, is it too slow?

 

[atferrari]

Have to shift 6 bytes every time for divisor and 6 for the base index.

Keep in mind Ian Rogers that I wrote it for 48/32.

To avoid the pseudo substractions for deciding if dividend is equal or higher than divisor I use compares (18F family has them) bUt still takes time.

With code running apparently OK but not yet improved, the stop watch gave me some 1070 Tcy.

Lot still to be done if I want this reasonable to use.

 

[gophert]

I think it is interesting to explore in assembly code but most programmers that need such resolution are using 32-bit micros and extremely efficient divide algorithms to execute divide within c. The 32-bit chips also have more core commands that allow divide to be executed with fewer clock cycles.

the XC32 compiler in C for PIC32 can handle 64bits in long double variable type with the first 53 bits being a signed integer and the last 11 bits are a signed integer as an exponent (+/-1023) which gives an enormous range at great resolution.

I also have trouble thinking of why one would need so many bits of resolution when doing division with an 8-bit chip. If doing a running average, or a voltage average or what ever, picking a convenient denominator of n^2 allows for simple bit shifting to do the division. But it is an interesting exercise to know how many clock cycles are needed in an 8-bit chip when justifying a more expensive and more complicated chip.

 

[atferrari]

I think it is interesting to explore in assembly code but most programmers that need such resolution are using 32-bit micros and extremely efficient divide algorithms to execute divide within c. The 32-bit chips also have more core commands that allow divide to be executed with fewer clock cycles.

the XC32 compiler in C for PIC32 can handle 64bits in long double variable type with the first 53 bits being a signed integer and the last 11 bits are a signed integer as an exponent (+/-1023) which gives an enormous range at great resolution.

I also have trouble thinking of why one would need so many bits of resolution when doing division with an 8-bit chip. If doing a running average, or a voltage average or what ever, picking a convenient denominator of n^2 allows for simple bit shifting to do the division. But it is an interesting exercise to know how many clock cycles are needed in an 8-bit chip when justifying a more expensive and more complicated chip.

Hola gophert

My routine, as is, to divide C3 00 C3 00 / C3 00 takes a humongous 1080 Tcy appr.

A lot can be reduced but not sure if I would do the effort albeit I feel satisfied with my code running almost in the first try.

Assembly - 18F2321 - MPLABX 5.40 - pic-as 2.20.

Could you elaborate on the part in bold, please?

 

[rjenkinsgb]

the XC32 compiler in C for PIC32 can handle 64bits in long double variable type

The C compilers for all PIC types can handle up to 64 bit integer or float types. The data size is not related to the word size of the CPU, it just takes more instructions when it has to be done in smaller sections.

 

[gophert]

Hola gophert

My routine, as is, to divide C3 00 C3 00 / C3 00 takes a humongous 1080 Tcy appr.

A lot can be reduced but not sure if I would do the effort albeit I feel satisfied with my code running almost in the first try.

Assembly - 18F2321 - MPLABX 5.40 - pic-as 2.20.

Could you elaborate on the part in bold, please?

For example, one could write code that calculates a running average 12 or 30 values but that means dividing create a significant amount of math and possible delay in making adjustment to stabilize a system. It is usually better to just take 16 or 32 values for your running average and shift right 4 or 5 bits (respectively) and the division is done.

 

[gophert]

The C compilers for all PIC types can handle up to 64 bit integer or float types. The data size is not related to the word size of the CPU, it just takes more instructions when it has to be done in smaller sections.

Umm, nope.
In xc8, it says double double is same 32 bits as double - if 32 bit is selected. Default is 24bit

 

[rjenkinsgb]

OK, I use the CCS C compiler, as it's far more versatile in regard to device peripherals. That has the same limits for all device families.
I did not realise XC8 was restricted like that.

 

[Nigel Goodwin]

You might check the divide routines on the PICLIST?



Although none are as big as you asked, but do you really need them that big?.