EmbeddedRelated.com
Forums

Next logical step after 8bit uCs?

Started by Michael Noone December 6, 2004
On 2004-12-07, Michael Noone <mnoone.uiuc.edu@127.0.0.1> wrote:

>>> or do you really just have to hardcode it? >> >> Not sure what you mean by "hardcode it". > > I'm sorry - understand I'm just a student so I'm sure I use > the wrong words for alot of things... All I mean is that the > only way that I can figure out how to divide something in a > chip that doesn't have a divide instruction is to write out a > little routine that divides it by hand - the same way that one > would divide a number on a piece of paper.
Yup.
> I can see this taking quite a few clock cycles even when > dealing with 8bit numbers...
Yup.
> I guess the general strategy would probabaly be to subract the > divisor from the dividend, check to see if the new dividend is > 0 or rolled past 0, if not then go back and subract again,
That's
> etc. Or is there a better way?
Usually. There are people who spend many years researching division algorithms. Here's an article with some good references (and example code) that google found: http://www.bearcave.com/software/divide.htm -- Grant Edwards grante Yow! I want the presidency at so bad I can already taste visi.com the hors d'oeuvres.
I think this ARM core is thumb only,
http://www.arm.com/miscPDFs/6751.pdf

On Tue, 07 Dec 2004 17:09:54 GMT, Michael Noone 
<mnoone.uiuc.edu@127.0.0.1> wrote:

> So am I right in thinking that there are some Thumb chips that can only > run in thumb mode, while there are other full ARM chips that can run in > both > thumb and ARM modes? Thanks!
I highly doubt Thumb-only chips exist, at least I am not aware of any. In ARM core numbering 'T' stays for Thumb, so if it is ARM7TDMI, it supports ARM and additionally Thumb mode. While ARM4 is ARM-mode only -- example is StrongARM. In general, the naming conventions look like: ARMxyz ------ x - processor family (7, 9, 10, ...) y - major memory features z - variation of major memory features Memory features: xy -- 20 - MMU + caches 22 - MMU + half-size caches 26 - MMU + caches + TCM 40 - MPU + caches 46 - MPU + caches + TCM 66 - TCM Where: MMU - memory management unit MPU - memory protection unit TCM - tightly-coupled memory Thus, ARM920T is family 9, with MMU and caches, plus Thumb. Vadim
On Tue, 07 Dec 2004 17:39:05 GMT, Michael Noone 
<mnoone.uiuc.edu@127.0.0.1> wrote:

> [...] All I mean is that the only way that I can > figure out how to divide something in a chip that doesn't have a divide > instruction is to write out a little routine that divides it by hand - > the same way that one would divide a number on a piece of paper.
Kind of -- you need to have a division routine. There are trivial cases like division by a power of 2. Then there is multiplication by reciprocal. And a number of other techniques :) In general, you have several options. If you would use C or C++, the compiler will generate the calls to the division function and the linker will resolve the symbol from the library. You can write the code in assembly and still call the same division function, passing the arguments in right order. Or you can provide your own division function. Vadim
bungalow_steve wrote:

> I think this ARM core is thumb only, > http://www.arm.com/miscPDFs/6751.pdf
Not quite - this is their new Cortex core, and whilst full info is still sketchy,it does say this "Cortex-M3 32-bit RISC processor executes purely Thumb&#4294967295;-2 instructions" Note the Thumb-2, (and other info) : this is NOT binary compatible : so this could be as compatible with ARM7, as the XA-51 is with 80C51 code. I WOULD like to see a list of Cortex opcodes, but ARM marketing want this to sound 'almost the same', just like Philips marketing wanted the XA-51 to sound just like another 80C51.... Anyone seen a beta Compiler, or benchmarked some real Cortex Code they can talk about yet ? -jg
On 2004-12-07, bungalow_steve <bungalow_steve@yahoo.com> wrote:

> I think this ARM core is thumb only, http://www.arm.com/miscPDFs/6751.pdf
I do believe you're right. It looks like it was announced about 6 weeks ago. Google didn't find any parts that contain that core. -- Grant Edwards grante Yow! Sign my PETITION. at visi.com
Michael Noone wrote:
>
... snip ...
> > So is it still possible to go about dividing when there is no divide > instruction? I mean I can certainly see a way to hardcode it, but I > would imagine that to be very processor intensive, especially since > I'd be dealing with 32bit numbers. So - is there any "trick" to > doing this, or do you really just have to hardcode it? Thanks!
Of course it is. The essential thing is an add/subtract instruction or subroutine of the appropriate width. You can avoid even that in specialized situations - see the dubldabl algorithm description on my site. People are so coddled these days :-) -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
"Michael Noone" <mnoone.uiuc.edu@127.0.0.1> wrote

