[xd41efisc]

Hi,

I am trying to work out how the code below points to an address.
I thought I worked this out a few years ago, but have spent a few hours and can't work it out.
I guess that is what happens when you leave things for a while.

Below is a bit of the code from tvrfan I am looking at.
I am trying to work out what is going on at:
648c that gives the rom address 941c.
649b that gives the rom address 941f.
And so on.

Code: Select all

  Update_fans:
648c: 9b,f6,74,00         cmpb  R0,[Rf6+74]                                        # 941C fan control enable
6490: d7,01               jne   6493             if (0 = Fan_enble)  {
6492: f0                  ret                    return; }

6493: 37,a1,02            jnb   B7,Ra1,6498      if (Cranking = 0) goto 6498;
6496: 20,c1               sjmp  6559             goto 6559;
6498: 71,df,e9            an2b  Re9,df           Hsfflg = 0;
649b: 9b,f6,77,b0         cmpb  Rb0,[Rf6+77]                                       #  ROM 941F fan high speed temp 2(242DegF)
649f: d6,24               jge   64c5             if (ECT >= Ect_hs2) goto 64c5;
64a1: 9b,f6,76,b0         cmpb  Rb0,[Rf6+76]                                       #  ROM 941E fan high speed temp 1(234DegF)
64a5: de,21               jlt   64c8             if (ECT >= Ect_hs1)  {
64a7: b3,74,21,42         ldb   R42,[R74+21]     R42 = N_byte;
64ab: 9b,f6,78,42         cmpb  R42,[Rf6+78]     

Thanks.

[ollopa]

You're missing the bit where register rf6 (rf6:rf7) is loaded with 0x93A8. Your addresses are then relative to that base.
[Rf6+74] = 941C
[Rf6+75] = 941D
[Rf6+76] = 941E
[Rf6+77] = 941F
[Rf6+78] = 9420

[xd41efisc]

Thanks mate,

I got the last part.
But I don't get the first part.
I see 93a8 at 2028 and 8fd6.
At 93a8 i see 9430.

Code: Select all

8 2022: 00,8c                8c00  RBASEADR_01        Rbase Rf0
8 2024: 5a,8e                8e5a  RBASEADR_02        Rbase Rf2
8 2026: d6,8f                8fd6  RBASEADR_03        Rbase Rf4
8 2028: a8,93                93a8  RBASEADR_04        Rbase Rf6
8 202a: 30,94                9430  RBASEADR_05        Rbase Rf8
8 202c: a8,97                97a8  RBASEADR_06        Rbase Rfa
8 202e: 7e,9a                9a7e  RBASEADR_07        Rbase Rfc
8 2030: 5a,9e                9e5a  RBASEADR_08        Rbase Rfe

I take it this is where it is loaded (2028), but what defines it as Rf6.

Thanks.

[tvrfan]

That looks like A9L....

The loop that loads those 'base' registers is here.

Code: Select all

84ed: a1,22,20,14         ldw   R14,2022         R14 = 2022;                       # calibration Table pointers
84f1: 3c,24,01            jb    B4,R24,84f5      if (Console_flag = 0) {           # enable ints if console enabled
84f4: fb                  ei                     interrupts ON; }
84f5: a1,f0,00,18         ldw   R18,f0           R18 = f0;                         # copy base vectors here
84f9: b3,01,20,20,1a      ldb   R1a,[R0+2020]    R1a = [2020];
84fe: a2,15,1c            ldw   R1c,[R14++]      R1c = [R14++];                    # set 8 vectors from 2022 to Rf0 -f8
8501: c2,19,1c            stw   R1c,[R18++]      [R18++] = R1c;
8504: e0,1a,f7            djnz  R1a,84fe         R1a--;
                                                 if (R1a != 0) goto 84fe;          # loop

and data begins at 2020 with one set of 8 vectors.
R14 is where vectors data starts = 0x2022
R18 is where the values get written = 0xf0
and the loop increments read and write locations (8 times)

[xd41efisc]

Ok thanks.

Yes it is A9L.

I have come across something else that I can't work out.

Using these register bases:
rbase 72 180
rbase 74 27e
rbase 76 37a
rbase 78 8eda

At these locations:
6e9e: I see [R72+13d] if I do the calculation 180+13d I get 2bd this is fine.
6ecb: I see [R72+48] if I do the calculation 180+48 I get 1C8 also fine.
6ed7: I see [R72+b4] if I do the calculation 180+b4 I get 234 but in the disassembly it is 134.
This is happening in a few areas.

Code: Select all

6e98: 30,2a,1a             jnb   B0,R2a,6eb5        if (!B0_R2a) goto 6eb5;
8 6e9b: 35,2b,12             jnb   B5,R2b,6eb0        if (!B5_R2b) goto 6eb0;
8 6e9e: b3,73,3d,01,42       ldb   R42,[R72+13d]      R42 = [2bd];         
8 6ea3: 99,04,42             cmpb  R42,4                                   
8 6ea6: d9,08                jgtu  6eb0               if ((uns) R42 > 4) goto 6eb0;
8 6ea8: 37,a0,05             jnb   B7,Ra0,6eb0        if (!B7_Ra0) goto 6eb0;
8 6eab: 3d,a0,02             jb    B5,Ra0,6eb0        if (B5_Ra0) goto 6eb0;
8 6eae: 20,91                sjmp  6f41               goto 6f41;           

8 6eb0: 91,20,2a             orrb  R2a,20             R2a |= 20;           
8 6eb3: 27,bf                sjmp  6e74               goto 6e74;           

8 6eb5: 31,2a,08             jnb   B1,R2a,6ec0        if (!B1_R2a) goto 6ec0;
8 6eb8: 3d,2b,b9             jb    B5,R2b,6e74        if (B5_R2b) goto 6e74;
8 6ebb: 37,a1,b6             jnb   B7,Ra1,6e74        if (!B7_Ra1) goto 6e74;
8 6ebe: 20,7a                sjmp  6f3a               goto 6f3a;           

8 6ec0: 3f,a1,49             jb    B7,Ra1,6f0c        if (B7_Ra1) goto 6f0c;
8 6ec3: 3a,a1,03             jb    B2,Ra1,6ec9        if (B2_Ra1) goto 6ec9;
8 6ec6: 3d,2b,02             jb    B5,R2b,6ecb        if (B5_R2b) goto 6ecb;
8 6ec9: 20,82                sjmp  6f4d               goto 6f4d;           

8 6ecb: b3,72,48,42          ldb   R42,[R72+48]       R42 = [1c8];         
8 6ecf: 99,08,42             cmpb  R42,8                                   
8 6ed2: d3,79                jnc   6f4d               if ((uns) R42 < 8) goto 6f4d;
8 6ed4: 32,2a,76             jnb   B2,R2a,6f4d        if (!B2_R2a) goto 6f4d;
8 6ed7: a3,72,b4,42          ldw   R42,[R72+b4]       R42 = [134];         
8 6edb: 99,18,43             cmpb  R43,18                                  
8 6ede: d3,6d                jnc   6f4d               if ((uns) R43 < 18) goto 6f4d;
8 6ee0: b3,78,c7,42          ldb   R42,[R78+c7]       R42 = [R78+c7];      
8 6ee4: 99,02,42             cmpb  R42,2                                   
                           

Another example is:
209a: I see [R74+de] if I do the calculation 27e+de I get 35c but in the disassembly it is 25c.
209e: I see [R74+9e] if I do the calculation 27e+9e I get 31c but in the disassembly it is 21c.

Code: Select all

 208e: 91,10,24             orrb  R24,10             R24 |= 10;           
8 2091: ef,1e,64             call  84b2               Sub0230();           
8 2094: ef,0c,65             call  85a3               Sub0233();           
8 2097: ef,5b,65             call  85f5               Sub0235();           
8 209a: a3,74,de,42          ldw   R42,[R74+de]       R42 = [25c];         
8 209e: c3,74,9e,42          stw   [R74+9e],R42       [21c] = R42;         
8 20a2: 45,e2,01,f0,42       ad3w  R42,Rf0,1e2        R42 = St0003;        
8 20a7: c3,76,b4,42          stw   [R76+b4],R42       [32e] = R42;         
8 20ab: a3,f0,02,42 

It is obviously something I am doing wrong.
Any ideas?
Thanks

[tvrfan]

xd41 ..,

Yep, The offset part is SIGNED, in a short (=byte) indexed address, so 0xde as a signed value is -(0x22) in effect, so as calculated 0x27e - 22 = 25c. And 0x9e = -(0x62).
You are most definitely NOT the first person here to be caught out by this !

I wrote that '-( )' in that odd way because officially hex doesn't have minus values in its representation. When the top bit is set it represents a negative value, where 0xff = -1 0xfe = -2 and so on. This applies for words too (bit 15). Code can have signed or unsigned bytes and words (and even longs for divide and multiply)

[xd41efisc]

O.K I had to think about that for a few minutes.

So in the example above:
6e9e: b3,73,3d,01,42 the 3d,01 is 2 bytes this makes it UNSIGNED and
6ecb: b3,72,48,42 the 48 is 1 byte making it SIGNED.
Or am I way off track.

Thanks.

[cgrey8]

The byte-length does not dictate whether something is signed or not. The interpreter of the data decides that.

In the case of offsets in branching opcodes, the 1-byte offset is always assumed signed so that it can branch forward by up to 127 bytes OR backwards by up to 128 bytes. Being able to declare "earlier" addresses is particularly useful when iterating over something (think a while or for-loop). The code gets down to a certain level and needs to return to be beginning of the loop to perform the loop again until some condition is met. In these cases, it's often a short-branch backwards through the code.

However there are plenty of other areas where a 1-byte value is interpreted as unsigned...memory-offsets is just not one of them.

[tvrfan]

OK. Careful here.... I don't want anybody confused, so will try to give a quick overview.

1. 'Data' can be signed or unsigned, anywhere. It's not linked with size. As Cgrey says it's up to the reader of that data, even if the reader happens to be for a CPU instruction.

2. When anyone starts with a new bin to look at, it's impossible to say which data values are signed and which are unsigned. The only way to know is to find out what the code does with each value. As I said in my last post, hex and other binary notations do not have a negative form. Why ? because it's up to the designer of the code.

3. Believe it or not, the CPU 'math unit' (the bit that does all the +, -, *, / etc.) has no sign knowledge at all. Because of clever design, it DOES NOT NEED TO. (There are a few exceptions to this, where it's necessary to know). This is common to nearly all CPU designs.

4. The instructions JNC, JE etc. (all the 'jump if' instructions) are the ones which tell you if the value is being treated as signed or unsigned.

5. Even CMPB, CMPW are not signed or unsigned either, they do both at the same time, by setting bits in the PSW (processor status word).

In your example 6e9e ldb, 42, ... cannot tell if this is signed or not, BUT 6ea3 CMPB and 6ea6 (JGTU) tell you that the value here is UNSIGNED (jgtu = jump if greater than unsigned). The jump instructions use the PSW to decide whether to jump or not.

I hope that helps.......... there are several design 'tricks' in CPUs which take a bit to get your head around, like "why do negative values go backwards compared to positive numbers ? " e.g. 1 = 0x1 2= 0x2 , but -1 = 0xff, -2 = 0xfe. This again is to do with clever design to make calcs a lot faster.... (remembering here that an '0xff' can be either 255 or -1, there's no way to know immediately ).

[cgrey8]

...much much more complete of an answer than mine.

[jsa]

A different way to look at it...

For signed operations 0x80 through to 0xff are negative, otherwise positive.
Hex 80 = Bin 1000 0000
Hex FF = Bin 1111 1111

For signed and unsigned 0x00 through to 0x7f are always positive.
Hex 00 = Bin 0000 0000
Hex 7F = Bin 0111 1111

The one on the left, bit 7, means a negative number for a signed operation.

[tvrfan]

For 8061 and 8065, the top bit (bit 7 for byte, bit 15 for word, bit 31 for double word) marks the value as negative *IF* the value is being treated as SIGNED...

Added this as it's not just bytes.