Re: [avr-gcc-list] one-byte stack bug in tiny26

[Erik Christiansen]

On Tue, Apr 27, 2004 at 11:51:19AM +0200, Marek Michalkiewicz wrote:
> Looks like another reason for per-device multilibs, as the avr2/3/4/5
> device groups are not enough (my fault, it looked clean at the time
> when Atmel's future plans were top secret - today we know about chips
> with "movw", but without "mul" = more than avr2, less than avr4).
> I'm not sure if we really want so many ld emulations though...

Marek,

   There has recently been some discussion of multilibbing, over on
crossgcc. It doesn't seem easy to get working perfectly. Also, this path
seems to greatly increase your workload.

   Do you think there is merit in a more accessible alternative, such as
just generating normalised assembler from gcc, then performing target
customisation in assembler macros? (To offload target tweaking to those
of us not familiar with gcc internals)

e.g. With or without movw instruction:

   .macro movw rd,rs
      .if (core > avr1) || (core == mega_xxx) || (core == mega_yyy)
         movw \rd,\rs
      .else
         mov  \rd,\rs
         mov  \rd+1,\rs+1
      .endif
   .endm

   As it stands, this example will obviously recurse infinitely, if the
test is true. To make it work would require that the normalised
assembler use a slightly different mnemonic. I suspect that's where this
notion could become hard to swallow.

   Is learning gcc internals, then, the only way to spread the load of
chasing an ever changing panoply of targets? I sense that a more
accessible toolset could invigorate avr-gcc.

Erik