libera/#clasp - IRC Chatlog
Search
18:43:41
drmeister
https://github.com/clasp-developers/seqan-clasp/blob/5caa2e1e6028525276a6b6ba770fa6e334563d58/src/seqan.lisp#L152
18:44:40
drmeister
What I'd like to do next, is get rid of all the SingleDispatchXXX_O classes and replace them with generic function dispatch.
18:45:39
drmeister
And expose the generic function methods that use multiple dispatch directly from C++ code so we don't need to write things like:
18:45:45
drmeister
https://github.com/clasp-developers/seqan-clasp/blob/5caa2e1e6028525276a6b6ba770fa6e334563d58/src/seqan.lisp#L152
18:46:58
yitzi
At least with the single dispatch I was able to get rid of the `dispatch@r1v` functions and just do this https://plaster.tymoon.eu/view/3363#3363
18:47:46
yitzi
Then just call `(setf (documentation dimension) ...)` to set the documentation strings later.
18:50:48
drmeister
There - for the first time I constructed a concrete example on how to expose compile-time multiple dispatch as generic function methods from C++.
18:54:22
drmeister
We would use those defmethods to create a "call history" to dispatch on the provided types and the lambdas would be the effective methods.
18:56:27
drmeister
I didn't test the self-reference for entry-points. Let me see if I can get that to work.
19:03:26
drmeister
Here's another timing comparison that is useful. Compare the bytecode speed to compiled cclasp code speed.
19:08:11
karlosz
so not only will we squeeze out jumps but also i envision using it to get rid of cells
19:08:41
karlosz
i think we'll get a speed up once we stop using read_uint16 and short jumps + reading from literals smartly
19:45:45
drmeister
So get the bytecode compiler working and then get back to work on the llvm compiler. :-)
20:25:22
Bike
it also looks like (lambda (&key)) compiles the same as (lambda ()), which is wrong, since :allow-other-keys has to be acceptable
20:28:02
karlosz
Bike: oh yeah, &key is wrong, but i was careful with allowing :allow-other-keys in the correct circumstances
20:54:05
karlosz
long isn't even compiled yet, but at least we get an error at compile time if we hit a program that needs it
20:55:28
Bike
i don't mind leaving LONG for last, given that we very possibly don't even need it for booting clasp
22:20:06
drmeister
Now that EntryPointBase_O points back to itself and inherits from the class formerly known as Function_O
22:48:20
karlosz
one note though: the VM will have to be updated to make the pc offset work from the start of the instruction. which might be more natural anyway
22:50:16
Bike
nice. yeah that should be easy, in the clasp vm it will just mean changing some -2s to -3s
22:53:08
karlosz
still should be portable to C++ - i did use a single dispatch closure mechanism thingy
22:54:10
drmeister
Name changes done, cclasp-boehm builds. Running static analyzer and then I'll push everything.
23:21:57
karlosz
drmeister: the compiler needs to learn how to do unwind protect, but other than that, very close
23:38:57
drmeister
Great - once the compiler is done and we start translating it we can compare the output of the CL compiler with the C++ compiler and identify problems quickly.
23:43:39
karlosz
yes. the CL compiler doesn't do anything crazy - it should be translatable to C++ without much fanfare
1:15:05
Bike
loading bytecoded functions shouldn't be hard, right? all their components are dumpable (except maybe constants, but then you couldn't compile-file that anyway)
1:25:05
drmeister
Well, that's a bit of a puzzler isn't it? With compile-file we use the literal compiler to generate code that evaluates to initialize the literals vector.
1:26:59
drmeister
It loads and compiles all of the bclasp source code and clos and then the cleavir code.
1:28:40
drmeister
Later we can interface the literal compiler with the bytecode compiler - but will we need to translate the literal compiler into C++?
1:33:40
Bike
i kind of thought we'd be compile-filing with the bytecode compiler, but i haven't deeply thought it through
1:51:57
drmeister
When we compile with the bclasp compiler or the cclasp compiler we do different things with literals than we do with compile-file. I guess we should look at that.
1:52:49
drmeister
I've been thinking of the bytecode compiler/interpreter as a replacement for the C++ interpreter.
1:58:10
karlosz
yeah, i mean we just bytecode compile and interpret instead of running the interpreter