Wiki is severly outdated, needs to be more friendly

[Artcfox]

Have you told the Debian gcc-avr maintainer about this update Artcfox?

https://qa.debian.org/developer.php?log ... debian.org

I have not. What's nice is you can just extract a whole bunch of the official toolchains in the same root directory and switch among them just by changing your path. That way you can pick the version that give you the best output for what you are trying to achieve.

[danboid]

Why would we not want to always use the latest stable gcc-avr?

[Artcfox]

Why would we not want to always use the latest stable gcc-avr?

Things like this can happen with newer versions: https://uzebox.org/forums/viewtopic.php?f=6&t=2254

And back when I tested a whole bunch of toolchain versions, there was a big variation in the generated assembly/code size for the different versions, some versions producing incorrect code: https://uzebox.org/forums/viewtopic.php?f=3&t=2304

Stuff like that is why I've been cautious about just blindly switching over to the newer toolchain version. I've been trying to compare the generated ASM in order to see if it's actually better or worse. In a lot of cases, compiling with -Os with the newer compiler did make the code smaller, but often by trading speed for that smaller size.

[danboid]

I think the wiki is in much better shape now after Uze recently updated the Windows instructions and made a few other tweaks on top of my ongoing efforts to document all the things.

[D3thAdd3r]

Thanks guys for improving this stuff!

...And back when I tested a whole bunch of toolchain versions, there was a big variation in the generated assembly/code size for the different versions...

I just blindly use the latest, but I always wondered if that was good. I suppose it's likely game specific, but what version are you using in general/for Unicorn?

[danboid]

I run Debian testing on my laptop and I use the default avr-gcc in the Debian testing repo which is currently avr-gcc 5.4.0

[ry755]

I run Debian testing on my laptop and I use the default avr-gcc in the Debian testing repo which is currently avr-gcc 5.4.0

Yikes that's still really old, on my Fedora 37 box I have avr-gcc 12.1.0.

Code: Select all

$ avr-gcc --version
avr-gcc (Fedora 12.1.0-2.fc37) 12.1.0

[Artcfox]

I run Debian testing on my laptop and I use the default avr-gcc in the Debian testing repo which is currently avr-gcc 5.4.0

Yikes that's still really old, on my Fedora 37 box I have avr-gcc 12.1.0.

Code: Select all

$ avr-gcc --version
avr-gcc (Fedora 12.1.0-2.fc37) 12.1.0

I wonder if that has all of the Atmel (now Microchip) patches applied, since the latest official version on Microchip's website is 7.3.0. One example that used to be different is the avr-objdump command has extra parameters specific to AVR chips. I'm not on a computer now but IIRC one of the specific parameters is -A.

[ry755]

I wonder if that has all of the Atmel (now Microchip) patches applied, since the latest official version on Microchip's website is 7.3.0. One example that used to be different is the avr-objdump command has extra parameters specific to AVR chips. I'm not on a computer now but IIRC one of the specific parameters is -A.

Interesting, `avr-objdump -A` returns this: ("<help output>" added by me)

Code: Select all

$ avr-objdump -A
avr-objdump: invalid option -- 'A'
<help output>

At the end of the listed help output, it says this:

Code: Select all

avr-objdump: supported targets: elf32-avr elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex plugin
avr-objdump: supported architectures: avr avr:1 avr:2 avr:25 avr:3 avr:31 avr:35 avr:4 avr:5 avr:51 avr:6 avr:100 avr:101 avr:102 avr:103 avr:104 avr:105 avr:106 avr:107

Anyways this is getting off-topic so we should probably move to the avr-gcc thread.