-
Notifications
You must be signed in to change notification settings - Fork 26
improve argument evaluation #104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
allow variables to be initialized with hex and binary values, not just integers
This will introduce a slight incompatibility in case someone has used integers with leading zeros. But I think it is worth it nevertheless, it should be just pointed out in docs / changelog.
|
Thanks for this PR. I thought we already supported this (see the test fixture here for example), because we support it for opcode arguments, but I now see we don't evaluate what is passed to According to the GNU assembler manual, the But for now, perhaps the easiest is to stick to supporting a single value, but to pass that value through our We already do this for the Would you mind adapting the PR to use |
Using eval_args instead for better compatibility when using expressions
I agree @wnienhaus that the use of eval_args is a better idea, as it also allows expressions. There is still an issue with leading 0's (thanks @ThomasWaldmann), which is not present when using leading 0's in opcode arguments, since this also goes through arg_qualify. There is a caveat, that when using leading 0's in opcode arguments, it can not be an expression. but this does not: This has to do with the try except blocks in the arg_qualify function. where int("048879") evaluates to 48879 (first try block) but eval("048879") throws an exception (second try block). |
If you figure out why the test fixture passes, I am interested what the reason is :) |
So... it turns out the change in behaviour (from what I remember to how it's now) is because of a "regression" (or fully-understood and intentional change) in MicroPython. When looking into this, I noticed our unit tests fail with the latest MicroPython (v1.25.0) - they fail here, exactly for the same reason you (@mjaspers2mtu) described in your last comment about the try..except block, but while trying to cast a hex value. Typing And sure enough, with MicroPython v1.24.1 all our unit tests still pass. And typing I traced it down to this commit in MicroPython: micropython/micropython@13b13d1. Because that change does not relate directly to hex values, and the tests that were added don't test any hex values, it might be that the impact on hex values was unintended. However, since Python 3 also throws pretty much the same exception, it may also have been intended (and the change is just missing some test cases). Btw, So I guess we have 2 options:
I think I'll raise an issue about 1. either way, just to find out what their intent was - and (potentially) make them aware of the issue with hex values. |
Yes, we did make a breaking change with how So given that above commit, I would say this change is understood and intentional. Although unfortunate that it did break something here 😞 |
allow variables to be initialized with hex and binary values, not just integers
For example:
magic: .long 48879
could also be:
magic: .long 0b1011111011101111
or what I frequently use it for:
magic: .long 0xBEEF
int(x, 0) in Python is a very useful feature of the int() constructor that automatically interprets the base (radix) of the number based on its prefix