HW4: code generation

Better viewed as markdown

VTables

They are generated when each class is visited, except for those of Object, Object[], int[] and boolean[], which are generated in the bootstrapping.

When the object vtable is generated, so is the array table, which just contains a reference to the supertype (in our case Object) and an unused pointer to the declared type of the element's vtable.

supertype pointer (Object) <-- vtable pointer
element vtable pointer (unused)

Each type's vtable contains the supertype as the first element (trait shared with array type's vtables for easier cast type comparisons). Then they contain all the methods available to an object of that type, including all those inherited. As the dynamic type is not known, the number and position of the methods is not known when executing a method, therefore each method's pointer is prepended by the method's name hash (similar to fields in an object).

supertype pointer <-- vtable pointer
hash("method0")
method0 pointer
hash("method1")
method1 pointer
...
hash("methodN")
methodN pointer

Method calls

The basic scheme used for method calls and the structure of the stack frame is that described in the __cdecl used in GCC. In short, this is the execution of a method call:

1. The caller pushes the arguments in the stack, from right-to-left, leaving the 0th argument (the reference to this) at the top of the stack.
2. The caller executes call (the instruction pointer gets stored in the stack)
3. The callee now takes control, and its first action is to save the base pointer to the stack and set the base pointer to the current stack pointer. Therefore, the arguments and return address are available to the method.
4. The local variables are reserved and zeroed in the stack.
5. The CALLEE_SAVED registers are saved to the stack.
6. The method executes its code
7. The CALLEE_SAVED registers are restored to their original status.
8. The callee restores the stack and base registers to its initial statuses. This is accomplished with a leave instruction. Then it returns using ret. This removes the instruction pointer from the stack leaving only the arguments.
9. The caller finally removes all the arguments from the stack and obtains the return value from EAX.

Therefore, the stack frame follows the following structure (N arguments and M local variables):

top of stack <-- ESP
...
saved registers
localM <-- EBP - 4 - M * 4
...
local1 <-- EBP - 8
local0 <-- EBP - 4
Old EBP <-- EBP
Return EIP
this <-- EBP + 8
arg0 <-- EBP + 12
...
argN <-- EBP + 12 + N * 4

Variable and object representation

Primitive variables

They are represented by value, with both integers and booleans occupying 4 bytes, and booleans being represented as TRUE = 0, FALSE = 1.

Reference variables

Stored in the heap, using calloc (to zero-initialize them).

Arrays

On top of storing the array elements, some overhead is stored with it, namely a pointer to the array vtable for casts, and the size of the array to check the bounds of the array on accesses or assignments. The pointer to the array points to the vtable pointer (the first element in the object structure):

array vtable pointer <-- var pointer
array size
element0
element1
...
elementN

Objects

Stores a pointer to the object's type vtable and all the fields. As the dynamic type of the object cannot be determined and therefore the fields not statically ordered, each field occupies 8 bytes, with the first 4 containing the hash for the VariableSymbol that represents it and the others the value or reference to the field.

The hash allows hiding variables, but introduces an overhead when accessing a field, to look for the position in which it is located.

vtable pointer <-- var pointer
field0's hash
field0
field1's hash
field1
...
fieldN's hash
fieldN