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

Check sharedCodeInCase: #bytecodePrimLessThanSistaV1 pragma #744

Open
PalumboN opened this issue Feb 12, 2024 · 1 comment
Open

Check sharedCodeInCase: #bytecodePrimLessThanSistaV1 pragma #744

PalumboN opened this issue Feb 12, 2024 · 1 comment
Labels

Comments

@PalumboN
Copy link
Collaborator

          The pragma is necessary for slang translation.

But with my changes such a translation is not valid anymore.
We should probably discuss this better.

Originally posted by @guillep in #743 (comment)

@guillep
Copy link
Member

guillep commented Feb 13, 2024

Just to document it, here it is.

The interpreter is made so all functions/methods are inlined by default by slang if possible.
This way, there are as few exit points from the interpreter function as possible.
However, this can create code explosion for long methods that are shared by many bytecodes.
This is for example the case for the send bytecodes that all call the long routine to lookup + activate.

To avoid this, instead of inlining long methods into the interpreter loop, some of these code paths are inlined once and shared by all the users using a goto.
The pragma sharedCodeInCase: controls this. It tells that the function should be inlined only once in the context of the bytecode given as parameter of the pragma. Then, Slang will translate all calls to this function to a goto if they are not the owner of the shared case.

Now, the point is that since this sharedCodeInCase: is implemented through gotos, this means that control jumps to the shared code but it's not easy to make it come back.
This means that this only works when the shared code is the tail of the bytecode: we don't need its return value, and we don't need control to come back. That's why shared code cases will in general be responsible for fetching the next instruction or doing the corresponding stack manipulation (pushes/pops).

-- EDIT--

also just FTR, why this is an issue in #743 (comment)

The thing is that to be able to translate booleanCheatTrueSistaV1 et al correctly in Druid, we need to have a single pop instruction and not two (one at the end of each tail. The refactored code does that by extracting the pop to the caller, and using the return value of the offending function. But this breaks the premise of the sharedCodeInCase:.

@PalumboN PalumboN added the druid label Feb 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants