Promote immediates.

[ltratt]

This is a conservative use of yk_promote operating on Lua opcodes which themselves use immediates (e.g. OP_ADDI). It does have a small (just over 1% improvement) effect on big_loop.lua, but the main point of this is to show that we can start to move an interpreter in a yk-specific direction.

Please wait until all reviewers have OKed this, as it's important for us to all see what this sort of thing looks like in practise.

[ptersilie]

Any hint what is being promoted here? I assume for OP_EQI it promotes the second argument, e.g. a == promote(b)? But I'm even less sure about the others.

[vext01]

Any hint what is being promoted here?

It's not very easy to follow, but if you follow the chain of macros it eventually ends up getting an integer value from an address relative to the instruction pointer.

e.g.

 #define sC2int(i)   ((i) - OFFSET_sC)

where i is the current instruction.

This looks feasible to me.

[jacob-hughes]

This seems sensible to me

[ltratt]

As Edd said, the macros mean that it's a bit hard to see what's going on. I'm not totally certain if/how to document it, either.

[ptersilie]

I guess my question is how did you decide which values to promote?

[ltratt]

I guess my question is how did you decide which values to promote?

Those which are used as immediates in Lua opcodes. Unfortunately you have to do a research hunt to work out how...

[vext01]

@ptersilie are you happy for me to merge this?

[ptersilie]

Yes, please go ahead.

[vext01]

Hrm, yklua failed to link.

[ltratt]

Leave it to me.

[ltratt]

d9a3ce2 guards the changes with USE_YK. I suspect we should move away from USE_YK, but that's something for another PR. Will need squashing if this is acceptable.

[vext01]

Please squash.

[ltratt]

Squashed.