How can I multiply 2 data that result in a 64 bit value? For example: unsigned long a = 4000000000, c; unsigned int b = 60000; c = a * b; //this have a problem!!! Has any library that can I use? Thanks Leonardo
You have to creat your own multiplication routine to achieve this. No library routine is there to have multi byte maths. You have to create your own routine.
Nobody has said it yet, so I will: if you need to do 64-bit arithmetic, then you are probably using the wrong processor! More helpfully: have you considered fixed or floating point arithmetic? Whether these are applicable depends upon exactly what it is you are trying to achieve. Finally, if you must do 64-bit arithmetic, you may find what you need here: ftp.embedded.com/.../crenshaw98.txt
Thanks for the answer. I will use this commands. The processor I can't chance at this time, but I will think about it! Thanks a lot!!!! Leonardo
http://www.8052.com/codelib/math8051.asm "A collection of math routines including 8-bit, 16-bit, 32-bit signed and unsigned addition, subtraction, multiplication, and division. Very nice code library with heavy in-line documentation! Been looking for multi-byte divide? Here it is." Perhaps you could take this as a basis to roll your own?
if you need to do 64-bit arithmetic, then you are probably using the wrong processor! Just by way of counter-example: The IEEE 802 standard (Ethernet, and others) specifies that the various counters it specifies may not roll over any faster than 57 minutes. It also specifies that any counter that can't be done in 32 bits has to be 64 bits wide. Approximately 2/3 of the counters at a gigabit rate, as for Gigabit Ethernet, thus have to be 64 bit counters. An embedded 8051 works really well to control an Ethernet chip. It doesn't have a lot to do in terms of raw horsepower. And it's not doing intensive math on those 64 bit integers. It's just adding a hardware register to a U64 once in a while -- minutes, maybe. Or, as another example, consider the IEEE MAC address, 48 bits wide. Perhaps you need to generate a series of a few MAC addresses, starting from a base address. So you increment a U64 a few times. Wide results do not necessarily correspond to a need for lots of MIPS or RAM. Nuclear weapon simulation and indexing memory-mapped Google database files aren't the only uses for 64 bit math. It would be quite nice if Keil provided 64-bit integer libraries.
Erik did only say, "probably the wrong processor" "you increment a U64 a few times" The OP was actually asking about multiplication - not just incrementing "Wide results do not necessarily correspond to a need for lots of MIPS or RAM" Not necessarily - but there must always be that suspicion...! ;-)
It was Graham :) Have you figured out what my company makes yet, given all the comments about 8051s embedded in Ethernet chips? We use ARMs as well, as it happens. I occasionally contemplate writing my few U64 arithmetic routines in assembler. And I'm always struck by the fact that the DPTR has an INC instruction, but no DEC. This would seem to make little-endian math more natural for the 8051, as you just rip through a couple of U64s with dual DPTRs and ADC. Moving backwards for the big endian format is harder, though. Keil libraries seem to load entire U32s into registers, do the math, and then write the result back out. But that strategy doesn't work so well with U64s.
"It was Graham :)" So it was - sorry, Erik!
"I'm always struck by the fact that the DPTR has an INC instruction, but no DEC." Aren't there a few derivatives that do add a decrement instruction? Anyhow, still doesn't help with the OP's multiplications...
I don't see how anybody could add an instruction to the 8051 machine language without requiring a whole new compiler (like the MX51 does). What some derivatives do add is a special bit in an SFR that changes the meaning of the normal 'inc dptr' instruction into 'dec dptr'.
"What some derivatives do add is a special bit in an SFR that changes the meaning of the normal 'inc dptr' instruction into 'dec dptr'." That's probably what I've seen referred to, then.
"That's probably what I've seen referred to, then" Or perhaps not: http://www.keil.com/forum/docs/thread908.asp