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

Strange-ish lexical behaviour, please review #107

Closed
bdw opened this issue Jun 26, 2014 · 0 comments
Closed

Strange-ish lexical behaviour, please review #107

bdw opened this issue Jun 26, 2014 · 0 comments

Comments

@bdw
Copy link
Contributor

bdw commented Jun 26, 2014

I was working on implementing JIT getlex / bindlex and I noticed some strange-ish behaviour in getlex. Specifically, to determine if a NULL has to be vivified into an object / vmnull, getlex checks for an entry in the 'lexical type' array.

This lexical_type array either comes from the spesh candidate (if present) or from the static frame. The frame is then passed - along with the index - to MVM_frame_vivify_lexical.
But MVM_frame_vivify never looks at spesh_cand->lexical_types. So that's a bit strange.

Furthermore, MVM_frame_vivify_lexical seems to be happy to accept an index greater than what will fit into the lexical_types array of the static frame, and if it doesn't fit, will look at the static frames' lexical type arrays of inlined spesh static frames. But getlex never bothers to check if the index is within the bounds of the lexical_types array.

So in short, the use of lexical_types in OP(getlex) and in MVM_frame_vivify_lexical (and possibly elsewhere) doesn't seem consistent, and possibly buggy.

What I'd like to do is move the decision between the two types of lexical types up to frame invocation level, that is to say, add a field 'effective_lexical_types' to MVMFrame. Furthermore, I'd also like to 'merge' the lexical type arrays of inlines, which i /think/ shouldn't be a problem, because apparantly indices are already moved about during inlining, as they obviously should.

@bdw bdw closed this as completed Jul 25, 2014
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

1 participant