-
-
Notifications
You must be signed in to change notification settings - Fork 171
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
[Feature Request] Literals (inline section fragments) #500
Comments
The real issue is, where to put it? "Some place" isn't too descriptive. Perhaps at the end of the current section? That being said, it seems like an interesting way to do jump tables:
|
It can be an explicitly marked constant pool, similar to ARM assemblers. |
The one I saw defaulted to the end of the assembly after your code, but there was a command to relocate it to wherever else you wanted |
Note that square brackets collide with memory accesses. In fact, this would mean that parsing is no longer context-free:
I'd suggest using curly braces instead.
Note that this kind of delimiters is used in quite a big family of languages already ;) |
Unresolved question: how would label scoping work here? |
I assume locals before a global would be local to the braces and globals would work as always. |
I saw this feature in the rare MIDAS assembler for PDP-10, which you'd think would be hard to get working or find docs for, but actually an easy self installing emulation package and extensive documentation for Midas and its OS are here ITS on Github |
Quick comment: parens, brackets and braces cannot work for this. Parens are used for expressions, brackets by memory accesses, and braces by symbol expansions (including outside of strings). So something else would be needed. Other than that, I'm not really sure about how useful this is; my main concern with this is code mixed in the middle of data, which I'm afraid would hurt readability in cases more trivial than in the OP. Implementation doesn't sound too complicated, but I'm seeing major pain points, such as specifying the location at which the code should be stored, or the fact that looks a lot like |
After further discussion, I think this might be worth it though in fairly minor ways (compared to current solutions), so I won't close this, but this is low priority as far as I'm concerned. Anyone else willing to take a stab at it is welcome, however. |
The proposition here is quite different from ARM assemblers. The literal pools there are typically used when numeric immediates are used that cannot be represented in 8-bits, (combined with some number of rotates as per the spec). It is also used for syntax like tl;dr I don't think this is a good idea, not least for the combining code/data argument. Also, I can't imagine a use case where such a syntax would be appropriate. |
In this case, double brackets would work perfectly. This might be complicated to parse, though, since the lexer would have to know to parse |
If #244 were implemented, allowing two sections to be in the same bank even if they're floating, this could make use of it. The parser could allow |
The problem of implementing #244 is that there's no way to adapt the bin packing algorithm to work with the additional constraints. |
As you said in Discord, section fragments would actually be fine here. Without this "literal" feature, people would manually put code blocks in the same section anyway, so it's fine if each |
Note that besides the PDP-10's MIDAS assembler, ASMotor itself has had these since 2019:
(It doesn't allow |
This is gonna be the weirdest feature request, and I don't mind if you don't think it worth adding. But I've dabbled with some old Mainframe assemblers from back in the 70s, and one of them had an interesting feature they called "Literals".
Basically, you could put code in square brackets, and it would cause that code to be assembled in a block at the end of your code (you could also relocated this block to other places, and I think you could redefine it several times thru your code), and the square brackets would be replaced with the address it ended up getting assembled to.
So you could type things like:
ld hl, [.db "HELLO WORLD"]
call Print
and the string would get assembled to some place, and replaced in the hl with its address. You could also use it to call a short block of code that returns, things like that.
Like I said, while useful, this is not exactly a standard feature, and I don't mind if you don't think it worth adding.
The text was updated successfully, but these errors were encountered: