Shop OBEX P1 Docs P2 Docs Learn Events
P2 Instructions TESTB & TESTBN - Page 4 — Parallax Forums

P2 Instructions TESTB & TESTBN

124»

Comments

  • cgraceycgracey Posts: 14,133
    ozpropdev wrote: »
    GET works for me.

    We already have
    GETWORD
    GETBYTE
    GETNIB

    so it makes sense to "carry" that form on with
    GETBIT
    GETPIN

    One trick I learned many years ago to avoid confusion is to read the documentation.
    I never assume that one MCU is going to behave the same as another.

    Also, those instructions all work with indexing.

    I like these:

    GETBIT
    GETBITN
    GETPIN
    GETPINN

    The last one doesn't look right with two N's.
  • cgracey wrote: »
    ozpropdev wrote: »
    GET works for me.

    We already have
    GETWORD
    GETBYTE
    GETNIB

    so it makes sense to "carry" that form on with
    GETBIT
    GETPIN

    One trick I learned many years ago to avoid confusion is to read the documentation.
    I never assume that one MCU is going to behave the same as another.

    Also, those instructions all work with indexing.

    I like these:

    GETBIT
    GETBITN
    GETPIN
    GETPINN

    The last one doesn't look right with two N's.

    GETBIT
    GETTIB
    GETPIN
    GETNIP
  • GETBIT
    GETNBIT
    GETPIN
    GETNPIN
  • cgraceycgracey Posts: 14,133
    edited 2018-12-11 00:50
    TonyB_ wrote: »
    cgracey wrote: »
    ozpropdev wrote: »
    GET works for me.

    We already have
    GETWORD
    GETBYTE
    GETNIB

    so it makes sense to "carry" that form on with
    GETBIT
    GETPIN

    One trick I learned many years ago to avoid confusion is to read the documentation.
    I never assume that one MCU is going to behave the same as another.

    Also, those instructions all work with indexing.

    I like these:

    GETBIT
    GETBITN
    GETPIN
    GETPINN

    The last one doesn't look right with two N's.

    GETBIT
    GETTIB
    GETPIN
    GETNIP

    This is the worst idea you've had, TonyB_.

    (I'm pretty sure you're joking, though.)
  • cgraceycgracey Posts: 14,133
    ozpropdev wrote: »
    GETBIT
    GETNBIT
    GETPIN
    GETNPIN

    Maybe this is what we go with.
  • cgracey wrote: »
    TonyB_ wrote: »
    cgracey wrote: »
    ozpropdev wrote: »
    GET works for me.

    We already have
    GETWORD
    GETBYTE
    GETNIB

    so it makes sense to "carry" that form on with
    GETBIT
    GETPIN

    One trick I learned many years ago to avoid confusion is to read the documentation.
    I never assume that one MCU is going to behave the same as another.

    Also, those instructions all work with indexing.

    I like these:

    GETBIT
    GETBITN
    GETPIN
    GETPINN

    The last one doesn't look right with two N's.

    GETBIT
    GETTIB
    GETPIN
    GETNIP

    This is the worst idea you've had, TonyB_.

    (I'm pretty sure you're joking, though.)

    It's not my fault, this is what happens when someone types GETPINN.
  • Get works for me too.

    Whatever gets done, we can eventually Make Some Noise about this in the documentation. It won't seem as bad.
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-12-11 10:13
    AJL wrote: »
    Roy Eltham wrote: »
    My recent post suggested a new suffix for these. Is that acceptable?
    As I said, the problem is that having WZ on the suffix implies that the Z flag will be set according to the result (as in set when the result is 0) and not what will actually happen with these instructions.
    That, to me, is the crux of the problem. So it needs to be something else that indicates it.

    Also, I don't like GET* at all.

    To me (and I think it's safe to say, Chip), all the WC and WZ suffices indicate is that the particular flag is affected (may change). I humbly submit that the "set according to the result (as in set when the result is 0)" is an inference, not an implication.

    To me, the crux of the problem is whether one can accept the idea of flag states being directly controlled, or being restricted to the ALU state output only. It seems obvious to me that we have some who can and some who can't (or won't), but only for the Z flag; Direct control of the C flag is accepted without question.
    I find this inconsistency quite puzzling.
    It's because there is no difference for C. Whether you shift into or test, C is set when 1 (or parity)
    Z is a special case specifically meaning Zero, not Non-Zero. It is the same in ALL micros that have a Z flag. And there are special instructions that rely on that setting, such as the conditional execution IF_Z and IF_NZ, DJZ, DJNZ, TJZ, TJNZ.

    It's about time some of you wrote some programs that use these things instead of commenting on theory. Then you'll find the issues and inconsistencies.
  • evanhevanh Posts: 15,126
    I've used TESTP WZ a lot for monitoring smartpins. I default to it over WC because WC is more likely to be used for other jobs.

  • Cluso99Cluso99 Posts: 18,066
    Chip,
    It's fundamentally wrong. There's no way around it.
    So you may as well leave it as is :(
  • This does not seem like a hill to die on.

    In some cases Z and C are flags in the conventional sense, in others they are single bit registers, based on the context of the instruction using them.

    It is a pragmatic reuse of logic, I see no reason for any changes.

    C.W.
  • ctwardell wrote: »
    This does not seem like a hill to die on.

    In some cases Z and C are flags in the conventional sense, in others they are single bit registers, based on the context of the instruction using them.

    It is a pragmatic reuse of logic, I see no reason for any changes.

    C.W.
    I agree.

  • cgraceycgracey Posts: 14,133
    I agree, too.

    Do you guys think GETxxxx mnemonics would be better than the current TESTxxx mnemonics, though?
  • Ahle2Ahle2 Posts: 1,178
    Yes, because TEST in the name implies that it is directly related to the "normal" test instruction. Which works differently and sets the flags in a different way. That will make a lot of people confused.
  • cgraceycgracey Posts: 14,133
    Ahle2 wrote: »
    Yes, because TEST in the name implies that it is directly related to the "normal" test instruction. Which works differently and sets the flags in a different way. That will make a lot of people confused.

    I agree.
  • cgracey wrote: »
    I agree, too.

    Do you guys think GETxxxx mnemonics would be better than the current TESTxxx mnemonics, though?

    Yes.

    I found useful the following way to think about it:

    GETBIT/GETNBIT and GETPIN/GETNPIN can use either C or Z flag as accumulator for bit operations (Write=load / AND / OR / XOR).

    Write (load) operation copies the selected bit into the accumulator (C or Z).
    This means that Z flag's value will be the opposite of the expected value for other instructions:
    WZ when the selected bit is zero results in Z=0 (instead of the usual Z=1).

    Maybe you will find this useful for documentation.
  • cgraceycgracey Posts: 14,133
    edited 2018-12-11 15:02
    Conga wrote: »
    cgracey wrote: »
    I agree, too.

    Do you guys think GETxxxx mnemonics would be better than the current TESTxxx mnemonics, though?

    Yes.

    I found useful the following way to think about it:

    GETBIT/GETNBIT and GETPIN/GETNPIN can use either C or Z flag as accumulator for bit operations (Write=load / AND / OR / XOR).

    Write (load) operation copies the selected bit into the accumulator (C or Z).
    This means that Z flag's value will be the opposite of the expected value for other instructions:
    WZ when the selected bit is zero results in Z=0 (instead of the usual Z=1).

    Maybe you will find this useful for documentation.

    Okay. I like those mnemonics, too. That is what we will do.
  • Chip, I agree get is better than test.
  • cgraceycgracey Posts: 14,133
    edited 2018-12-11 15:17
    ctwardell wrote: »
    Chip, I agree get is better than test.

    And, as someone pointed out, these instructions will go well with GETNIB/GETBYTE/GETWORD, which also permit indexing via ALTx instructions.

    Cluso99, could we have your blessing?
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-12-11 20:02
    cgracey wrote: »
    ctwardell wrote: »
    Chip, I agree get is better than test.

    And, as someone pointed out, these instructions will go well with GETNIB/GETBYTE/GETWORD, which also permit indexing via ALTx instructions.

    Cluso99, could we have your blessing?
    That sounds fine. As I said, it works differently.

    Could you leave in the TESTP/TESTPN/TESTB/TESTBN WZ/WC
    instructions and compile to the reverse the Z please? (ie Z sets if =0 as expected for test instructions)
    Note I deliberately left out WCZ as the silicon will not support that result. I'd even be happy with just supporting WZ if easier.

    BTW I wasn't having a meltdown. I just believe that it's an exception and still don't have a nice solution.
  • Cluso99Cluso99 Posts: 18,066
    Just had a horrible thought...
    What about GETNIB etc WZ/WC/WCZ ?

    Fortunately, there are no WZ/WC/WCZ options for GETNIB etc :)
  • cgraceycgracey Posts: 14,133
    Cluso99 wrote: »
    Just had a horrible thought...
    What about GETNIB etc WZ/WC/WCZ ?

    Fortunately, there are no WZ/WC/WCZ options for GETNIB etc :)

    If you scare yourself half to death, twice, on the same day...

    I don't want to change the meaning of TESTP(N) and TESTB(N) regarding Z because it will break my ROM code and I don't want that worry. Your ROM code would be affected, too. Let's just think about anything else.
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    Cluso99 wrote: »
    Just had a horrible thought...
    What about GETNIB etc WZ/WC/WCZ ?

    Fortunately, there are no WZ/WC/WCZ options for GETNIB etc :)

    If you scare yourself half to death, twice, on the same day...
    Let me think about that... Ummm :wink:
    I don't want to change the meaning of TESTP(N) and TESTB(N) regarding Z because it will break my ROM code and I don't want that worry. Your ROM code would be affected, too. Let's just think about anything else.
    Sure. We can revisit later as it's just a compiler add-in and I think it's a nice instruction.
  • roglohrogloh Posts: 5,122
    edited 2018-12-12 00:26
    Am not really wanting to open up more discussion as it seems things are perhaps finally converging a little? but it was not fully clear to me...are we still thinking of having ANDC, ORC, XORC suffixes or are the mnenomics now going to be expanded into this:
    GETPIN  D,#S WZ / WC
    GETNPIN D,#S WZ / WC
    GETBIT  D,#S WZ / WC
    GETNBIT D,#S WZ / WC
    
    ANDPIN  D,#S WZ / WC
    ANDNPIN D,#S WZ / WC
    ANDBIT  D,#S WZ / WC
    ANDNBIT D,#S WZ / WC
    
    ORPIN   D,#S WZ / WC
    ORNPIN  D,#S WZ / WC
    ORBIT   D,#S WZ / WC
    ORNBIT  D,#S WZ / WC
    
    XORPIN  D,#S WZ / WC
    XORNPIN D,#S WZ / WC
    XORBIT  D,#S WZ / WC
    XORNBIT D,#S WZ / WC
    

    What happens if you want to write both Z and C ? I guess that is not possible or desirable and so the assembler should flag it as an error?
  • evanhevanh Posts: 15,126
    rogloh wrote: »
    What happens if you want to write both Z and C ? I guess that is not possible or desirable and so the assembler should flag it as an error?

    That isn't allowed, but the encoding is available. That's the existing hole.

  • evanhevanh Posts: 15,126
    On that note, given the nature of the explicit flag write that these instructions are, it wouldn't be out of order to compact four opcodes into one by using each CZ bit encoding for one of the flag writes.

  • evanh wrote: »
    rogloh wrote: »
    What happens if you want to write both Z and C ? I guess that is not possible or desirable and so the assembler should flag it as an error?

    That isn't allowed, but the encoding is available. That's the existing hole.

    BITx/DIRx {WCZ} share the opcodes with TESTBx/TESTPx WC/WZ.

    Mmm, four pages and counting for something that probably wouldn't have gone past one with a macro assembler.
  • evanhevanh Posts: 15,126
    Lol, twice.

  • The end result Chip settled on was keeping everything the same as it is, EXCEPT changing TEST to GET.

    So there is just GETBIT/GETNBIT/GETPIN/GETNPIN instructions, and the WZ/ORZ/ANDZ/XORZ/WC/ORC/ANDC/XORC suffix things.
  • cgraceycgracey Posts: 14,133
    Roy Eltham wrote: »
    The end result Chip settled on was keeping everything the same as it is, EXCEPT changing TEST to GET.

    So there is just GETBIT/GETNBIT/GETPIN/GETNPIN instructions, and the WZ/ORZ/ANDZ/XORZ/WC/ORC/ANDC/XORC suffix things.

    Sounds good.
Sign In or Register to comment.