Skip to content
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

Precedence issues between unary byte/word-access operators and postfix increment/decrement #106

Open
Bananattack opened this issue Feb 3, 2021 · 0 comments

Comments

@Bananattack
Copy link
Collaborator

Bananattack commented Feb 3, 2021

Currently all postfix operators have higher precedence than prefix operators. This has some unfortunate limitations though:

// Postfix increment in expression statement. Fails to compile.
// because it is evaluated as <:(hl++), which is not a permitted expression statement.
// Also because of precedence, it also currently implies a higher-bit increment followed by bit-masking.
<:hl++;

// Postfix increment in assignment right-hand side. Also fails.
// Similar to above parse, but different restrictions.
// It tries to decompose <:(hl++) into:
// a = hl; a = <:a; hl++; which will not work.
a = <:hl++;

++<:hl; // Prefix increment. Works fine.
a = ++<:hl; // Prefix increment. Works fine.

See if there's some way that the compiler can instead bind the unary prefix access operators with less precedence than incrementation (eg. by manual fix-up during parsing). Most of the time, we want normal prefix operator precedence rules, but post-incrementation is an exception.

Short of some other ambiguity, it would be nice to make <:expr++ always mean (<:expr)++ and not >:(expr++) so it has more useful semantics.

NOTE: these uses should continue to work:

// becomes a = l; due to register decomposition.
a = <:hl;
// take the low-byte of an address literal.
a = <:&myaddress;
 // constant indexing, so the address can be folded at compile-time, and then <: masks off
a = <:word_array[0]
// take the low-byte of some indirected larger-than-byte thing (if the platform were to allow it)
foo = <:*term;
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant