Mars assembly: Disallow global varnames; add special instructions to access globals

[Matt Giuca]

Usages of Mars assembly are currently complicated by the fact that all of the following instructions need to deal with the possibility of some of their arguments being global variable names:
- mov
- ld_field
- fieldset
- fieldreplace
- arraylit
- call
- parcall

Back-ends and middle-ends may require special cases for a) varnames which refer to global functions, and/or b) varnames which refer to computable global constants.

In particular, back-ends must be prepared for any of the above instructions to execute code if a computable global constant is supplied, which goes against the principle that each instruction does one thing. The type dictionary transformation currently under consideration will also have a hard time dealing with both global function and CGC names encountered in instructions.

Therefore, the proposal is to add four new instructions. While this will dramatically increase the size of the instruction set, it should reduce complexity in handling all of the above instructions throughout the system. It will also bring global functions to parity with constructors, which currently can't be referred to in a variable name, and remove the special case where 'varname' in some instructions cannot refer to a global, while in others it can.

The new instructions are as follows:

ld_cgc varname, cgc_name
Loads the value of a computable global constant into a local variable name. This may execute the body of the CGC or restore the result from a cache, depending on the implementation.

ld_func varname, func_name
Loads a global function into a local variable name. This does not execute any code (much like ld_ctor). func_name must be a global function name, not a CGC or a constructor.

call_global varname, func_name, list(atom)
Calls a global function, storing the result in a local variable. func_name must be a global function name, not a CGC or a constructor.

parcall_global varname, func_name, list(atom)
Partially-applies a global function, storing the resulting function in a local variable. This does not execute any code. func_name must be a global function name, not a CGC or a constructor.

Importantly, these are the only four instructions which can refer to a global variable at all (unless you count ld_ctor). ld_cgc and call_global are the only instructions which can actually execute code in a global variable.

Ideally, there would be two additional changes made:
- There would be no such thing as a CGC in the bytecode at all (and no ld_cgc instruction). However, this would require a proper thunk mechanism, so for now, the bytecode supports CGCs directly.
- There would be call_ctor and parcall_ctor instructions, for parity with the call_global and parcall_global instructions. But we've done okay without them so far. (The only real reason to introduce call_global and parcall_global is to allow optimisation of type dictionaries.)

[Matt Giuca (mgiuca)]

While doing this, move gvname out of varname. I believe now every single varname(gvname(_)) is a special case; make it something other than a varname. The AST representation can still store names as varname(svname(_)) until it knows better, and then global names are turned into something completely different.

[Matt Giuca (mgiuca)]

Fixed in trunk r1184.