This is the Atmel  WAVRASM  Bug  

-----Original Message-----
From: Wagner [mailto:wagner@ustr.net]
Sent: Sunday, March 03, 2002 1:51 AM
To: avr-gcc-list@avr1.org
Cc: misc@atmel.com
Subject: wavrasm compiler bug?
Compiler Atmel WAVRASM - Version 1.30 - Jan27/1999 01:30:00

It is me, or this compiler has a bug when calculating the .db directive addressing?
The problem appeared in a long run, I reduced to the minimum exercise so it is possible to duplicate and exercise.
Follows the assembly code and the compilation listing result:

Source:


.cseg
            Ldi R30,(MSG001)
            Ldi R30,(MSG002)
            Ldi R30,(MSG003)
            Ldi R30,(MSG004)
            Ldi R30,(MSG005)
            Ldi R30,(MSG006)
MSG001:    .DB    1,"A"
MSG002:    .DB    1,"A"
MSG003:    .DB    1,"A"
MSG004:    .DB    "A",1
MSG005:    .DB    "A",1
MSG006:    .DB    "A",1


Listing:

            .cseg

000000 e0e6      Ldi     R30,(MSG001)
000001 e0e8      Ldi     R30,(MSG002)
000002 e0ea      Ldi     R30,(MSG003)
000003 e0ec      Ldi     R30,(MSG004)
000004 e0ed      Ldi     R30,(MSG005)
000005 e0ee      Ldi     R30,(MSG006)

000006 4101   MSG001:   .DB   1,"A"
000007 4101   MSG002:   .DB   1,"A"
000008 4101   MSG003:   .DB   1,"A"
000009 0141   MSG004:   .DB   "A",1
00000a 0141   MSG005:   .DB   "A",1
00000b 0141   MSG006:   .DB   "A",1


Problem definition:
Note the line 000000, it shows the correct .db directive address at label MSG001, when assembling e0e6. 
Lets open the instruction:

e...  means LDI (Load Immediate)
..e.  means into register 0Eh from the 16-31 package (R30).
.0.6  means label is at address (low) 06h.

E0D8

The E means Instruction LDI (load immediate)
The D means the 13th register from 16-31 package
The 08 means memory source address.

Note the line 000001, it is already incorrect. Decompose the e0e8 as show above, you will see it is already pointing to
address 08h instead of 07h, the correct MSG002 label address (skiped 1 byte).

Note the line 000002, it still pushing the error, now its e0ea is trying to say the MSG003 is located at address 0Ah, what is double incorrect, MSG003 is at 08h (skiped 1 byte).

Note the line 000003, e0ec shows also incorrect MSG004 position (skiped 1 byte)

Now note lines 000004 and 000005, it is not jumping the extra byte as the previous lines, but it still with an offset error pushed from the previous.

Everything goes wrong whenever you use a directive .DB with a number before a text.

In this case, source code MSG001, 002 and 003 are using .DB  1,"A"  (number before text),  while MSG004, 005 and 006, are using   .DB  "A",1 (number after text).

If in the directive .DB you use  1,$41 instead of 1,"A", it will generate exactly the same compiled data bytes, but the address calculation will be correct.

The problem is isolated to when using at least one numeric digit before a quoted text in the .db directive.

Anyone already saw this flaw? or it is me?

The correct listing should be:

            .cseg

000000 e0e6      Ldi     R30,(MSG001)
000001 e0e7      Ldi     R30,(MSG002)
000002 e0e8      Ldi     R30,(MSG003)
000003 e0e9      Ldi     R30,(MSG004)
000004 e0ea      Ldi     R30,(MSG005)
000005 e0eb      Ldi     R30,(MSG006)

000006 4101   MSG001:   .DB   1,"A"
000007 4101   MSG002:   .DB   1,"A"
000008 4101   MSG003:   .DB   1,"A"
000009 0141   MSG004:   .DB   "A",1
00000a 0141   MSG005:   .DB   "A",1
00000b 0141   MSG006:   .DB   "A",1


Final note:
If using single quote (') instead of double (") around the text, it works correctly, so, why double quotes generate the problem?

------------------------------------------------------
Wagner Lipnharski - Director - wagner@ustr.net
UST Research Inc. - Orlando - FL - http://www.ustr.net