> So is it still possible to go about dividing when there is no divide > instruction?
Ye Gods and little fishes! What are they teaching in school these days? Oh, yes, how to use a calculator ...
> I mean I can certainly see a way to hardcode it ...
1) All math functions, heck _all_ functions, are 'coded': either as wires, microcode or application code; usually by all three at once. 2) All computers can be emulated by a machine with only one instruction: "Move bit from X to Y and jump to Z if the bit moved was a one." Written as "X, Y, Z", with one instruction who needs an opcode. And all digital systems can be constructed (or deconstructed) with 2-input NAND gates (or NOR, if you prefer). Everything else is extrapolated from there: you do it or someone else does it for you. 3) It is really a matter of how much abstraction you want, how many $$ you are willing to spend on run-time libraries/cores and how much elbow-grease you are willing to put into the project.
> I would imagine that to be very processor intensive,
It is. That's the point: let the processor do it.
> especially since I'd be dealing with 32bit numbers.
That's not a very big number.
> So - is there any "trick" to doing this, or do you really just have > to hardcode it?
As "trick" I imagine you mean: "Is there any way I can get out of doing this?" Is there any trick to digging a ditch? No. But you can get someone else to do it for you. As part of one's education one should have coded (and it isn't all that 'hard') a few math routines. After that, if one is not going into the numeric side of the business, one uses proven canned software/microcode/hardware for common math. If you are using a high-level language that supports floating point math then an IEEE math run-time-library will (should) come with the compiler/interpreter. If not, you can buy an IEEE library for most any processor from folks like U.S. Software. Put an RPN emulator around this and code away as if it was an h/p calculator. FWIW that calculator you are using most likely has a serial 4-bit microprocessor: a one bit processor emulating a 4-bit processor. You are not going to get much sympathy in your avoidance of doing a bit of work to add floating point to your whatever-it-is. * * * You still, though, haven't said what the 'whatever-it-is' is. The answer to your dilemma may have nothing to do with fast math ... -- Nicholas O. Lindan, Cleveland, Ohio Consulting Engineer: Electronics; Informatics; Photonics. Remove spaces etc. to reply: n o lindan at net com dot com psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
"Nicholas O. Lindan" <see@sig.com> wrote in
news:zpotd.8083$Va5.2900@newsread3.news.atl.earthlink.net: 

