This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

uVision2 debugger

In A51 the next definitions takes two cells of RAM, (0AH), for example, and (0BH):

data_variable: DS 1
typeless_number EQU 0BH

and can be treated with the same instruction:

MOV A,data_variable (F50A)
MOV A,typeless_number (F50B)

,but there is the value of "data_variable" displays properly in the "Watch" window,
"typeless_number" shows it's address instead
of the value.

How can I trace such a variable?

Parents
  • typeless_number EQU 0BH

    No it doesn't. This will only consume one byte of memory. EQUs don't reserve memory --- they're just fancy names for fixed numbers.


    That is correct; however

    What the instruction
    MOV A, typeless_number
    might put into the accu is random garbage. If it shows 0x0B for you, that's pure coincidence.

    is not correct. The EQU tell the assembler to substitute, so
    MOV A, typeless_number
    becomes
    MOV A, 0x0b

    nothing random about that.

    That using such means of defining memory slots is likely to cause all kinds of "housekeeping errors" is another story.

    Erik

Reply
  • typeless_number EQU 0BH

    No it doesn't. This will only consume one byte of memory. EQUs don't reserve memory --- they're just fancy names for fixed numbers.


    That is correct; however

    What the instruction
    MOV A, typeless_number
    might put into the accu is random garbage. If it shows 0x0B for you, that's pure coincidence.

    is not correct. The EQU tell the assembler to substitute, so
    MOV A, typeless_number
    becomes
    MOV A, 0x0b

    nothing random about that.

    That using such means of defining memory slots is likely to cause all kinds of "housekeeping errors" is another story.

    Erik

Children
  • Erik,

    it produces "random" (not good word here, I agree) results because there is difference between next two lines:

    MOV,A#0x0b
    MOV A,0x0b
    
    last line does not load 0x0b into accumulator but a value from location 0x0b. So the question is why OP uses fancy number of memory location.
    I would preffer something like this:
    LOCATION_0BH  DATA 0x0b
    
    MOV A,LOCATION_OBH
    

    Regards,
    Oleg

  • guys,

    The definition of all RAM (DATA) locations by EQU was a common practice years (ages?) ago. I haver NO recollection of the reason.

    it was something like
    ;; data area
    store1 EQU 30h
    store2 equ store1+1

    and so on.

    Erik

  • The problem with what you remember is that while it sure is a way time-honoured to definite memory locations, it's not a way to define variables.

    The difference is two-fold. First, there's type: an EQU is just a number, not an address. The second is ownership: memory locations belong to the hardware (e.g. some memory-mapped device), whereas variables belong to individual pieces of software.

    To put it in a different context: if

    foo EQU 0x23
    were a variable definition, then so would
    #define FOO 0x23
    in a C program.

  • The problem with what you remember is that while it sure is a way time-honoured to definite memory locations, it's not a way to define variables.
    no, but where the variables are, which is just the same as
    org 30h
    store1 ds 1
    store2 ds 1
    which you state is "defining variables"
    To put it in a different context: if
    foo EQU 0x23
    were a variable definition, then so would
    #define FOO 0x23
    in a C program.

    C and assembler - apples and oranges

    Erik

  • no, but where the variables are, which is just the same as

    org 30h
    store1 ds 1
    store2 ds 1


    No, it's not. Not even after fixing obvious typos. Try it for yourself: here's two minimalistic .A51 files, the only difference is that one uses EQUs, the other DS:
    ; equ.asm:
            DSEG at 30h
    store1 equ 30h
    store2 equ store1+1
            CSEG
            ORG 0
            mov     a, store1
            mov     B, store2
            END
    
    ; ds.asm:
            DSEG at 30h
    store1: ds 1
    store2: ds 1
            CSEG
            ORG 0
            mov     a, store1
            mov     B, store2
            END
    
    (The code part is needed because otherwise, the linker will optimize things away).

    Here's the difference between the list files (modulo file names):
    @@ -24,8 +24,8 @@ SYMBOL TABLE LISTING
     N A M E             T Y P E  V A L U E   ATTRIBUTES
    
     B. . . . . . . . .  D ADDR   00F0H   A
    -STORE1 . . . . . .  D ADDR   0030H   A
    -STORE2 . . . . . .  D ADDR   0031H   A
    +STORE1 . . . . . .  N NUMB   0030H   A
    +STORE2 . . . . . .  N NUMB   0031H   A
    
    
     REGISTER BANK(S) USED: 0
    
    The important thing to note is that the EQUs got listed as NUMBer, the DS as ADDResses. This becomes even clearer in the difference between map files:
    @@ -17,11 +17,9 @@ LINK MAP OF MODULE:  DS (DS)
    
                 * * * * * * *   D A T A   M E M O R Y   * * * * * * *
                 REG     0000H     0008H     ABSOLUTE     "REG BANK 0"
    -                    0008H     0028H                  *** GAP ***
    -            DATA    0030H     0002H     ABSOLUTE
    
                 * * * * * * *   C O D E   M E M O R Y   * * * * * * *
                 CODE    0000H     0005H     ABSOLUTE
    
    -Program Size: data=10.0 xdata=0 code=5
    +Program Size: data=8.0 xdata=0 code=5
     LINK/LOCATE RUN COMPLETE.  0 WARNING(S),  0 ERROR(S)
    Note that according to the linker, the program using EQU has used no data at all except register bank #0. I hope you can agree that this is desaster waiting to happen.

  • Note that according to the linker, the program using EQU has used no data at all except register bank #0. I hope you can agree that this is desaster waiting to happen.
    Yes, there is a disaster waiting, but not the one you mention. The method virtually guarantee that someone at some time will put 2 variables in the same slot.

    I have seen several programs using the EQU method that worked beautifully (and fixed some that did not).

    Please understand, I totally agree that the EQU method is dangerous and should not be used, where we do not agree is that, it works. I would neither use nor recommend it, but in a way that invites you to make a bug and almost guarantees you will, it works.

    NOW, if you mix this with C the house comes tumbling down, but that was not mentioned. Of course if you mix the EQU method with 'ds' statements it will get so many times easier to make a bug, but, again, it CAN be done.

    I do not know how long you have been around, but some of the programs from the pre C days were "really fun", you added a variable and spent days to find out why that maded the whole thing fall apart.

    Erik

  • friends,

    come back to the original question:

    data_variable: DS 1
    typeless_number EQU 0BH

    and can be treated with the same instruction:

    MOV A,data_variable (F50A)
    MOV A,typeless_number (F50B)

    ,but there is the value of "data_variable" displays properly in the "Watch" window,
    "typeless_number" shows it's address instead
    of the value.

    How can I trace such a variable?


    I think the question is not in difference between EQU/define/DATA et cetera, the matter is "how to obtain this value". And the answer is simple - follow the [simple] rules which Keil made for us. Debugger (and its Watch module) is not so smart to understand that if user types "EQU" then he orders: "look at the value which is stored in a memory which address in indicated by this fancy number". So open datasheet, read about numbers and addresses and have good sleep then.

    Regards,
    Oleg

  • I think the question is not in difference between EQU/define/DATA et cetera

    But it's exactly about the difference between EQU and DS!

    And the difference between those is precisely that one generates a number, the other a variable. This difference both neatly explains the difference of behaviour if one tries to display things in the debugger (the EQU is not displayed as "its address", but actually as itself: a number), and provides an obviously correct solution to the problem: don't use EQU if what you wanted was to define a variable.

    Now, even an EQU-ed "variable" can be viewed in the debugger, but you'll have to go through quite some painful typing to get there. You'd have use something like

    *(data char *)equ_label
    as the expression whose value is to be displayed or watched.