Jump to content
IGNORED

CZC kicks butt (one for the assembler freaks!)


Willsy

Recommended Posts

Can I just say, the CZC instruction freaking rocks. For many years, whenever I felt I need to use CZC or COC I would have to read up on them in the editor assembler manual. Especially CZC. But, when the penny drops (it's only taken circa 25 years in my case!) you realise what awesome instructions they are!

Link to comment
Share on other sites

Really? Hm, I wrote up a complaint about these instructions on my CRPG site once, I'll reprint it here:

 

---

 

There's one opcode in particular in TMS9900 assembly language that never fails to annoy me. I've had multiple issues with it in my design efforts, eventually leading to me to use other approaches in most cases.

The opcode? COC, or Compare Ones Cooresponding. (And it's sibling, Compare Zeros Cooresponding for similar reasons.)

The first problem with this opcode is that it has no byte equivalent form. Many times my code has returned a "syntax error" on compilation, because I errantly threw in a COCB... which doesn't exist.

The second problem is that it only allows register-to-register or memory-to-register comparisons. Another error code I kept seeing was "invalid register"... which happens because I tried to do a memory-to-memory compare.

Okay, so everyone makes mistakes. But in this instance, it seems like this particular opcode is really useless in many situations where it could actually be useful.

Consider the normal compare © instruction. It has a byte-vector (CB) and it also lets you do all four potential variants of source/destination. (R->R, R->M, M->R, and M->M) It's only natural to assume that COC has this functionality, and yet it doesn't.

Then also consider the SOC and SZC opcodes. (Set Ones and Zeroes Cooresponding) These have byte-vectors. These work on all four variants. So the message here is, be invasive all you want, but you can only passively check it in one manner?

The other issue is when I need to check bit values, the fact I need to use a register means I don't really save much time or memory using COC.

Consider this example. I have a value in the symbolic address @ARRAY+4 that I need to check if the high-bit (>80) is on or off. Using COC, I may do it like this:

       LI   R1,>8000       MOV  @ARRAY+4,R0       COC  R1,R0       JEQ  ELSEWR

Still, it seems wasteful to set up a register (R1) just to get that bit. So you could also do it like this to save an instruction, at the cost of a bit of speed on the COC comparison:

FILTER DATA >8000       MOV  @ARRAY+4,R0       COC  @FILTER,R0       JEQ  ELSEWR

So, there's one way to use COC. But, if you MUST use a register to get the value you want to check, why not do it like this?

       MOV  @ARRAY+4,R0       ANDI R0,>8000       JNE  ELSEWR

Using immediate values is nearly always faster than memory words, because the CPU only has to do a single access back to memory to retrieve the value. For symbolic memory addresses, it has to fetch the address, THEN fetch the value at the address.

Also, I'm taking advantage of the fact that the CPU is doing a comparison every time it performs an operation anyway. If, after AND'ing the value the equality bit in the status register is one, that means the bit wasn't set. Otherwise, it was (thus not equal to zero) and we can do our jump.

About the only time I can see using COC is if you already have a value in a register you need to check, so the move isn't necessary. It is also useful in that it preserves the word being checked, unlike the AND operation above, if you need to check it multiple times.

 

Adamantyr

Link to comment
Share on other sites

About the only time I can see using COC is if you already have a value in a register you need to check, so the move isn't necessary. It is also useful in that it preserves the word being checked, unlike the AND operation above, if you need to check it multiple times.

Boom. There you go! You nailed it. As a result of discussions between Lee and I off-line, regarding keyboard scanning, I've (finally) come to appreciate the utility of these instructions.

 

Your comments regarding the addressing constraints is very valid. It's a side effect of the instruction group that they are in. They are Format III instructions, whereas SOC, SZC et al are Format I instructions (by the way, I had to look that up :-D ). I guess they couldn't fit everything into Format I.

 

Nice to see you posting. You lurk too much ;)

Edited by Willsy
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...