avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Problems with AVR-GCC Assembler v2.11 (Duplicate Posting)


From: Bruce D. Lightner
Subject: [avr-gcc-list] Problems with AVR-GCC Assembler v2.11 (Duplicate Posting)
Date: Wed, 18 Jul 2001 10:15:20 -0700

TWIMC:

I seem to have detected a problem with the the AVR-GCC assembler (v2.11),
taken from the Web page "AVR development tools (binaries+source)" at 
http://www.combio.de/avr/, mainttained by Gunnar Henne <address@hidden>.
He suggested that I post this problem here in hopes of finding someone who
knows what the problem is.

In particular, I downloaded and installed the Win32 binaries...

  avr-binutils release 2.11 6.8M 
  avr-gcc release 3.0 3.06M 
  avr-libc-2001.07.01 sources + install programm for every location 124k
  Useful Unix Tools (make.exe, rm.exe ...) 444k 

and discovered that the version of "avr-as" included with that release does
not seem to be right.

Note that "avr-gcc" seems to work just fine, and it does create correct
object files when run in the "normal" way.  However, if you run "avr-gcc -S"
to instead produce an AVR assembly source file, and then try to run the
assembly source code through "avr-as", you get syntax errors.  This has not
been may experience in the past. 

After a bit of investigation, it seems that "equates" (e.g., .equ, .equiv,
.set) are somehow "broken" when it comes to AVR instructions which reference
the "equates".  Note that when using older releases of the Win32 (and Linux)
AVR GCC tools, there is no problem.  Is there some new "secret switch" that
I need to add to the "avr-as" command line?

Here is a simple AVR assembly test program named "x.s" which demonstrates
the problem...

    .arch at90s8515
yl = r28
__zero_reg__ = r0

.section .text
    adc r14,__zero_reg__
    clr r28
    clr yl
    adc r14,yl
    nop

Running the new version of "avr-as" on this file shows the following odd
output:

% \avrgcc\bin\avr-as --verbose -al x.s
GAS LISTING x.s                         page 1


   1                        .arch at90s8515
   2                    yl = r28
   3                    __zero_reg__ = r0
   4
   5                    .section .text
   6 ???? E01C              adc r14,__zero_reg__
****  Error:constant value required
   7 ???? CC27              clr r28
   8 ???? 0024              clr yl
****  Error:constant value required
   9 ???? E01C              adc r14,yl
****  Error:constant value required
  10 ???? 0000              nop
GNU assembler version 2.11 (avr) using BFD version 2.11
x.s: Assembler messages:
x.s:6: Error: constant value required
x.s:8: Error: constant value required
x.s:9: Error: constant value required
GAS LISTING x.s                         page 1


   1                        .arch at90s8515
   2                    yl = r28
   3                    __zero_reg__ = r0
   4
   5                    .section .text
   6 ???? E01C              adc r14,__zero_reg__
****  Error:constant value required
   7 ???? CC27              clr r28
   8 ???? 0024              clr yl
****  Error:constant value required
   9 ???? E01C              adc r14,yl
****  Error:constant value required
  10 ???? 0000              nop
GNU assembler version 2.11 (avr) using BFD version 2.11
x.s: Assembler messages:
x.s:6: Error: constant value required
x.s:8: Error: constant value required
x.s:9: Error: constant value required

Note that it looks like the AVR code is actually being assembled TWICE each
time "avr-as" is run!  Of course, the error messages should not be
occurring!  You get the same errors if your use ".equ" in place of "=".

Here is output using an older "avr-gcc" release, which shows NO errors:

% \avrgcc\bin\avr-as --verbose -al x.s
GAS LISTING x.s                         page 1


   1                .arch at90s8515
   2            yl = r28
   3            __zero_reg__ = r0
   4
   5            .section .text
   6 0000 E01C      adc r14,__zero_reg__
   7 0002 CC27      clr r28
   8 0004 CC27      clr yl
   9 0006 EC1E      adc r14,yl
  10 0008 0000      nop
GNU assembler version 2.9.5 (avr) using BFD version 2.9.5.0.13

Anyway, I am confused.  I would appreciate your thoughts on this!  We are
anxious to switch to the new tools because the newer version of "avr-gcc"
generates much better code.  I've found up to a 15% reduction in program
memory space consumed when compiling C-code for larger projects!  And, of
course, it would be nice to use the AVR assembler from that newer AVR-GCC
release!

Best regards,

Bruce

P.S.- I have not checked for this problem under Linux (yet).

-- 
 Bruce D. Lightner
 Lightner Engineering (http://www.picoweb.net/)
 La Jolla, California
 Email: address@hidden
 URL: http://www.lightner.net/lightner/bruce/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]