P2 Instructions TESTB & TESTBN

124»

Comments

  • 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
    Formerly known as TonyB
  • GETBIT
    GETNBIT
    GETPIN
    GETNPIN
    Melbourne, Australia
  • cgraceycgracey Posts: 11,771
    edited 2018-12-11 - 00:50:34
    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.)
  • 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.
    Formerly known as TonyB
  • 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.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • Cluso99Cluso99 Posts: 15,474
    edited 2018-12-11 - 10:13:59
    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.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • 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.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Chip,
    It's fundamentally wrong. There's no way around it.
    So you may as well leave it as is :(
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • 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.

  • I agree, too.

    Do you guys think GETxxxx mnemonics would be better than the current TESTxxx mnemonics, though?
  • 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.
    SIDcog - The sound of the Commodore 64 in a single cog: Thread, OBEX
  • 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: 11,771
    edited 2018-12-11 - 15:02:15
    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: 11,771
    edited 2018-12-11 - 15:17:56
    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: 15,474
    edited 2018-12-11 - 20:02:12
    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.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • Just had a horrible thought...
    What about GETNIB etc WZ/WC/WCZ ?

    Fortunately, there are no WZ/WC/WCZ options for GETNIB etc :)
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • 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.
  • 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.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • roglohrogloh Posts: 1,456
    edited 2018-12-12 - 00:26:43
    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?
  • 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.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • 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.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • 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.
    Formerly known as TonyB
  • Lol, twice.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • 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.
  • 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.