[jsa]

The opcode names differ a little, but 806x address modes are EXACTLY the same.
.
.
.
I hope that makes sense !

Not quite.

It appears to me the operands are in opposite order comparing the MCS-96 docs to Ford Handbook.

ADD AX,BX; AX <-- AX + BX

First operand equals first operand plus second operand.

ADD2W RA,RB; RB <-- RA + RB

Second operand equals first operand plus second operand.

[tvrfan]

The last operand is normally the 'target', as per my examples..... the only example I can think of which isn't is STW and STB which are reverse of LDW and STB.
I turn the operands around in my pseudo code listings to read like standard maths.

also for 2 operands it would typically read something like R8 += R12 which is shorthand for R8 = R8 + R12

[sailorbob]

Not quite.

It appears to me the operands are in opposite order comparing the MCS-96 docs to Ford Handbook.

tvrfan said the addressing modes are the same. What you are querying is the operand order, a different thing.

ADD2W RA,RB; RB <-- RA + RB

I cannot recall see the ADD2W RA,RB being shown in any 8061 documentation with the operation as you've shown it; is it an example you created?

The RB <-- RA + RB is correct though. For your example of "add 2 words" this is based upon the program containing opcode operand operand where the first operand is RA and the second operand containing RB. When written in assembly language you would have AD2W RB,RA.

[jsa]

What you are querying is the operand order, a different thing.

OK, thanks.

is it an example you created?

I should have written AD2W
See attached.

Thanks for the additional explanation TVRfan.

I found the 5 byte opcode like AD2W a bit of a head scratcher as far as the operand sequence goes. Working it out from the MCS-96 docs and Ford Handbook alone seems very challenging.

[tvrfan]

John,

There's a couple of things here .....

First, let me say YES - it IS very confusing to have different sizes of ops, and even worse when some options use an odd 'register' value. Frankly, I think it's a pain in the arse. If all ops were the same size, it would be *FAR* easier to decode, just for starters. Unfortunately in the olden days of computing, space was much more at a premium, and RAM cost a lot of money, clock speeds lower, so stuff was squeezed into small spaces for speed and compactness.

Operands - some operations are 'commutative', which means order independent. For example, addition, A+B = B+A; this also applies for multiplication.
This is not true for subtraction or divison of course, B-A != A-B . I say this little thing in case it helps, it's quite possible that pocket guide actually has a couple of things in the wrong order, it doesn't matter in many cases, but will confuse the poor learner.

What I did in SAD was to have a master operand table (you will see that in source code I posted), and it defines what goes where in terms of operands, size, and other stuff.
It's actually got quite a bit of info in that structure, necessary to decode correctly, and even then it still needs some 'C' code for the final details. It's not at all simple.

