freenode/#sicl - IRC Chatlog
Search
2:41:23
jcowan
I realized FWIW that symbols and packages must exist at runtime in CL-R if quoted symbols are to mean anything, since quoted literals have runtime existence. I am not prepared to say that (cons 'x foo) is not meaningful in CL-R.
2:41:44
jcowan
But they can be very simple: a symbol has a name, a package, and a plist, and a package has only a name.
2:42:38
jcowan
Also the (fully CL) packages created and consumed at compile time with defpackage are not the same as packages created at runtime by make-package.
2:51:52
jcowan
so that (eq (read) 'foo) will produce the right result if `read` reads the string "foo"
2:52:01
pfdietz
Ok. I suggested before that what you want to get rid of is the ability to know if a symbol has been interned (and to iterate over the symbols of a package). With that, the unused symbols can be GCed.
2:53:20
pfdietz
Literal symbols in the code would stick around in their packages, but nothing else would have to.
4:04:59
no-defun-allowed
i did find an interesting message about a hardware error in dmesg after the crash, but apparently that's just a cpu fault not any other hardware
4:14:02
no-defun-allowed
that said, an early batch of r5 1600s apparently had issues, and would crash gcc sometimes
4:34:24
pfdietz
Sure, there's read. But that doesn't mean unreferenced symbols can't be GCed. You may get a 'different' symbol the next time it's read, but how could one tell?\
6:42:45
beach
Here is the current thinking with respect to code generation. Compiling a file or a form will generate an AST and the file compiler will simply store the AST in a READ-able format that is already defined by Cleavir. So the AST will be the FASL format.
6:42:56
beach
When the FASL file is loaded, the AST will be turned into a HIR graph that has a top-level ENTER instruction representing a function that will be enclosed and then called at load time. When that function executes, it will accomplish all the top-level actions that are required according to the source code.
6:43:05
beach
LOAD-TIME-VALUE forms will have been decomposed in a way that remains to be determined exactly, and that decomposition is done by using the result of heisig's fairly recent work.
6:43:14
beach
Compiling the HIR graph will create a "code object" as show in Figure 14.1 on page 47 (PDF page 57) of this document: http://metamodular.com/sicl.pdf and in particular, the code object contains a "code vector" which is a vector containing the native code for the processor.
6:43:25
beach
The question is what the top-level enclose will do and what a nested ENCLOSE-INSTRUCTION does (in particular to determine the entry point). Here is what I am thinking now: The code vector will have been allocated in a place that does not move, so the addresses of the instructions are known.
6:43:32
beach
The top-level enclose puts the first address of the code vector in the top-level function to be executed and then calls it. A nested ENCLOSE-INSTRUCTION contains an offset into the code vector that is determined at compile time.
6:43:34
beach
The ENCLOSE-INSTRUCTION accesses the static environment, then the code object, then the code vector and determines the address of the first instruction of the code vector. It adds that address to its compiled-in offset and uses it to create the nested function.
6:44:18
beach
Now, today is Monday and Monday mornings are crazy around here. In 15 minutes or so, I will vanish for around an hour.
6:46:00
beach
By using the AST as the FASL format, I eliminate an entire, possibly very large, body of code that would need to be specified and implemented, namely the code for a specific FASL format.
6:46:18
beach
If performance should turn out to be a problem, such a module can be implemented later.
6:47:04
beach
But I think this current thinking is what is going to be the fastest way of getting a native system up and running.
6:47:46
beach
It means that not only the compiler but also Eclector must be included in the initial system, but I am now convinced that both those modules are fairly small.
6:48:15
beach
It suffices to look at the size of the FASLs generated by SBCL for those modules to get an idea.
8:42:18
jackdaniel
beach: does it mean, that your FASLs will be "portable" across different cpu architectures? or did I misread something?
9:03:12
heisig
Regarding portability - maybe it would make sense to have a list of SICL variables that are possibly platform dependent and store them in the FASL, just to make sure.
9:03:59
heisig
Then one could at least detect whether the conditions at compile-time are still met at load-time.
9:23:09
beach
Cleavir does have a bug right now I think, including for Clasp. It looks to me like CST-to-AST does not process the first argument of a LOAD-TIME-VALUE form. It should be converted to an AST and then to HIR. But I think fixing it may break a certain number of things, so we need to plan for it.
9:25:07
beach
It is rare that the consequences of such a bug are detected, and, as I recall, CLISP has always left the form in there without processing.
9:31:36
heisig
The bug would only arise if the null lexical environment at compile-time would be noticeably different from the null lexical environment at load-time, right?
9:36:06
beach
There are many restrictions on such differences, which is why it does not happen often.