> "Michael Noone" <mnoone.uiuc.edu@127.0.0.1> wrote > >> So is it still possible to go about dividing when there is no divide >> instruction? > > Ye Gods and little fishes! What are they teaching in school these > days? Oh, yes, how to use a calculator ...
I meant was there any easier way besides coding it - some math trick I was forgetting or something.
> >> I mean I can certainly see a way to hardcode it ... > > 1) All math functions, heck _all_ functions, are 'coded': either as > wires, > microcode or application code; usually by all three at once. > > 2) All computers can be emulated by a machine with only one > instruction: > "Move bit from X to Y and jump to Z if the bit moved was a one." > Written as "X, Y, Z", with one instruction who needs an opcode. > And all digital systems can be constructed (or deconstructed) with > 2-input NAND gates (or NOR, if you prefer). Everything else is > extrapolated from there: you do it or someone else does it for you. > > 3) It is really a matter of how much abstraction you want, how many $$ > you > are willing to spend on run-time libraries/cores and how much > elbow-grease you are willing to put into the project.
Again - as I said - I was just wondering if there was any easier way besides the obvious. Apparently there isn't.
> >> I would imagine that to be very processor intensive, > > It is. That's the point: let the processor do it. > >> especially since I'd be dealing with 32bit numbers. > > That's not a very big number.
After dealing with 8 bit numbers on all my previous projects - it looks fairly big. Everything's relative.
> >> So - is there any "trick" to doing this, or do you really just have >> to hardcode it? > > As "trick" I imagine you mean: "Is there any way I can get out of > doing this?" Is there any trick to digging a ditch? No. But you can > get someone else to do it for you. >
I don't see why you're being so sassy... Again - I meant is there any way besides the obivous.
> As part of one's education one should have coded (and it isn't all > that 'hard') a few math routines. > > After that, if one is not going into the numeric side of the business, > one uses proven canned software/microcode/hardware for common math. > > If you are using a high-level language that supports floating point > math then an IEEE math run-time-library will (should) come with the > compiler/interpreter. > > If not, you can buy an IEEE library for most any processor from folks > like U.S. Software. Put an RPN emulator around this and code away as > if it was an h/p calculator. > > FWIW that calculator you are using most likely has a serial 4-bit > microprocessor: > a one bit processor emulating a 4-bit processor. You are not going to > get much sympathy in your avoidance of doing a bit of work to add > floating point to your whatever-it-is.
I'm not trying to avoid anything - I'm trying to make sure I don't do anything horrendously inefficient in my code.
> > * * * > > You still, though, haven't said what the 'whatever-it-is' is. The > answer to your dilemma may have nothing to do with fast math ... > > -- > Nicholas O. Lindan, Cleveland, Ohio > Consulting Engineer: Electronics; Informatics; Photonics. > Remove spaces etc. to reply: n o lindan at net com dot com > psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
I don't have an exact application as of yet. I just expect that in the near future I will be needing to use something more advanced than a 8bit uC like an AVR, as it seems each one of my projects becomes more and more complicated and now I'm starting to be limited by AVRs abilities. (both speedwise and capability wise) -Michael
Michael Noone wrote:
> Grant Edwards <grante@visi.com> wrote in news:41b5e4aa$0$9705$a1866201 > @visi.com: > > >>On 2004-12-07, Michael Noone <mnoone.uiuc.edu@127.0.0.1> wrote: >> >> >>>>ARM is another option, 32 bits, but has multiple cycle multiplies > > and > >>>>no divide instruction, >> >>Not have a divide isntruction is fairly common for DSPs, isn't >>it? They're generally optimized around multiply-add sequences. >> >> >>>>I would consider it a "weak" DSP processor, maybe its good >>>>enough for you. >>> >>>So is it still possible to go about dividing when there is no >>>divide instruction? >> >>Of course. >> >> >>>I mean I can certainly see a way to hardcode it, but I would >>>imagine that to be very processor intensive, especially since >>>I'd be dealing with 32bit numbers. So - is there any "trick" >>>to doing this, >> >>The trick is to avoid doing division. >> >> >>>or do you really just have to hardcode it? >> >>Not sure what you mean by "hardcode it". >> > > > I'm sorry - understand I'm just a student so I'm sure I use the wrong > words for alot of things... All I mean is that the only way that I can > figure out how to divide something in a chip that doesn't have a divide > instruction is to write out a little routine that divides it by hand - > the same way that one would divide a number on a piece of paper. I can > see this taking quite a few clock cycles even when dealing with 8bit > numbers... I guess the general strategy would probabaly be to subract > the divisor from the dividend, check to see if the new dividend is 0 or > rolled past 0, if not then go back and subract again, etc. Or is there a > better way? Thanks, > > Michael
A while back I carefully analyzed and figured out the Atmel example code (you should find this code, including other algorithms for multiplies and I think signed versions as well, in their App. Notes!) for unsigned division. The top part is some code to allow you to run it in the simulator, and find out exactly how many clocks it takes. You may have to edit the text to replace the TABs with spaces or whatever, to get the formatting to look respectable again. Good day! ---------------- .include "2313/2313def.inc" .def zero = r1 .def temp = r24 .def total_lo = r2 .def total_hi = r3 .def time = r27 Reset: ldi r16,low(RAMEND) out SPL,r16 Main: clr zero clr total_lo clr total_hi ldi dd,252 ; r16 Loop: push dd ldi dv,3 ; r17 out TCNT0,zero ; clear Timer 0 ldi temp,0b00000001 ; select CK/1 out TCCR0,temp ; turn on Timer 0 rcall U8divU8_1 ldi temp,0b00000000 out TCCR0,temp ; stop Timer 0 in time,TCNT0 ; r27 subi time,5 ; correct for overhead add total_lo,time adc total_hi,zero ; r3:r2 pop dd inc dd ;cpi rB0,16 brne Loop rjmp Main Dummy: ret ; U8divU8_1 is my rewording of the Atmel division routine. ; ; Registers: .def dd = r16 ; unsigned 8 bit dividend .def dv = r17 ; unsigned 8 bit divisor .def quot = r16 ; unsigned 8 bit quotient replaces ; dividend .def rem = r15 ; unsigned 8 bit remainder .def loop_cnt = r25 U8divU8_1: sub rem,rem ldi loop_cnt,9 Shift_DD: rol dd dec loop_cnt brne Shift_R ret Shift_R: rol rem sub rem,dv brsh Set_C add rem,dv clc rjmp Shift_DD Set_C: sec rjmp Shift_DD ; Example of long division algorithm. In the code, the quotient is ; developed in the register containing the dividend. ; ; 0100 = Q , R = 0001 ; ______ ; DV = 0011 | 1101 = DD ; -11 subtract DV from leftmost bit of DD (first rol DD into R) ; --- ; C10 result negative so ; +11 add DV back to remainder, put 0 in Q (rol 0 into DD) ; --- ; 11 shift next DD bit into R ; -11 subtract DV ; --- ; 0 result not negative so put 1 in Q ; 00 shift next DD bit into R ; -11 subtract DV ; --- ; C01 negative, so ; +11 add DV back to remainder, put 0 in Q ; --- ; 01 shift next DD bit into R ; -11 subtract DV ; --- ; C10 result negatvie so ; +11 add DV back to remainder, put 0 in Q ; --- ; 1 remainder ; R = 0 ; clear Carry ; loop_count = 9 ; Shift_DD: DD << 1 ; shifts MSb into C ; -- loop_count ; If loop_count = 0 then return ; R << 1 ; shifts C into LSb of R ; R = R - DV ; if negative then R = R + DV ; else goto Set_C ; clear Carry ; will put a 0 into Q ; goto Shift_DD ; Set_C: set Carry ; will put a 1 into Q ; goto Shift_DD -- _______________________________________________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply.