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

Implement [[ fragment literals ]] #1614

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Rangi42
Copy link
Contributor

@Rangi42 Rangi42 commented Jan 17, 2025

Fixes #500

Replaces #716 and #1603

Anywhere you would normally use an address, such as dw Label or ld hl, Label or call Label, you can use a [[ fragment literal ]] instead. Each fragment literal becomes its own SECTION FRAGMENT to be appended to the current section.

This feature is referred to as "code/data literals" in ASMotor,
and simply as "literals" in some older assemblers like MIDAS
for the PDP-10. RGBASM already had the "section fragments"
feature for keeping disparate contents together when linked,
so these worked naturally as "fragment literals".
@Rangi42 Rangi42 added enhancement Typically new features; lesser priority than bugs rgbasm This affects RGBASM labels Jan 17, 2025
@Rangi42
Copy link
Contributor Author

Rangi42 commented Jan 17, 2025

Summarizing some points from the discussion in #500:

  • You can write single-line fragment literals like [[ db "Hello world!" ]], or put the contents on their own line(s), following whatever indentation style you prefer.
  • Since these literals are implemented as section fragments, they get appended after their containing section, but any exact placement beyond "somewhere in the same bank as their containing section" is not guaranteed and should not be relied on. (For example, using jr across fragment literals is a bad idea.)
  • The parser requires end-of-line tokens as line terminators, not separators, including directives which must manage their own newlines and are "DEFINITELY one of the more FRAGILE parts of the codebase" (so refactoring them to be separators would be a lot of hard work). This means that lexing the ]] token has to inject an end-of-line token before itself, to allow ]] on the same line as its content.
  • ASMotor has had these since 2019 as "code/data literals". The implementation is similar to this PR, creating a new section for the literal content, placed in the same "group" as its containing section, and using a special label to evaluate the literal content's address.

@Rangi42
Copy link
Contributor Author

Rangi42 commented Jan 17, 2025

Since this is a backwards-compatible feature, I think it's fine to add in a patch-level release (i.e. 0.9.1 instead of 0.10.0). We've done so before, like with 0.6.1 adding rgbgfx -o - - support, 0.5.2 adding compound assignment operators like DEF x += 1 (and also deprecating SET in DEF x SET x + 1), 0.5.1 adding CHARLEN and CHARSUB, etc. It's just that more recently, we've had a slower release cadence and "minor" releases (more like major ones, it's just that we're still stuck in 0ver) have felt more appropriate.

@Rangi42
Copy link
Contributor Author

Rangi42 commented Jan 17, 2025

Note that one of the initial blockers to this feature was the global parser state that fragment literals had to back up. We've long since gotten rid of that, consolidating them into the stacks of lexer state and fstack nodes.

@Rangi42
Copy link
Contributor Author

Rangi42 commented Jan 17, 2025

If anyone wants to build this and test it out before it gets merged -- notice any bugs, inconvenient limits, nice use cases, etc -- that would be very helpful!

@Rangi42 Rangi42 added this to the 0.9.2 milestone Jan 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Typically new features; lesser priority than bugs rgbasm This affects RGBASM
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature Request] Literals (inline section fragments)
1 participant