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

Interpret real operands that omit decimal as a real value #2

jberryman opened this Issue Jan 17, 2019 · 2 comments


None yet
2 participants
Copy link

jberryman commented Jan 17, 2019

This is a documented "quirk":

#  - Signed fixed point arguments (S1.14, S1.9, S.10) may be
#    entered using an unsigned integer equivalent value. This 
#    causes a conflict with SpinASM, when entries like -1 and 1
#    are interpreted differently depending on how they are used.
#    In asfv1, all operands are treated alike, so to specify
#    a real number, the decimal part is compulsory: Eg -1.0, 1.0.

I'm new to fv1 and this caused me some confusion in code I was assembling. Is this "quirk" supposed to be a feature or is this just a deficiency of asfv1 (i.e. something you would accept a pull request for)?

It's not clear to me why you'd want to be able to specify e.g. 1 and mean 0x0001 in s1.14

Thanks for your work on this project!

jberryman added a commit to jberryman/asfv1 that referenced this issue Jan 19, 2019


This comment has been minimized.

Copy link

ndf-zz commented Jan 21, 2019

Hi jberryman,

I originally intended this "quirk" to be a feature that resolves ambiguity of argument types in the Spin provided assembler. For example, you can access a delay line with an integer literal and it means an integer offset, but the same text would be interpreted as a fixed point real value for other operations. By requiring all fixed point real literals to include a decimal, there is no ambiguity. For example:

AND 1.0

These two separate valid statements should probably be treated differently. I also liked the idea that you could specify an argument (eg s1.14) by the actual integer that will be used, not by the converted value - but in that case you can always provide an unambiguous hex or binary representation.

Unfortunately, my code breaks a lot of Spin examples where they mix integer literals and fixed point literals throughout the code, and maybe consistency in the scanner/parser is not that valuable to users.

I'll have a look at the commit.

Thanks for the comment!


This comment has been minimized.

Copy link

jberryman commented Jan 22, 2019

Thanks a lot for the response; I think I understand what you mean. I'm not sure if the commit attached makes a lot of sense to be honest. It was mostly a quick experiment to see if it would work to get a successful roundtrip from ROM through a decompiler I'm using and back again, for a particular program I'm trying to tweak.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment