Shop OBEX P1 Docs P2 Docs Learn Events
Curious, which line of code is faster? — Parallax Forums

Curious, which line of code is faster?

iQuitiQuit Posts: 78
edited 2010-05-17 16:00 in Propeller 1
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[noparse][[/noparse]7..4] - 240

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

 Col := !INa[noparse][[/noparse]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
efficient or more readable etc.?

Just curious == Dan
smilewinkgrin.gif

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

Comments

  • kuronekokuroneko Posts: 3,623
    edited 2010-05-17 01:10
    Why don't you take the next step and simply measure how long each expression takes? [noparse];)[/noparse]

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

    Post Edited (kuroneko) : 5/17/2010 6:44:42 AM GMT
  • JonnyMacJonnyMac Posts: 9,235
    edited 2010-05-17 02:14
    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[noparse][[/noparse] ] 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
  • kuronekokuroneko Posts: 3,623
    edited 2010-05-17 02:43
    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[noparse]/noparse affects all the other bits in a long as well (or byte in this case). And I assume he wants them zero'd.
  • JonnyMacJonnyMac Posts: 9,235
    edited 2010-05-17 05:33
    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[noparse][[/noparse]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[noparse][[/noparse]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
  • heaterheater Posts: 3,370
    edited 2010-05-17 06:40
    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.
  • MagIO2MagIO2 Posts: 2,243
    edited 2010-05-17 11:29
    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.
  • iQuitiQuit Posts: 78
    edited 2010-05-17 16:00
    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. smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "She may not be very pretty now, but she was somebody's baby once." Bugs Bunny
Sign In or Register to comment.