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

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

Re: [avr-gcc-list] Bug in attiny2313 support ?


From: Theodore A. Roth
Subject: Re: [avr-gcc-list] Bug in attiny2313 support ?
Date: Fri, 17 Dec 2004 08:43:31 -0800 (PST)

On Fri, 17 Dec 2004, Frederik Rouleau wrote:

> Hello,
>
> When I compile one of my code for attiny2313 I have the following error :
>
>     /Temp/cck4qsmk.s: Assembler messages:
>     /Temp/cck4qsmk.s:289: Error: illegal opcode mul for mcu attiny2313
>
>
> I have in the .lst file :
>
>      126:serial.c      ****                 uint8_t lum = (uint16_t)(lu
>     * arg) / 255;
>      287                   .LM23:
>      288 ???? 8091 0000         lds r24,lu
>      289 ???? 8C9F              mul r24,r28
>     ****  Error:illegal opcode mul for mcu attiny2313
>
> I am using binutils  2.15.94 20041215, avr-gcc  4.0.0 20041205 and
> avr-libc from cvs HEAD.
>
> It seems that attiny2313 is considered as an "avr4" architecture as the
> atMega8, 88, 168. But those latest have instruction not supported by atTiny.
> This problem should probably also occured for attiny13.
>
> Sould I submit a bug report ? And where (gcc, binutils...) ?

This is a bug in GCC.

The fact that GAS is emitting an error means that it is correctly
catching when gcc generates asm with the mul insn when the target device
does not support that insn.

The problem in GCC is that all arch=4 devices are assumed to have the
"movw", "mul" and other instructions making them "enhanced" devices over
the older avr devices. Unfortunately, the tiny2313 breaks that
assumption since it has some of the "enhanced" insns, but not all of
them.

A little testing shows that the problem exists for the tiny13 too:

  address@hidden:~/dev/test/foo$ make
  avr-gcc -g -Os -Wall -mmcu=attiny13  -save-temps   -c -o tst.o tst.c
  tst.s: Assembler messages:
  tst.s:57: Error: illegal opcode mul for mcu attiny13
  make: *** [tst.o] Error 1

>From a quick look at avr.c in GCC's source, it looks to me that the fix
is not going to be trivial since it involves passing more info around
than is currently available. If the fix requires making a new arch
(beyond the exisiting avr1-avr5), that would mean some minor changes to
avr-libc.

Sorry that I didn't test this case sooner. Like Bruce recently said on
the list, if you don't test it, it _will_ be broken.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden


reply via email to

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