freenode/#sicl - IRC Chatlog
Search
4:58:12
beach
I am contemplating a question of elegance and performance during bootstrapping. One of the first-class global environments I use, like E4 or E5 is going to be the template for the final system, in that it will contain no functions imported from the host. It will still contain host objects such as CONSes, symbols, numbers, and probably also packages.
4:58:21
beach
When the binary executable contents is written, those host objects will be replaced by SICL equivalents. Now, during bootstrapping, I often have a choice between a host function and a SICL function. In particular, for functions on lists, I can import the host version of something like MAPCAR, or I can load the SICL version from a SICL FASL file.
4:58:29
beach
The SICL version will be significantly slower, because it is executed using the HIR interpreter. So the first question is: Should I use SICL versions of or host versions in environments other than the last?
4:58:40
beach
The second question is: Should I use SICL versions exclusively in the last environment, or should I use host versions during bootstrapping (for performance reasons) and only load SICL versions right before the final executable is generated?
4:58:47
beach
The third question is: Should I import only those host functions that I absolutely need (as I do now), carefully justifying why they are needed, or should I just import a lot of host functions, like all the functions on lists?
4:58:51
beach
The fourth question is: In the last environment, should I load only those SICL functions that are required in order for the executable to function, and load the rest from the executable itself, or should I load lots of other functions as well?
4:59:19
beach
I mean, I am fully capable of making a decision myself, but it would be interesting to hear opinions.
5:01:42
beach
So for the first question, I have a tendency to think that I should use host functions, because I am likely to add more work during bootstrapping, and it would be silly to take a performance hit just because I can't use compiled versions of SICL functions during bootstrapping.
5:02:50
beach
For the second question, I think the reason is the same. There is no reason to use SICL functions during bootstrapping when there are host functions that will do the same thing, except faster.
5:03:46
beach
For the third question, I think I want to limit the number of host functions I import to the strict minimum, justifying each one with a comment. But that's a lot of work.
5:06:20
beach
For the fourth question, it is clear that there will be SICL stuff that I can't create in the host. In particular, I am thinking of hash tables. EQ hashing is going to depend on address, and that won't be known until the last minute.
5:06:21
beach
I plan to implement a simple version of the hash-table interface, but that uses lists instead, and use it during bootstrapping. In the final system, those hash tables will need to be replaced by real ones.
5:11:23
beach
The advantage of using SICL versions during bootstrapping is that those functions will then be exercises more, but I can write a bunch of tests running in the last environment after all the SICL versions have been loaded.
8:41:06
MichaelRaskin
Is it likely that these decisions will later affect cross-compilation work? (My immediate reaction is that one would want to use host functions for host data structures, though, so I guess this doesn't chage the conclusion anyway)