PDA

View Full Version : Curious, which line of code is faster?

iQuit
05-17-2010, 07:42 AM
I found a couple of ways to do one thing, and was wondering if one was preferable over the other. Being a SoS (student of Spin), these questions come up
often during my studies. I'm sure that there are even more ways to accomplish this, but am mostly curious...

Var
byte Col

PUB Go
'cod here...

Col := !INa[7..4] - 240

'More code, but these are the two lines in question.

Col := !INa[7..4] & %00001111

Since there are no VAR nibbles available, I found that I need to strip the top four bits--they get set to ones after the bitwise NOT! Is one of these faster, more

Just curious == Dan
http://forums.parallax.com/images/smilies/smilewinkgrin.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"She may not be very pretty now, but she was somebody's baby once." Bugs Bunny

kuroneko
05-17-2010, 08:10 AM
Why don't you take the next step and simply measure how long each expression takes? ;)

Also, you say that the high nibble is %1111 after the bitwise NOT, in this case you might as well use INa[7..4] ^ %1111.

Post Edited (kuroneko) : 5/17/2010 6:44:42 AM GMT

JonnyMac
05-17-2010, 09:14 AM
The first.· Per Kuroneko-san's suggestion, I timed them (see attached).

BTW, the - 240 in the first line and the & %00001111 in the second line·is redundant if you're looking for a 4-bit value.· The way you're using ina[ ] takes care of the masking and shifting.· Your result, with the subraction or anding is going to be %0000 - %1111.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Post Edited (JonnyMac) : 5/17/2010 2:21:40 AM GMT

kuroneko
05-17-2010, 09:43 AM
JonnyMac said...
BTW, the - 240 in the first line and the & %00001111 in the second line is redundant if you're looking for a 4-bit value.

Problem is that the "!" in !ina[] affects all the other bits in a long as well (or byte in this case). And I assume he wants them zero'd.

JonnyMac
05-17-2010, 12:33 PM
Arigato gozaimasu. I was under the (incorrect) assumption that the masking would happen after the !, it happens before. You are correct that be cleanest approach to this code is:

col := ina[7..4] ^ %1111

Ironically, I have a BCD switch on a product and just went back and looked at my own code (written two months ago) -- it is:

PUB getselect

'' Reads SFX select switch (\$00 to \$0F)

return !ina[SEL_MSB..SEL_LSB] & \$0F

It's six of one, a half-dozen of the other (same result with slightly different code).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Post Edited (JonnyMac) : 5/17/2010 5:43:39 AM GMT

heater
05-17-2010, 01:40 PM
Or you could compile the thing with BST with View->Compiler listing option turned on and then inspect the listing for the actual byte code generated. For simple statements like this it is easy to see what the relative execution times will be by counting the bytecodes in each case.

Well almost. Be aware that different bytecodes will probably take different amounts of time to execute. But I think for a first approximation we can assume they are close enough the same. If your code is that sensitive to timing it is probably time to move to PASM anyway.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

MagIO2
05-17-2010, 06:29 PM
Ok ... just a few more words, as iQuit marked himself as a student ;o)

XOR is also called a 'programmable inverter' ...
One side of the XOR register is the input (I) . Now let's assume the other side of the XOR is a configuration input (C) telling the XOR which bits to negate and which not. R being the result:

I C R
0 0 0
1 0 1

0 1 1
1 1 0

If you have a look at R in combination with C you see that R is a copy of I in case C == 0 and R is the inverse of I in case C == 1.

iQuit
05-17-2010, 11:00 PM
NICE! I didn't think of timing. Great idea.
This is not time critical, but being a SoS, I always like to know which of my alternatives are MORE PROPER?
And yes, I need the uppers zeroed. If there were a nibble VAR, I could use that. But I have to make my own.
I actually tried my two variants, and they work. Hadn't thought of ^ %1111. The ^ and & usages look the cleanest, but
for me, at this stage, the & is more readable.

I'm going to keep the timing thing in mind for future use. Thanks to all, Dan

P.S. By the way, this is for a hex keypad reader that I'm trying to implement using the fewest number of pins. http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"She may not be very pretty now, but she was somebody's baby once." Bugs Bunny