freenode/#clasp - IRC Chatlog
Search
19:28:34
stassats
just load everything in slime, incrementally modify the compiler, output some ir stuff, link it
19:29:31
stassats
just making sure that the host macros and constants and stuff like that do not leak into the target
19:42:58
drmeister
If we made the calls to functions in the "LLVM-SYS" package spool to a file and then write a little virtual machine in C++ that read those instructions and made the calls - that might be the best way to do this. Then we can keep translate.lisp pretty much the same as it is now and the code-generation code in translate.lisp would stay in translate.lisp.
19:43:44
drmeister
We could load Cleavir into sbcl the way that beach has been doing it now and first class top level environments might be very helpful here.
19:44:21
drmeister
There are all of the calls to the runtime functions implemented in C++ that cclasp makes that I'm not sure about
19:44:58
stassats
it wouldn't really be cclasp, just cleavir running in sbcl and compiling cclasp code
19:45:19
stassats
some of cclasp code would have to run on the host, macros and functions that are used my macros
19:48:20
Shinmera
frgo: Glad to hear. If there's anything in Deeds that you notice could be improved, do let me know.
19:48:30
drmeister
But it moves most of the work into Common Lisp rather than C++. That's extremely attractive.
19:49:08
drmeister
There's just this little virtual machine that needs to be defined and built in C++.
19:51:28
Bike
sorry, wasn't paying attention. but yes, bootstrapping from another implementation instead of having bclasp would be good if we can manage it.
20:13:17
drmeister
sbcl loads cleavir already. If we loaded Cleavir and then started compile-file'ing all of the cclasp files...
20:14:09
drmeister
There will be macros and eval-when's that need to be evaluated at compile-time. If they call runtime functions that sbcl doesn't provide - then we need to provide those.
20:19:43
drmeister
Hmm, there would probably need to be a configuration file that clasp generates that the sbcl compiler loads.
20:21:15
drmeister
I guess for boehmdc the configuration file that clasp generates won't have any typeq information defined.
20:23:43
drmeister
I think the FuncallableInstance_O and Instance_O changes I'm making will be for posterity.
20:29:46
drmeister
With FuncallableInstance_O inheriting from Function_O it's a simple range check of header values to determine if something is a Function_O.
20:30:05
drmeister
The function pointer for the executable code is at the same offset for all Function_O objects.
20:31:01
drmeister
In the case of FuncallableInstance_O objects the executable code is a little shim function that sets up a VaList_S structure for the arguments and then calls the dispatch function, which can be either the ECL dispatch code or fastgf.
21:09:16
drmeister
Bike: Is it straightforward to get Cleavir up and running in sbcl - it's the same environment that beach and you use all the time - isn't it?
21:11:59
drmeister
Here's what I think it will look like. (1) Run the iclasp-whatever executable and generate a CL source file that defines all kinds of constants that compiling cclasp requires.
21:13:51
drmeister
(4) Run the iclasp-whatever executable, load the instructions for the virtual machine -> many bitcode files, fasl files and executable for cclasp-whatever
22:09:33
drmeister
One last time - there is never a situation where there would be a need for a funcallable class - correct?
22:10:50
drmeister
I've spent the day teasing apart the implementation of Instance_O (includes behavior to support classes) and FuncallableInstance_O (does not include behavior to support classes but supports funcallableness)
22:54:41
drmeister
aclasp is compiling now with the new changes. I have to run an errand for a couple of hours - so I won't be here to fix things if it breaks. I'll have to pick this up again tonight.
22:56:44
drmeister
Just in case I did get everything right I pushed everything to 'dev-func' and I'll try building everything and running the static analyzer on the AWS system.
0:29:07
drmeister
It's going to take some rearranging. There are calls to llvm-sys functions that return values
5:58:28
drmeister
::notify Bike cclasp failed to compile when it runs into a problem with a typecheck in pprint.lsp. The complete backtrace is here: https://gist.github.com/drmeister/91bdedb3229ed403b8d91d6ff15919ac
6:23:04
drmeister
::notify Bike This is happening when building cboehmdc - so I think all type checks should reduce to typep.
7:14:44
drmeister
::notify Bike I think the check isn't allowing for the possibility that there is no typeq information for the type - there is no information for any types with boehmdc, because the static analyzer output isn't used by boehmdc. It needs to use gen-typep-check in this case. I'm going to hack a call to gen-typep-check into gen-primitive-type-check to just get the static analyzer running. You probably have a better way