Subject: SZC for idiots...

From: "Marc H" <[email-masked]>
Date: Tue, 03 Aug 2010 00:52:11 -0000

Could someone please drawn me a picture as to how SZC (Logical AND????) works.  I'm working and getting nowhere..... and please dumb it down a bit ;-)

---

From: ti99_forever <[email-masked]>
Date: Mon, 2 Aug 2010 21:26:23 -0700 (PDT)

Not a tutorial, but...

SZC sets the bits that are set to 1 in the flag word to 0 in the destination. This isn't the same as an AND, so you usually have to INVert the bits in the flag to get what you really want out of SZC. SZC can be interpreted as "Set the bits in the Destination to Zero that correspond to the bits set to One in the Flag word."

BTW: all off the top of me head... so take it with a pint!

--- On Mon, 8/2/10, Marc H <[email-masked]> wrote:

From: Marc H <[email-masked]>
Subject: [TI994A] SZC for idiots...
To: [email-masked]
Date: Monday, August 2, 2010, 8:52 PM

------------------------------------

Yahoo! Groups Links

---

From: "Tursi" <[email-masked]>
Date: Mon, 2 Aug 2010 22:34:44 -0700

> Could someone please drawn me a picture as to how SZC (Logical AND????) works.  I'm working and getting nowhere..... and please dumb it down a bit ;-)

I started a picture, but that takes too long. ;)

As Ben said, every bit set to 1 in the source word is zeroed in the destination word. Every bit set to 0 in the source word is ignored.

So (just using bytes here, these are binary):

S: 00001111
D: 01010101
---------------- SZC - bits set to '1' in the src are zeroed
    01010000

S:11110000
D:11111111
--------------- SZC - bits set to '1' in the src are zeroed
  00001111

S:0000000
D:01010101
---------------- SZC - no bits are set to '1' in the src, so no change
  01010101

S:11111111
D:01010101
--------------- SZC - all bits are set to '1' in the src, so all bits are zeroed
  00000000

Note that the original contents of destination are irrelevant, if the corresponding bit in the source is set, the result is 0.

---

From: mark wills <[email-masked]>
Date: Thu, 5 Aug 2010 12:48:46 +0000 (GMT)

SZC==NAND

?

>
>From: Tursi <[email-masked]>
>Sent: Tue, 3 August, 2010 6:34:44
>Subject: Re: [TI994A] SZC for idiots...
>
>  
>
>
>> Could someone please drawn me a picture as to how  SZC (Logical AND????) 
>>works.  I'm working and getting nowhere..... and  please dumb it down a bit ;-)
>> 
>
>As Ben said, every bit set to 1 in the source word is  zeroed in the destination 
>word. Every bit set to 0 in the source word is  ignored.
>
>Note that the original contents of destination are  irrelevant, if the 
>corresponding bit in the source is set, the result is  0.
> 
>
>
>

---

From: "Tursi" <[email-masked]>
Date: Thu, 5 Aug 2010 09:46:42 -0700

> SZC==NAND

No, especially because NAND is not concerned with the order of the input
bits. NAND is NOT-AND, it is an AND gate with an inverter attached. It may
help to see it in terms of single bits, so I'll give the binary truth tables
to compare, with descriptions.

This is the binary truth table for NAND (note / and - are used here as
separators, not math):

NAND: (src NAND dest = result)

0 NAND 0 = 1 --- 0 AND 0 is 0, NOT 0 is 1
0 NAND 1 = 1 --- 0 AND 1 is 0, NOT 0 is 1
1 NAND 0 = 1 --- 1 AND 0 is 0, NOT 0 is 1
1 NAND 1 = 0 --- 1 AND 1 is 1, NOT 1 is 0

SZC sets the result bit to zero if and only if the source bit is 1. So the
binary truth table for SZC is:

SZC: (src SZC dest = result)

0 SZC 0 = 0 --- Source is 0, so dest bit (0) is unchanged
0 SZC 1 = 1 --- Source is 0, so dest bit (1) is unchanged
1 SZC 0 = 0 --- Source is 1, so dest bit is set to zero, original value
irrelevant
1 SZC 1 = 0 --- Source is 1, so dest bit is set to zero, original value
irrelevant

The E/A manual and several other sources describes SZC as an AND with the
inverse of the source, which is true in that all cleared bits in the source
are left untouched in the destination, but I actually find that description
MORE confusing since it requires you to think of two steps. SZC is an
unusual instruction for its day in terms of what it does, but its actual
operation is pretty straightforward.

---

From: Marc Hull <[email-masked]>
Date: Thu, 5 Aug 2010 11:36:43 -0700 (PDT)

At any rate this is truly a command only an engineer could love ;-) 

--- On Thu, 8/5/10, Tursi <[email-masked]> wrote:

From: Tursi <[email-masked]>
Subject: Re: [TI994A] SZC for idiots...
To: [email-masked]
Date: Thursday, August 5, 2010, 11:46 AM

  

separators, not math):

irrelevant

irrelevant

---

From: "Jens-Eike Hartwig" <[email-masked]>
Date: Thu, 05 Aug 2010 21:26:22 +0200

Think of it as a selective CLR (clear all bits where the mask is 1).

GreeTIngs
Jens-Eike

---

From: tursi <[email-masked]>
Date: Thu, 5 Aug 2010 13:15:49 -0700 (PDT)

> At any rate this is truly a command only an engineer could love ;-)

TI's thinking was that it would be useful for setting and clearing bits in 
a bit mask.

The traditional way to do this is to use a mask, and the inverse of the 
mask, with OR and AND. For example, if you want to work with bit 3 from a 
byte (it doesn't matter, but I will use bit 0 as LSB), the traditional way 
would be something like this (mind the pseudocode):

SETMASK EQU >08
CLRMASK EQU >F7

SETBIT  OR @SETMASK,R0
         RT

CLRBIT  AND @SETMASK,R0
         RT

TI instead figured that rather than having to define two masks for the 
same flag, or having to invert it at runtime, they would simply give you 
two commands specifically intended to set and clear bits. So on the 9900, 
instead you could do:

MASK EQU >08

SETBIT SOC @MASK,R0
        RT

CLRBIT SZC @MASK,R0
        RT

SOC sets bits in the target to '1', and SZC sets bits in the target to 
'0'. Once I started thinking about them that way, and stopped trying to 
compare them to AND and OR instructions, they started to make a lot more 
sense to me. Yes, you can describe their behaviour using OR and AND 
(indeed the result of SOC is identical to OR), but this is not what the 
instructions actually do.

---

From: tursi <[email-masked]>
Date: Thu, 5 Aug 2010 13:18:39 -0700 (PDT)

> CLRBIT  AND @SETMASK,R0

Grr.. hopefully it was obvious this was supposed to AND using CLRMASK, not 
SETMASK on both of them. :)