search

Ro5bert / avra

Assembler for the Atmel AVR microcontroller family
GNU General Public License v2.0
153 stars 39 forks source link

.undef not work (or misused by me) #27

Open bdyssh opened 3 years ago

bdyssh commented 3 years ago

Hello. I need to use .undef , but it just does not have any effect. How to reproduce: Try to translate three-lines asm code:

.define test
.undef test
.define test

Current result: I get error: undef.asm(3) : Error : Can't redefine constant test, use .SET instead Expected result: No errors. Versions: This problem exist with old avra 1.3.0 from 2010, as well as latest version 1.4.2. Am i misuse the directive? Thanks.

Ro5bert commented 3 years ago

You're not misusing it; .undef is currently not implemented (i.e., AVRA recognizes it, but does nothing). I'll look into providing an implementation for it.

jameswilddev commented 3 years ago

Will this work like AVR Assembler's undef (http://ww1.microchip.com/downloads/en/devicedoc/40001917a.pdf) or C's undef (https://gcc.gnu.org/onlinedocs/cpp/Undefining-and-Redefining-Macros.html)? (will it allow reuse of a register, or deletion of preprocesor values)?

Reason I ask is that the docs list it with the latter (https://github.com/Ro5bert/avra#forward-references-not-supported-for-ifdef-and-ifndef-directives), but this issue makes it sound like the former.

Ro5bert commented 3 years ago

@jameswilddev I planning on making it undefine any symbol (i.e., a combination of the preprocessor and assembler versions of the directive). Sometime before I started maintaining AVRA, the unfortunate decision was made to make the #directive syntax merely alias the .directive syntax, which has caused many problems, and I can't really change it for backwards compatibility. If one really wants the C preprocessor behaviour of the directives, they can just run an external C preprocessor, so my philosophy has been to favour the assembler directives.

Earlier this year I started working on AVRA 2.0, which is mostly a rewrite of the internals, but it will also incorporate this change. I've been too busy to work on it recently, but I should be able to this summer. Until then, I'm not fixing any non-major AVRA 1.x bugs, because the code is too messy. Every time I fix a bug, I discover 3 more just reading the surrounding code; it's that bad.

jameswilddev commented 3 years ago

Aha, I know that feeling. I'm on and off playing around with a fairly large AVR assembler codebase at the minute so if you need something big to smoke test it with just let me know!

On the other hand I've also recently played around with writing an AVR opcode interpreter as part of a tool to brute force search for solutions to awkward bitwise manipulation which needs to fit into small spaces in terms of flash and cycle count and I feel I've got a bit of a rough headspace full of AVR machine code now. So if you need a hand with AVRA 2.0 (even writing tests or similar) let me know!