Shop OBEX P1 Docs P2 Docs Learn Events
SFUNC question - Page 10 — Parallax Forums

SFUNC question

178101213

Comments

  • ersmithersmith Posts: 5,900
    edited 2017-05-04 23:55
    The only thing I'm a little nervous about with changing the BITx instructions so that they can no longer read the previous instruction's state is that we may be losing some useful functionality. An atomic "set bit and test previous value" can be useful for semaphores around interrupts and such. Will it get used a lot? Probably not, but then these particular bit operations may not be much either.

    Let's look at what we can do now (v18) in one instruction:
    testb $, #18 wc   ' C := 1, immediate bit is always set
    testb $, #23 wc   ' C := 0, assuming the encoding of testb does not change
    testb X, Y wc     ' C := X.Y
    if_c  testb X,Y wc ' C := C AND X.Y
    if_nc testb X,Y wc ' C := C OR X.Y
    
    What's not so convenient are C := !C (it can sometimes be faked by using Z as a proxy for !C, as we saw above) and C := Z. I think the MODCZ instruction can handle both of those, as well as most operations between C and Z, so it seems like with that we'll be in pretty good shape.
  • cgraceycgracey Posts: 14,133
    edited 2017-05-04 23:55
    Jmg,

    It would always compute the logical function for both C and Z, then write each as directed by WC/WZ. This gets redundancy out of the syntax. Also, it allows the operand to be just D,{#}S.
  • cgraceycgracey Posts: 14,133
    This encoding can be used for not just BITx, but the other four pin-related DIRx/OUTx/FLTx/DRVx instruction blocks:
    EEEE 0100000 00I DDDDDDDDD SSSSSSSSS        BITL    D,S/#
    EEEE 0100000 CZI DDDDDDDDD SSSSSSSSS        BITAND  D,S/#       {WC,WZ}
    EEEE 0100001 00I DDDDDDDDD SSSSSSSSS        BITH    D,S/#
    EEEE 0100001 CZI DDDDDDDDD SSSSSSSSS        BITANDN D,S/#       {WC,WZ}
    EEEE 0100010 00I DDDDDDDDD SSSSSSSSS        BITC    D,S/#
    EEEE 0100010 CZI DDDDDDDDD SSSSSSSSS        BITOR   D,S/#       {WC,WZ}
    EEEE 0100011 00I DDDDDDDDD SSSSSSSSS        BITNC   D,S/#
    EEEE 0100011 CZI DDDDDDDDD SSSSSSSSS        BITORN  D,S/#       {WC,WZ}
    EEEE 0100100 00I DDDDDDDDD SSSSSSSSS        BITZ    D,S/#
    EEEE 0100100 CZI DDDDDDDDD SSSSSSSSS        BITXOR  D,S/#       {WC,WZ}
    EEEE 0100101 00I DDDDDDDDD SSSSSSSSS        BITNZ   D,S/#
    EEEE 0100101 CZI DDDDDDDDD SSSSSSSSS        BITXORN D,S/#       {WC,WZ}
    EEEE 0100110 00I DDDDDDDDD SSSSSSSSS        BITN    D,S/#
    EEEE 0100110 CZI DDDDDDDDD SSSSSSSSS        BITGET  D,S/#       {WC,WZ}
    EEEE 0100111 00I DDDDDDDDD SSSSSSSSS        BITRND  D,S/#
    EEEE 0100111 CZI DDDDDDDDD SSSSSSSSS        BITGETN D,S/#       {WC,WZ}
    
  • cgraceycgracey Posts: 14,133
    edited 2017-05-05 00:14
    Here they are, split apart into bit writes and flag writes:
    EEEE 0100000 00I DDDDDDDDD SSSSSSSSS        BITL    D,S/#		'bit := 0
    EEEE 0100001 00I DDDDDDDDD SSSSSSSSS        BITH    D,S/#		'bit := 1
    EEEE 0100010 00I DDDDDDDDD SSSSSSSSS        BITC    D,S/#		'bit := C
    EEEE 0100011 00I DDDDDDDDD SSSSSSSSS        BITNC   D,S/#		'bit := !C
    EEEE 0100100 00I DDDDDDDDD SSSSSSSSS        BITZ    D,S/#		'bit := Z
    EEEE 0100101 00I DDDDDDDDD SSSSSSSSS        BITNZ   D,S/#		'bit := !Z
    EEEE 0100110 00I DDDDDDDDD SSSSSSSSS        BITN    D,S/#		'bit := !bit
    EEEE 0100111 00I DDDDDDDDD SSSSSSSSS        BITRND  D,S/#		'bit := rnd
    
    EEEE 0100000 CZI DDDDDDDDD SSSSSSSSS        BITAND  D,S/#    {WC,WZ}	'WC/WZ &=  bit
    EEEE 0100001 CZI DDDDDDDDD SSSSSSSSS        BITANDN D,S/#    {WC,WZ}	'WC/WZ &= !bit
    EEEE 0100010 CZI DDDDDDDDD SSSSSSSSS        BITOR   D,S/#    {WC,WZ}	'WC/WZ |=  bit
    EEEE 0100011 CZI DDDDDDDDD SSSSSSSSS        BITORN  D,S/#    {WC,WZ}	'WC/WZ |= !bit
    EEEE 0100100 CZI DDDDDDDDD SSSSSSSSS        BITXOR  D,S/#    {WC,WZ}	'WC/WZ ^=  bit
    EEEE 0100101 CZI DDDDDDDDD SSSSSSSSS        BITXORN D,S/#    {WC,WZ}	'WC/WZ ^= !bit
    EEEE 0100110 CZI DDDDDDDDD SSSSSSSSS        BITGET  D,S/#    {WC,WZ}	'WC/WZ :=  bit
    EEEE 0100111 CZI DDDDDDDDD SSSSSSSSS        BITGETN D,S/#    {WC,WZ}	'WC/WZ := !bit
    
  • jmgjmg Posts: 15,140
    edited 2017-05-05 00:22
    cgracey wrote: »
    It would always compute the logical function for both C and Z, then write each as directed by WC/WZ. This gets redundancy out of the syntax. Also, it allows the operand to be just D,{#}S.
    So you mean the legal operands suffix are {WC} , {WZ}, {WC,WZ}, but {} is illegal ? (what actually happens?)
    That would mean this opcode can do this, right ?
    EEEE 0100001 CZI DDDDDDDDD SSSSSSSSS        ANDFN   D,S/#       {WC,WZ}
    
    C = Bitname AND !C
    Z = Bitname AND !Z
    (and both of the above, should anyone need that ... )
    but not 
    Bitname = Bitname AND !C
    Bitname = Bitname AND !Z
    

    Addit: Ah, I see from the grouping above, the {} case is borrowed for another opcode. That's one question sorted.
    BITANDN {} -> BITH
  • Ah, actually we *can* already do NOT (and XOR) in one instruction. It does require a scratch register to be set to a known value:
    one	long 1
    ' set C := !C
    	cmpx one, #1  wc ' if C = 0, one < 1+C is true, so C := 1
    	                 ' if C = 1, one < 1+C is false, so C := 0
    
    Having that predefined register around also makes the C:=1 and C:=0 cases much clearer.
    So maybe everything we need is already in v18.

    I still like the MODCZ instruction, it could be very handy.

    I don't like the idea of changing the way the wc,wz flags work for the BIT instructions. It's not orthogonal, and it gets rid of potentially useful functionality. Besides, a lot of those "new" instructions are redundant, e.g. BITAND X,Y wc is:
      if_c testb X,Y wc
    
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    Let's look at what we can do now (v18) in one instruction:
    testb $, #18 wc   ' C := 1, immediate bit is always set
    testb $, #23 wc   ' C := 0, assuming the encoding of testb does not change
    testb X, Y wc     ' C := X.Y
    if_c  testb X,Y wc ' C := C AND X.Y
    if_nc testb X,Y wc ' C := C OR X.Y
    one	long 1
    ' set C := !C
    	cmpx one, #1  wc ' if C = 0, one < 1+C is true, so C := 1
    	                 ' if C = 1, one < 1+C is false, so C := 0
    
    All these examples are clever gymnastics, but rather illustrate the problem.

    How would a first year student decode any of these ?

    Ideally, source code should be 'read at a glance' stuff, and easy to maintain.

    I think my favorite is this one, for CLR C
    testb $, #23 wc   ' C := 0, assuming the encoding of testb does not change
    

    The full bit instructions did deliver 'read at a glance', all these 'hey, look what we can do' gymnastics, just prove what has been lost.
  • jmg wrote: »
    All these examples are clever gymnastics, but rather illustrate the problem.

    How would a first year student decode any of these ?

    Ideally, source code should be 'read at a glance' stuff, and easy to maintain.
    Which is why we'd want to use macros for these, or even add them as instructions in PASM, or put them in a compiler. All of the details can be hidden. The architecture is capable of a vast amount of things that we haven't even scratched the surface of. Unfortunately, until we get silicon it is all moot :(.
  • cgraceycgracey Posts: 14,133
    Ersmith,

    It looks like we can do all kinds of logical operations on register bits with conditionals, but the ability to accumulate logical results, as you go, into C and Z is very limited. Do you agree?

    All we would miss by having WC/WZ change the BITxxx bit writes into flag writes would be that the bit writes would not report back the prior state of the bit. However, if both WC and WZ are expressed for a bit-write instruction, we could have the prior state written back to C and NZ. Would that give you much indigestion?
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    All we would miss by having WC/WZ change the BITxxx bit writes into flag writes would be that the bit writes would not report back the prior state of the bit. However, if both WC and WZ are expressed for a bit-write instruction, we could have the prior state written back to C and NZ. Would that give you much indigestion?
    Does TESTB still exist ? That lets you read a Bool State into C,NZ ? So covers that rather rare case with one more line.

    Does this new scheme still lose the group of
    Bitname = Bitname AND !C
    Bitname = Bitname AND !Z
    that were available in full bit instructions ?
  • cgraceycgracey Posts: 14,133
    edited 2017-05-05 01:47
    jmg wrote: »
    cgracey wrote: »
    All we would miss by having WC/WZ change the BITxxx bit writes into flag writes would be that the bit writes would not report back the prior state of the bit. However, if both WC and WZ are expressed for a bit-write instruction, we could have the prior state written back to C and NZ. Would that give you much indigestion?
    Does TESTB still exist ? That lets you read a Bool State into C,NZ ? So covers that rather rare case with one more line.

    Does this new scheme still lose the group of
    Bitname = Bitname AND !C
    Bitname = Bitname AND !Z
    that were available in full bit instructions ?

    The "Bitname = Bitname AND !C" type stuff is gone. However, those can be more than recreated through conditionals:
    IF_NC	BITL	D,S		'bit &= C
    IF_C	BITL	D,S		'bit &= !C
    
    IF_C	BITH	D,S		'bit |= C
    IF_NC	BITH	D,S		'bit |= !C
    
    IF_C	BITN	D,S		'bit ^= C
    IF_NC	BITN	D,S		'bit ^= !C
    
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    The "Bitname = Bitname AND !C" type stuff is gone. However, those can be more than recreated through conditionals:
    IF_NC	BITL	D,S		'bit &= C
    IF_C	BITL	D,S		'bit &= !C
    
    IF_C	BITH	D,S		'bit |= C
    IF_NC	BITH	D,S		'bit |= !C
    
    IF_C	BITN	D,S		'bit ^= C
    IF_NC	BITN	D,S		'bit ^= !C
    

    Ah, ok, - I guess I can quote Eric here...
    ersmith wrote: »
    Which is why we'd want to use macros for these, or even add them as instructions in PASM, or put them in a compiler. All of the details can be hidden.

  • cgraceycgracey Posts: 14,133
    edited 2017-05-05 02:15
    Conditionals allow C-with-Z functions to affect register bits:
    IF_C_NE_Z	BITN	D,S		'bit ^= C ^ Z
    
  • cgracey wrote: »
    All we would miss by having WC/WZ change the BITxxx bit writes into flag writes would be that the bit writes would not report back the prior state of the bit. However, if both WC and WZ are expressed for a bit-write instruction, we could have the prior state written back to C and NZ. Would that give you much indigestion?

    I guess there are other ways to do atomic read/modify, as long as MUXC and the other logical operations can still report back the previous bit state. So it's not a deal breaker. Personally I find the new use of wc,wz a bit weird, but maybe I just haven't wrapped my head around it. It also seems like we're adding a lot of new instructions / special cases for a feature that conceptually seems like it shouldn't need that many.

    If we had a TESTNB instruction maybe we could achieve the logical operations with conditionals the way you indicated above? I'm not sure. It seems like it's the NOT case that's the awkward one.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Here they are, split apart into bit writes and flag writes:
    Next obvious question I guess, is do these compile to smaller/same/larger Logic than the full bit instructions ?

  • SeairthSeairth Posts: 2,474
    edited 2017-05-05 02:29
    cgracey wrote: »
    jmg wrote: »
    cgracey wrote: »
    All we would miss by having WC/WZ change the BITxxx bit writes into flag writes would be that the bit writes would not report back the prior state of the bit. However, if both WC and WZ are expressed for a bit-write instruction, we could have the prior state written back to C and NZ. Would that give you much indigestion?
    Does TESTB still exist ? That lets you read a Bool State into C,NZ ? So covers that rather rare case with one more line.

    Does this new scheme still lose the group of
    Bitname = Bitname AND !C
    Bitname = Bitname AND !Z
    that were available in full bit instructions ?

    The "Bitname = Bitname AND !C" type stuff is gone. However, those can be more than recreated through conditionals:
    IF_NC	BITL	D,S		'bit &= C
    IF_C	BITL	D,S		'bit &= !C
    
    IF_C	BITH	D,S		'bit |= C
    IF_NC	BITH	D,S		'bit |= !C
    
    IF_C	BITN	D,S		'bit ^= C
    IF_NC	BITN	D,S		'bit ^= !C
    

    Also
    IF_C	BITX D,S WC		'C &= bit
    IF_NC	BITX D,S WC		'C |= bit
    

    Nothing for XOR or !bit, though...
  • jmgjmg Posts: 15,140
    Seairth wrote: »
    IF_C	BITX D,S WC		'C &= bit
    IF_NC	BITX D,S WC		'C |= bit
    
    Aren't those destructive of D ?
    I think the new BITGET can do atomic, one bit, non destructive read ?

  • cgraceycgracey Posts: 14,133
    These new BITx instructions are a lot of mnemonics, but very little logic.

    I thought, too, that TESTNB would probably solve most of the problem. It's easy to accumulate ANDs and ORs with complementary reads, but XOR is maybe still difficult.
  • jmgjmg Posts: 15,140
    edited 2017-05-05 02:42
    ersmith wrote: »
    If we had a TESTNB instruction maybe we could achieve the logical operations with conditionals the way you indicated above?
    Does the new/proposed? BITGET/BITGETN offering not do this ? Does this now replace TESTB ?
    EEEE 0100110 CZI DDDDDDDDD SSSSSSSSS        BITGET  D,S/#    {WC,WZ}	'WC/WZ :=  bit
    EEEE 0100111 CZI DDDDDDDDD SSSSSSSSS        BITGETN D,S/#    {WC,WZ}	'WC/WZ := !bit
    

  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    ersmith wrote: »
    If we had a TESTNB instruction maybe we could achieve the logical operations with conditionals the way you indicated above?
    Does the new/proposed? BITGET/BITGETN offering not do this ? Does this now replace TESTB ?
    EEEE 0100110 CZI DDDDDDDDD SSSSSSSSS        BITGET  D,S/#    {WC,WZ}	'WC/WZ :=  bit
    EEEE 0100111 CZI DDDDDDDDD SSSSSSSSS        BITGETN D,S/#    {WC,WZ}	'WC/WZ := !bit
    

    That's correct. No need for TESTB/TESTBN, anymore.
  • cgracey wrote: »
    jmg wrote: »
    ersmith wrote: »
    If we had a TESTNB instruction maybe we could achieve the logical operations with conditionals the way you indicated above?
    Does the new/proposed? BITGET/BITGETN offering not do this ? Does this now replace TESTB ?
    EEEE 0100110 CZI DDDDDDDDD SSSSSSSSS        BITGET  D,S/#    {WC,WZ}	'WC/WZ :=  bit
    EEEE 0100111 CZI DDDDDDDDD SSSSSSSSS        BITGETN D,S/#    {WC,WZ}	'WC/WZ := !bit
    

    That's correct. No need for TESTB/TESTBN, anymore.

    Okay. I'm obviously still behind on the changes. Does this mean we now have:
    BITL
    BITH
    BITC
    BITNC
    BITZ
    BITNZ
    BITGET  (was opcode for BITN)
    BITGETN (was opcode for BITX)
    

  • cgraceycgracey Posts: 14,133
    Seairth,

    If I implement this stuff, which would take about an hour, we'll have these:
    EEEE 0100000 00I DDDDDDDDD SSSSSSSSS        BITL    D,S/#		'bit := 0
    EEEE 0100001 00I DDDDDDDDD SSSSSSSSS        BITH    D,S/#		'bit := 1
    EEEE 0100010 00I DDDDDDDDD SSSSSSSSS        BITC    D,S/#		'bit := C
    EEEE 0100011 00I DDDDDDDDD SSSSSSSSS        BITNC   D,S/#		'bit := !C
    EEEE 0100100 00I DDDDDDDDD SSSSSSSSS        BITZ    D,S/#		'bit := Z
    EEEE 0100101 00I DDDDDDDDD SSSSSSSSS        BITNZ   D,S/#		'bit := !Z
    EEEE 0100110 00I DDDDDDDDD SSSSSSSSS        BITN    D,S/#		'bit := !bit
    EEEE 0100111 00I DDDDDDDDD SSSSSSSSS        BITRND  D,S/#		'bit := rnd
    
    EEEE 0100000 CZI DDDDDDDDD SSSSSSSSS        BITAND  D,S/#    {WC,WZ}	'WC/WZ &=  bit
    EEEE 0100001 CZI DDDDDDDDD SSSSSSSSS        BITANDN D,S/#    {WC,WZ}	'WC/WZ &= !bit
    EEEE 0100010 CZI DDDDDDDDD SSSSSSSSS        BITOR   D,S/#    {WC,WZ}	'WC/WZ |=  bit
    EEEE 0100011 CZI DDDDDDDDD SSSSSSSSS        BITORN  D,S/#    {WC,WZ}	'WC/WZ |= !bit
    EEEE 0100100 CZI DDDDDDDDD SSSSSSSSS        BITXOR  D,S/#    {WC,WZ}	'WC/WZ ^=  bit
    EEEE 0100101 CZI DDDDDDDDD SSSSSSSSS        BITXORN D,S/#    {WC,WZ}	'WC/WZ ^= !bit
    EEEE 0100110 CZI DDDDDDDDD SSSSSSSSS        BITGET  D,S/#    {WC,WZ}	'WC/WZ :=  bit
    EEEE 0100111 CZI DDDDDDDDD SSSSSSSSS        BITGETN D,S/#    {WC,WZ}	'WC/WZ := !bit
    
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    If I implement this stuff, which would take about an hour, we'll have these:
    Can you do a similar table around these too, related to this comment ?
    cgracey wrote: »
    This encoding can be used for not just BITx, but the other four pin-related DIRx/OUTx/FLTx/DRVx instruction blocks:
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    If I implement this stuff, which would take about an hour, we'll have these:
    Can you do a similar table around these too, related to this comment ?
    cgracey wrote: »
    This encoding can be used for not just BITx, but the other four pin-related DIRx/OUTx/FLTx/DRVx instruction blocks:

    Imagine the same thing with BITx done to all of those other four blocks. Hey, were you going to point out that would be 40 new mnemonics?
  • X64 has something like 1700 instructions.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    ..
    This encoding can be used for not just BITx, but the other four pin-related DIRx/OUTx/FLTx/DRVx instruction blocks:
    ..
    Imagine the same thing with BITx done to all of those other four blocks.
    I fear I'll imagine up the wrong operation.
    I can see OUTxx for example has a Boolean destination, which is one of 64 port pins.
    With the BITOP Logical group, rules look to be {} changes the opcode, and WC or WZ writes to only C or Z.
    Not quite sure how to apply those new rules, to an output pin ?

  • cgraceycgracey Posts: 14,133
    edited 2017-05-05 10:12
    Okay. I've got everything working.

    Here is the new BITx instruction block:
    EEEE 0100000 CZI DDDDDDDDD SSSSSSSSS    *   BITAND  D,S/#       {WC,WZ required}
    EEEE 0100001 CZI DDDDDDDDD SSSSSSSSS    *   BITANDN D,S/#       {WC,WZ required}
    EEEE 0100010 CZI DDDDDDDDD SSSSSSSSS    *   BITOR   D,S/#       {WC,WZ required}
    EEEE 0100011 CZI DDDDDDDDD SSSSSSSSS    *   BITORN  D,S/#       {WC,WZ required}
    EEEE 0100100 CZI DDDDDDDDD SSSSSSSSS    *   BITXOR  D,S/#       {WC,WZ required}
    EEEE 0100101 CZI DDDDDDDDD SSSSSSSSS    *   BITXORN D,S/#       {WC,WZ required}
    EEEE 0100110 CZI DDDDDDDDD SSSSSSSSS    *   BITEST  D,S/#       {WC,WZ required}
    EEEE 0100111 CZI DDDDDDDDD SSSSSSSSS    *   BITESTN D,S/#       {WC,WZ required}
    
    EEEE 0100000 00I DDDDDDDDD SSSSSSSSS    *   BITL    D,S/#
    EEEE 0100001 00I DDDDDDDDD SSSSSSSSS    *   BITH    D,S/#
    EEEE 0100010 00I DDDDDDDDD SSSSSSSSS    *   BITC    D,S/#
    EEEE 0100011 00I DDDDDDDDD SSSSSSSSS    *   BITNC   D,S/#
    EEEE 0100100 00I DDDDDDDDD SSSSSSSSS    *   BITZ    D,S/#
    EEEE 0100101 00I DDDDDDDDD SSSSSSSSS    *   BITNZ   D,S/#
    EEEE 0100110 00I DDDDDDDDD SSSSSSSSS    *   BITRND  D,S/#
    EEEE 0100111 00I DDDDDDDDD SSSSSSSSS    *   BITNOT  D,S/#
    

    Here is the new pin operations instruction block:
    EEEE 1101011 CZL DDDDDDDDD 001000000    *   INAND   D/#         {WC,WZ required}
    EEEE 1101011 CZL DDDDDDDDD 001000001    *   INANDN  D/#         {WC,WZ required}
    EEEE 1101011 CZL DDDDDDDDD 001000010    *   INOR    D/#         {WC,WZ required}
    EEEE 1101011 CZL DDDDDDDDD 001000011    *   INORN   D/#         {WC,WZ required}
    EEEE 1101011 CZL DDDDDDDDD 001000100    *   INXOR   D/#         {WC,WZ required}
    EEEE 1101011 CZL DDDDDDDDD 001000101    *   INXORN  D/#         {WC,WZ required}
    EEEE 1101011 CZL DDDDDDDDD 001000110    *   INTEST  D/#         {WC,WZ required}
    EEEE 1101011 CZL DDDDDDDDD 001000111    *   INTESTN D/#         {WC,WZ required}
    
    EEEE 1101011 00L DDDDDDDDD 001000000    *   DIRL    D/#
    EEEE 1101011 00L DDDDDDDDD 001000001    *   DIRH    D/#
    EEEE 1101011 00L DDDDDDDDD 001000010    *   DIRC    D/#
    EEEE 1101011 00L DDDDDDDDD 001000011    *   DIRNC   D/#
    EEEE 1101011 00L DDDDDDDDD 001000100    *   DIRZ    D/#
    EEEE 1101011 00L DDDDDDDDD 001000101    *   DIRNZ   D/#
    EEEE 1101011 00L DDDDDDDDD 001000110    *   DIRRND  D/#
    EEEE 1101011 00L DDDDDDDDD 001000111    *   DIRNOT  D/#
    
    EEEE 1101011 00L DDDDDDDDD 001001000    *   OUTL    D/#
    EEEE 1101011 00L DDDDDDDDD 001001001    *   OUTH    D/#
    EEEE 1101011 00L DDDDDDDDD 001001010    *   OUTC    D/#
    EEEE 1101011 00L DDDDDDDDD 001001011    *   OUTNC   D/#
    EEEE 1101011 00L DDDDDDDDD 001001100    *   OUTZ    D/#
    EEEE 1101011 00L DDDDDDDDD 001001101    *   OUTNZ   D/#
    EEEE 1101011 00L DDDDDDDDD 001001110    *   OUTRND  D/#
    EEEE 1101011 00L DDDDDDDDD 001001111    *   OUTNOT  D/#
    
    EEEE 1101011 00L DDDDDDDDD 001010000    *   FLTL    D/#
    EEEE 1101011 00L DDDDDDDDD 001010001    *   FLTH    D/#
    EEEE 1101011 00L DDDDDDDDD 001010010    *   FLTC    D/#
    EEEE 1101011 00L DDDDDDDDD 001010011    *   FLTNC   D/#
    EEEE 1101011 00L DDDDDDDDD 001010100    *   FLTZ    D/#
    EEEE 1101011 00L DDDDDDDDD 001010101    *   FLTNZ   D/#
    EEEE 1101011 00L DDDDDDDDD 001010110    *   FLTRND  D/#
    EEEE 1101011 00L DDDDDDDDD 001010111    *   FLTNOT  D/#
    
    EEEE 1101011 00L DDDDDDDDD 001011000    *   DRVL    D/#
    EEEE 1101011 00L DDDDDDDDD 001011001    *   DRVH    D/#
    EEEE 1101011 00L DDDDDDDDD 001011010    *   DRVC    D/#
    EEEE 1101011 00L DDDDDDDDD 001011011    *   DRVNC   D/#
    EEEE 1101011 00L DDDDDDDDD 001011100    *   DRVZ    D/#
    EEEE 1101011 00L DDDDDDDDD 001011101    *   DRVNZ   D/#
    EEEE 1101011 00L DDDDDDDDD 001011110    *   DRVRND  D/#
    EEEE 1101011 00L DDDDDDDDD 001011111    *   DRVNOT  D/#
    

    These INx instructions let you read the INA/INB bits and do logic ops into the flags. The DIRx/OUTx/FLTx/DRVx instructions affect the DIRA/DIRB/OUTA/OUTB bits, but not the flags.
  • cgracey wrote: »
    Okay. I've got everything working.

    Here is the new BITx instruction block...

    A few questions:

    Is the assembler going to enforce the requirement/restriction of WC/WZ based on mnemonic?

    Are BITAND, etc. updating D or the flag(s)? If it's the flags, maybe use "CZ" prefix instead of "BIT"?

    I see BITEST/BITESTN instead of BITGET/BITGETN. Is that correct?

    What is BITRND?
  • dMajodMajo Posts: 855
    edited 2017-05-05 13:48
    cgracey wrote: »
    Okay. I've got everything working.

    Here is the new BITx instruction block:
    ...

    Here is the new pin operations instruction block:
    ...

    These INx instructions let you read the INA/INB bits and do logic ops into the flags. The DIRx/OUTx/FLTx/DRVx instructions affect the DIRA/DIRB/OUTA/OUTB bits, but not the flags.

    I do not know how the opcodes have to be optimized and waht is behind the production of a good working set.
    But after all this discussions, and with some inspiration from other environments, I would love it to be possible to have all this in the effect field like (taken from prior post):
    cgracey wrote: »
    With the proposed ANDF/ANDFN instructions, this:
    HeaterPin := (MinTemp < Temp < MaxTemp) AND HeaterON AND NOT ThermalTrip OR TestPin
    

    could be realized as:
    		CMP	Temp,MaxTemp		WC
    		CMP	MinTemp,Temp		AC
    		BIT	Flags,#HeaterOn		AC
    		BITN	Flags,#ThermalTrip	AC
    		BIT	Flags,#TestPin		OC
    		DRVC	#HeaterPin
    

    where
    WC sets C from instruction
    AC ands prior C with instruction C
    OC ors C with instructin C
    XC xors C with instruction C
    conditionals works the same way of course
  • evanhevanh Posts: 15,126
    Seairth wrote: »
    What is BITRND?
    That'll bit-sample the hardware pseudo-random generator.
Sign In or Register to comment.