EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: metertech58761 on February 17, 2023, 09:29:19 am
-
Still plugging away at figuring out that bit of code, but I have made significant steps in understanding it...
Once I get a better handle on a few bits, I might finally be able to move beyond transliteration to actually rewriting the code.
One of the tricker parts is attached - it is too long to display in-line, so am attaching it as text instead.
I tried putting it into a 68xx emulator but the results just don't match what I'm expecting, so want to see if the brain trust here can make more sense of this snippet.
Also, perhaps to offer guidance as to how it might look in C (treating the multi-byte values as a single numeric value, which appears to be little-endian).
Hope I explained what I'm asking or am I clear as mud like always?
msgRec (5,4,3) = incoming binary value
temp6 - temp9 are scratchpad bytes
bcdData54..10 is the packed BCD result (which is then unpacked and pushed to the display via other routines).
EDIT:
I just had a flash of insight -
Shifting a number by 3 bits then adding the original back in... that's multiplying by 9 isn't it?
There's a register factor that comes into play somehow... it's 13 8/9. When expressed in 'improper' form, that works out to 125/9.
Division is basically repeated subtraction until you deplete the original number isn't it?
So what am I missing? This looks like it could be replaced by just a few statements in C++, right?
-
This would accomplish the same thing, right?
impulse = ((msgTbl[5] << 16) + (msgTbl[4] << 8 ) + msgTbl[3]); // impulse count rec'd from UUT
impulse = (impulse * 9);
bcdBuffer = 0;
do
{
impulse = (impulse - 1250);
bcdBuffer++;
}
while (impulse > 1250);
If the above is usable, then how do I ensure the output is 5 digits (we only care about the lower 5 digits)?
-
So now you've got
bcdBuffer = (impulse * 9) / 1250
where impulse was in BCD but bcdBuffer is in binary (because you didn't increment in BCD).
Not sure that's what you wanted, but if you do in fact want to print only the least 5 digits of an integer in bcdBuffer, it will be (bcdBuffer % 100000), ie the remainder when the value is divided by 100000.
edit:
Sorry, you do appear to DAA the value incrementing in bcdData - but not the value decrementing in temp. Not sure what's going on there.
The carry processing is required because DAA can result in a carry out when the msd is corrected from a result > 10 to a carry+remainder.
-
That helps. Thank you!
And I think this in turn has probably given me a clue about another part of the code...!
-
It's true that division is repeated subtraction.
However, if you're expecting a result greater than 100000, subtracting 1250 per loop is going to be a horribly inefficient way to do it
You probably want to do long division, subtracting as many 1250 X 100000 as possible followed by 1250 x 10000, 1250 x 1000 etc.
-
That was more in regards to an assembly language perspective... I still want to rewrite this app (and interrupt) in something more modern like C++ that would allow me to move it to one of the PIC platforms.
Another part of the code I finally understood enabled me to determine some parts that would have been tricky to rewrite were not needed after all. That in turn allowed a bit further cleanup (so far, I've shaved the original 7+ kilobytes of assembly down to about 4.5K).
The one remaining obstacle is being able to move smoothly between BCD and binary values in C++.