Generally - I believe these are always true (someone correct me if I'm wrong !!)

The last operand in the opcode sequence (=byte) is ALWAYS the destination register, except for STW, STB. [obviously not for jumps,ret, etc]
For 3 op operands, e.g. AD3W, the last two bytes are always registers, with last as destination.
The multimode opcodes (as example above) the 'option' always starts at the first operand, (be that an immediate, register, or indexed/ indirect address) .
Jump offsets are always relative to the start of next opcode (plus or minus as relevant).

Hope that helps a bit, no easy answer..

[jsa]

Here's an example for LDB opcode..... there are 6 variants ... used same params as much as possible to show differences

Code: Select all

b0,a1,08           ldb   R8,Ra1     R8 = Ra1;          # register to register, byte

b1,a1,08           ldb   R8,a1       R8 = a1;           # immediate value 

b2,a0,08           ldb   R8,[Ra0]   R8 = [Ra0];        # indirect  (address pointed to by Ra0) 

b2,a1,08           ldb   R8,[Ra0++]  R8 = [Ra0++];    # indirect with increment 

b3,a0,53,08        ldb   R8,[Ra0+53]  R8 = [Ra0+53]   # short indexed address  

b3,a1,53,03,08    ldb   R8,[Ra0+353]  R8 = [Ra0+353] # long indexed address

[Ra0 + 53] is 'address pointed to by what's in Ra0 Plus 0x53'

and of course if it's an address it's a WORD, so [Ra0] is actually address value in Ra1,Ra0, which if you think about it, is why designers can use lowest bit (i.e. odd value)
as a further option.....

Consider;

Code: Select all

77,FF,D4,00,00      # AD2B Zero Indexed, Odd so Long Indexed
                            # Byte[FF]=Byte[Address[FE FF] + 0x00D4] is how I perceive it might work

or

Code: Select all

77,6A,1F,00         # AD2B Zero Indexed, Even so Short Indexed
                          # Byte[6A]=Byte[Address[6A]+0x1F] is how I perceive it might work

I have not been able to rationalise how these work. All the MCS-96 literature does not seem to have an explanation.
Nothing appears to be in the Ford Reference Handbook.

The last operand can't serve any useful purpose as a destination register as R0 is fixed at Zero.
One assumes then the operand sequence is not like the rest of the 8061 opcodes and address modes.

The first operand, being the source register, is not a destination register in any of the literature.

Why do both disassemblers, treat FF in my first example as a Word, referencing FE in the results output, when the opcode is for a Byte ?

What is correct, why is it so ?

[sailorbob]

Using the Zero register as the destination is quite common, usually it's done for the purposes of a conditional jump rather than an addition.

[jsa]

Ok compare some value to the zero register and do the appropriate action. Thats sensible enough.

But trying to add some value to the zero register and then store it to the zero register ?

[decipha]

that doesnt sound right?

Are you sure its not adding 0 to an address and then following it with a compare?

thats done often for switches

[jsa]

I'm not 100% sure what it's doing.

[sailorbob]

Even though it's an addition operation being performed the purpose is not to add two values together to get a sum that's needed. It's done for purposes of a conditional jump.

Replace the 0x77 opcode with 0x9B and you'll see it amounts to the same thing in terms of what the program is doing.

[jsa]

Ok, thanks, so you're saying ?

Code: Select all

77,FF,D4,00,00      # AD2B Zero Indexed, Odd so Long Indexed
                    # Byte[R00]=Byte[Address[RFE RFF] + 0x00D4]+0x00
                    # The contents of RFE, RFF & D4 Indexed address remain unchanged, as they were before the operation

Apart from chewing up 12 state times, what else has it achieved ?

What has happened to the flags in the PSW ?

Strictly following the documentation, the operation should cause a write attempt to, Read Only, R00. Does the write attempt occur or does some mechanism within the microprocessor prevent the write attempt ?

If a write is not prevented, what does the microprocessor do when an attempt is made to Write 0 or some non 0 value to the register ?

[decipha]

the opcode following that example will show you whats going on, the ecu is simply filling the temp registers so it can do an immediate compare to 0, that value is clearly a switch

[jsa]

Thanks decipha.

Code: Select all

52B5  77,FF,D4,00,00            addb  Zero,$00D4[REG_FE]
52BA  DF 02                je    L52BE

Ok, Zero flag is set by ADDB instruction, JE sees Z flag set and jumps two bytes to L52BE.

Code: Select all

529D  77,6A,1F,00            addb  Zero,$1F[REG_6A]
52A1  D7,5A                jne   L52FD

Again, Zero flag is set by ADDB instruction, JNE see Z flag set and does not jump and continues with 52A3.

Rationalising, it must be possible for both to evaluate to something other than zero, otherwise the ADDB operands are a waste of time.

Question still remains about which is the source and destination register for zero indexed operations ?

[sailorbob]

Code: Select all

52B5  77,FF,D4,00,00            addb  Zero,$00D4[REG_FE]
52BA  DF 02                     je    L52BE

Ok, Zero flag is set by ADDB instruction, JE sees Z flag set and jumps two bytes to L52BE.

It only jumps if the content of $00D4[REG_FE] has a value of zero.

Code: Select all

529D  77,6A,1F,00            addb  Zero,$1F[REG_6A]
52A1  D7,5A                  jne   L52FD

Again, Zero flag is set by ADDB instruction, JNE see Z flag set and does not jump and continues with 52A3.

It will not jump if the content of $1F[REG_6A] has a value of zero.

[jsa]

Thanks Sailorbob.

So it boils down to there being no opcode to directly check $00D4[REG_FE] or $1F[REG_6A] and set the Z flag accordingly ?

The processor has to tolerate the zero register as a destination register for the instruction and the sources $00D4[REG_FE] or $1F[REG_6A] remain unchanged by the instruction.

[sailorbob]

So it boils down to there being no opcode to directly check $00D4[REG_FE] or $1F[REG_6A] and set the Z flag accordingly ?

This is just one way of doing this, as said above you could change the 0x77 opcode with 0x9B to do the same thing.

The processor has to tolerate the zero register as a destination register for the instruction and the sources $00D4[REG_FE] or $1F[REG_6A] remain unchanged by the instruction.

$00D4(REG_FE) is a rom address so its contents cannot be changed.

[jsa]

Thank you.