CodeWarrior Assembly: Value Truncated to One Byte

cancel
Showing results for 
Search instead for 
Did you mean: 

CodeWarrior Assembly: Value Truncated to One Byte

8,014 Views
Wings
Contributor I
A line in assembly code goes like this:

LDA #RXFIFO+%11000000

And RXFIFO has been declared prior to this line as:

RXFIFO EQU $3F

When the LDA line is encountered the assembler spits out this warning:
Warning : A13003: Value is truncated to one byte

So what gives? I've seen these warnings before and, like this example,
most are bogus warnings.

Thanks for your input.

-Richard
Labels (1)
0 Kudos
6 Replies

505 Views
JM
Contributor I
All labels are considered 16 bits
So when a one byte operand is needed it has to cut the high part.
To avoid this warning try EQU.B instead of EQU
 
RXFIFO EQU.B $3F
 
The label will be considered 8 bits and the warning will go off.
 
Also when you use a reference from an other file use XREF.B instead of just XREF so the assembler warnings will keep quiet.
 
Also when you allocate memory use ds.b or dc.b
 
If you declare a zero page memory SECTION use SECTION SHORT.
 
For more details go to ->HELP->INDEX and search for EQU or XREF or SECTION
 
 
 
0 Kudos

505 Views
sskuce
Contributor I
I've got a similar issue. I'm a newbie to CW and Freescale/Motorola micros in general, so maybe there's something simple I'm not doing. I'm using CW 5.7.0 with the MC9S08GB60.

I've got a byte defined in my zero page, as so:
; variable/data section
MY_ZEROPAGE: SECTION SHORT
;Transmit enabled flag. Controls transmission over RS-485
gbSGTE: DS.B 1
;...other variables not relevant to my post.


And in my code, which is later in the same file, I've got a branch using gbSGTE:
BRCLR 0, gbSGTE, \@FINISH ;Skip transmitting if not enabled.

This gives me A13003, Value truncated to one byte, even though the generated machine code is correct, at least in the debugger it looks correct. MY_ZEROPAGE is definitely in the zero page, as when I look at the assembly in the debugger, all the variables declared in MY_ZEROPAGE have addresses below $ff.

The problem is with gbSGTE, not \@FINISH, which is only +19 from the branch instruction. I can continue working for now, as it's 'only' a warning, and like I said the generated machine code turns out fine, so it's just annoying, but I would obviously like to get rid of it.

I understand that labels are 16-bit by default, but I would think that if you explicitly declare SECTION SHORT, that wouldn't be a problem. Is there a way I can force it to interpret gbSGTE as an 8-bit label?
0 Kudos

505 Views
rocco
Senior Contributor II
Hi, Sskuce:

That is odd. I do what you seem to be doing all of the time, but I don't get that error message, unless:

1) The variable is really not in the zero-page (not the case for you), or
2) The variable is defined after the code is defined (also doesn't seem to be the case).

However, it looks like you may be doing a few things different from me:

One is that you are using the "SECTION" directive to define page zero, whereas I use the "BSCT" directive. Maybe the assembler is not interpreting the "SHORT" keyword correctly (the linker has to) whereas it interprets "BSCT" correctly.

Second is that the label "\@FINISH" is in a format that is typically used within a macro. Are you doing this within a macro? I can't see how that would make a difference, however.

Just some (probably useless) ideas . . .
0 Kudos

505 Views
sskuce
Contributor I
Thanks rocco,

Unfortunately that didn't solve it. Actually, when I used BSCT, the variables weren't in the zero page anymore! I looked in the help files and I seemed to be using it right, but there it was, so I went back to my SECTION SHORT format.

I fixed my problem by declaring the variable in a separate assembly file and importing it using XREF.B, which does force it to an 8-bit label. Problem solved, if not satisfactorily understood.

Thanks again!
Sam
0 Kudos

505 Views
rocco
Senior Contributor II
They are annoying, aren't they?

But although these warnings are often of no consequence, the assembler doesn't know whether it is or not.

The reason you got the error is that you did an addition of two constants, and constant math is done with 32-bit precision within the assembler. Since the LDA-immediate instruction only takes one byte as an operand, the 32-bit value had to be truncated. The assembler does not know if you meant to truncate or not.

You can avoid this error by doing the truncation explicitly:

LDA #LOW(RXFIFO+%11000000)


Or, you could pre-define the constant, though I don't understand why this doesn't cause the error also:

FifoConstant: equ RXFIFO+%11000000
LDA #FifoConstant

I noticed that if I pre-define the constant prior to referencing it, I get no warning. But if I reference it before defining it, I get the truncation warning, but still get correct code.


You might also try an OR instead of an ADD, but I'm not sure if that would help. I know that the ADD will use 32 bit math, but I'm not sure about the OR.
0 Kudos

505 Views
Wings
Contributor I
Thanks Rocco. The first thing I looked for was to see if the symbol was defined prior to the code, and it was. At least to my eyeballs it was, but it turned out that it was not. So, moving the equate line prior to the code stops the warning. (been there done that)

This is the only assembler I've used that can't wait until pass #2 to flag this as a warning/error, and then do it only if the symbol evaluates to something larger than will fit in a register.
0 Kudos