SFUNC question - Page 10 — Parallax Forums

# SFUNC question

• Posts: 5,613
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.
• Posts: 13,895
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.
• Posts: 13,895
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}
```
• Posts: 13,895
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
```
• Posts: 14,994
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
• Posts: 5,613
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
```
• Posts: 14,994
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.
• Posts: 5,613
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 .
• Posts: 13,895
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?
• Posts: 14,994
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 ?
• Posts: 13,895
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
```
• Posts: 14,994
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.

• Posts: 13,895
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
```
• Posts: 5,613
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.
• Posts: 14,994
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 ?

• 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...
• Posts: 14,994
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 ?

• Posts: 13,895
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.
• Posts: 14,994
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
```

• Posts: 13,895
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.
• Posts: 2,474
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)
```

• Posts: 13,895
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
```
• Posts: 14,994
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:
• Posts: 13,895
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?
• Posts: 10,246
X64 has something like 1700 instructions.
• Posts: 14,994
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 ?

• Posts: 13,895
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.
• Posts: 2,474
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?
• Posts: 854
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
• Posts: 14,025
Seairth wrote: »
What is BITRND?
That'll bit-sample the hardware pseudo-random generator.