Support numbers larger than 53-bits and immediates in assembly

[appden]

This improves the extension to properly support 64-bit (and even larger) numbers through using BigInt along with correctly matching immediate values in assembly. Other minor improvements in include properly activating the extension when an individual file is opened and improving the debugging experience.

[maziac]

Thanks for the PR. Please check my comments for the 2 commits.

[maziac]

And, please, add a statement here (as a simple comment) that you provide your changes under MIT license.

[appden]

And, please, add a statement here (as a simple comment) that you provide your changes under MIT license.

Thanks for looking this over! I'm contributing these changes under the the MIT license.

[appden]

As far as I can see the format e.g. "$80" (=0x80) would not be recognized anymore. Or evaluated as decimal to 80 and not 128.

Could you give an example for what immediate values are not recognized anymore and which assembler it is.

Now $80 is matched as both decimal as well as hex. I believe that should be the intended behavior.

[maziac]

Not exactly. You can see that the Decimal number in the 2nd column is bold. I.e. the bold number here shows the recognized number format. Only if the format is ambiguous more columns are shown. I.e. here it shows 3 columns as it could be decimal, hex positive or hex negative. But the decimal (2nd column) shouldn't be there.

Here is a simple example for $20: With "\$":

Without "\$": The 2nd one is "wrong" because the 2nd column is a wrong interpretation because $20 is hex.

Could you give me an example of your assembler code, what is going wrong there.

[appden]

The 2nd one is "wrong" because the 2nd column is a wrong interpretation because $20 is hex.

That depends on the context, which this extension cannot know. I see you're looking at Z80 assembly, where the $ prefix indicates a hex value. However, I'm looking at x86 assembly in AT&T syntax, where the $ prefix denotes an immediate decimal value.

[appden]

I would guess it does not work for big negative numbers.

Good catch. I just pushed up a fix to do two's complement on an arbitrary sized value.

[maziac]

The 2nd one is "wrong" because the 2nd column is a wrong interpretation because $20 is hex.

That depends on the context, which this extension cannot know. I see you're looking at Z80 assembly, where the $ prefix indicates a hex value. However, I'm looking at x86 assembly in AT&T syntax, where the $ prefix denotes an immediate decimal value.

That is right, I used Z80 a lot. Maybe I have done too much with "old" languages. I thought this prefix was widely used but looking into wikipedia shows that it was mainly used by some older assembly languages especially by Motorola.

So, OK, we can make it more ambiguous so that it shows both possibilities: hex and decimal.

[appden]

Impressing one liner (or better two-liner). Thumbs up.

Thanks. 😀

The only thing: I think we need this for the decimal as well. Could you add that, too.

That's another good catch that I lazily missed, sorry! I just pushed an update to fix hex representations of negative decimals.