freenode/#sicl - IRC Chatlog
Search
15:27:30
beach
Here is what I am currently working on. I want to adapt the structure of the HIR code so that it is easier to translate to the final executable that is described in the draft paper on call-site optimization.
15:27:40
beach
To do that, I introduced an AST class and a HIR class for calls to global functions explicitly named on the call site. So a call such as (F ...) where F is global will no longer get translated to an FDEFINITION followed by a CALL, but instead to an instance of the new class.
15:27:46
beach
Then, instead of hoisting FDEFINITION-INSTRUCTIONS, I will just leave the NAMED-CALL-INSTRUCTIONs as they are for further translation. This translation will ultimately lead to an instance of something like CALL-SITE in the code object, and an unconditional JUMP instruction in the final code.
15:28:04
beach
But for the purpose of the HIR evaluator, I subclass the NAMED-CALL-INSTRUCTION and give it the function cell in a slot. I already have code for the HIR evaluator to translate this new instructions, and I have code to collect the NAMED-CALL-INSTRUCTIONs in HIR and stick them in a list in the TOP-LEVEL-ENTER-INSTRUCTION (which should probably be in the code object at some point instead).
15:28:06
beach
I now need to define the TIE function so that it goes through that list and fills in the function cells before the top-level function is called.
16:41:44
beach
I need to think some more about how tying (i.e., associating a code object with a particular run-time environment) is going to happen in native code. There are two main aspects to tying. One is the call sites and the other is the non-trivial constants and the LOAD-TIME-VALUEs.
16:43:28
beach
Call sites should not be hard in the native case. There needs to be some standard object for each call site. These objects are kept in some container, probably a list, in the code object.
16:45:11
beach
Each call site indicates the name of the global function, the list of arguments, and an offset into the code vector (also kept in the code object) where the address of the jump instruction is located. For each argument, there is some representation of where it can be found, like a register or a stack location.
16:46:45
beach
As far as call sites are concerned, tying invokes some function in the environment, giving it the list of the call sites. That function then creates the snippets and patches the code vector accordingly.
16:49:03
beach
For constants and LOAD-TIME-VALUEs, here is how I see things. To access a constant, the code does a PC-relative load. The index into the code vector of the relative location of the LOAD instruction is kept track of so that it can be patched once the code vector has been allocated.
16:49:39
beach
The tying function allocates a vector to hold non-trivial constants and results of LOAD-TIME-VALUEs.
16:50:08
beach
Probably, the top-level function of the code vector is given that vector as an argument.
16:50:54
beach
That top-level function executes the LOAD-TIME-VALUE forms and stores the result in the vector. Non-trivial constants are just stored as such.
16:51:54
beach
The code vector is then patched with the distance between the PC-relative LOAD instruction and the element in the vector.
16:54:22
beach
So I need a way to indicate to the allocator that code vectors and the vector of constants should be allocated in the global heap.
16:57:11
beach
During bootstrapping, I can capture such allocations and reserve space in the (huge) host vector representing the global heap, and I can store the correspondence between the object and its address in the global heap in a hash table.
16:57:52
beach
This table is needed anyway when I turn the isomorphic graph into a target graph, so I am just allocating some objects early.
16:58:46
beach
Then I need HIR instructions to get the address of an element of a vector in the global heap.
16:59:32
beach
During bootstrapping, the HIR evaluator translates these instructions into table queries.
17:01:00
beach
So, anyway, the message here is that I need to start thinking harder about how the tying is going to happen in the native case, and I need to find a way to emulate it during bootstrapping.