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

Obscure feature requests #165

Open
erkyrath opened this issue Mar 18, 2022 · 5 comments
Open

Obscure feature requests #165

erkyrath opened this issue Mar 18, 2022 · 5 comments

Comments

@erkyrath
Copy link
Contributor

This is various pieces of information which the compiler could provide which we don't have a real use case for, but the idea came up and I want to write it down. Very low priority.

@erkyrath
Copy link
Contributor Author

Current routine address

Maybe a system constant #current_routine. This returns routine_start_pc with marker IROUTINE_MV. (Divide by scale_factor in Z-code.) If used outside a routine definition, it's an error.

@erkyrath
Copy link
Contributor Author

Number of local variables

Similarly, #local_variable_count could return routine_locals. Error outside a function definition.

@erkyrath
Copy link
Contributor Author

erkyrath commented Mar 18, 2022

Absolute address of a label

You can @jumpabs to a label given its address, but there's currently no way to get this. (Would only be possible in Glulx, as Z-code label addresses don't generally fit in a 16-bit value, and there is no @jumpabs in Z-code anyway.)

Label addresses aren't handled in backpatching; they're figured out by special code in transfer_routine(). So this is messy, and it would be messier if you want to retain the addresses of labels outside the code of the routine itself.

Might want a special syntax for this, maybe ..LabelName; -- defines the label as a global symbol and also adds it to a list of labels to remember through compilation.

(Backpatching this requires care, too. I think we'd need a new marker which indexes into a table of (routine address, offset).)

@erkyrath
Copy link
Contributor Author

Local variable index

The offset where a local occurs in the locals segment. Like #g$GLOBAL, but for locals. The obvious spelling would be #l$LOCAL.

This value would be pretty hard to use. There's no way to access the locals segment except with an opcode argument, and those have fixed offsets. I guess self-modifying code could generate an opcode to do this.

@curiousdannii
Copy link

This value would be pretty hard to use. There's no way to access the locals segment except with an opcode argument, and those have fixed offsets.

Yeah I've realised that... that might end up being the trickiest part of all this. Or maybe just the most verbose - I could do it with a long switch statement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants