Global variables are now loaded from _ENV.

[rbartlensky]

In the Lua specification, the global variables are loaded from a global table called _ENV. Programs can overwrite this variable as well, and can read and write from/to it. There are a few changes:

• The compiler:
  • assumes that _ENV is always stored in register 0
  • replaces all global variable writing, and reading with GetAttr, and SetAttr instructions
• The vm:
  • always creates a LuaTable and stores it in register 0, so that globals can be easily accessed.
  • can now set and get attributes of LuaTables

[ltratt]

Can you benchmark a couple of programs that do simple global read/writes before/after this PR?

[rbartlensky]

Can you benchmark a couple of programs that do simple global read/writes before/after this PR?

I have a hunch that programs before this PR are slightly faster, but only because I implemented globals without considering _ENV. But yes, I can try to create a few programs, and benchmark the interpreter on them!

[rbartlensky]

I would like to merge this PR before writing any benchmarks. I am going to implement functions and loops first, and then come back to optimizing the _ENV lookups.

[rbartlensky]

As an extra example, _ENV is handled in the following way:

Example program:

x = 2 -- equivalent to _ENV["x"] = 2

The compiler generates the following bytecode:

LDI     1 0   # load into register 1 integer 0
LDS     2 0   # load into register 2 string 0
SetAttr 0 2 1 # _ENV is always in register 0, _ENV["x"] = 2

and the tables:

Strings: { 0 -> "x" }
Integers: { 0 -> 2 }
Floats: {}

Every LuaString has an extra field which is the index of the string in the constant table. This field will be None if the user generates strings through concatenation.

The VM only executes set/get_attr if the loaded LuaString doesn't have an index. If it does, then the attribute is looked up via the env_attrs vector.

[ltratt]

I guess I was expecting something more like "GLOBAL_ASSIGN 0 2" where "0" == "print" and "1" is register 1 (which, presumably, holds the value 1). However, this is something we can optimise / change later.

[rbartlensky]

I guess I was expecting something more like "GLOBAL_ASSIGN 0 2" where "0" == "print" and "1" is register 1 (which, presumably, holds the value 1). However, this is something we can optimise / change later.

I see what you mean. That might speed things up, and the changes should be easy to make even later on.

[rbartlensky]

Ready for another review!

[ltratt]

Please squash.

[rbartlensky]

Squashed!