freenode/#clasp - IRC Chatlog
Search
13:29:24
lxsameer
hi folks, i'm interested to know about clasp's type system implementation. is there any article or paper related to that topic ?
13:30:00
lxsameer
also could you please point me to the code which is related to clasp's type system ?
13:34:33
Bike
lxsameer: what specifically do you want to know? for subtypep, which is most of the logic, we just use baker's algorithm, which i'd link you to but the site appears to be done
13:35:26
Bike
https://dl.acm.org/doi/10.1007/BF01807504 https://www.lrde.epita.fr/~didier/research/publications/papers/valais.19.els.pdf
13:35:34
lxsameer
Bike: i'm interested to know how you implmented a dynamic typed language on top of llvm , how do you do type infer and stuff like
13:43:14
Bike
we're just starting to get type inference working, but it's totally a lisp thing; llvm is irrelevant to it
14:10:33
lxsameer
Bike: interesting, so basically these i8 values are a pointer to the data which tagged with the type of that data right ?
14:11:37
lxsameer
Bike:thanks mate, I have to read those papers and the code, but i'm pretty sure i'm going to have many questions
14:14:09
lxsameer
Bike: so on the llvm level you have only and only one type right, everything is in that type
14:15:10
Bike
depends on what you mean by AOT. it works like a normal lisp implementation, like you open up a repl and compile things from there
14:56:22
Bike
we have a lot of code that doesn't rely on bignums and ratios being normalized (e.g. we check if bignums equal fixnums, or if integers equal ratios). was there some time that we didn't try to keep everything normalized or what?
14:56:56
Bike
we also have stuff checking if reals equal complexes, but maybe that's necessary because float zeroes are weird
15:09:12
drmeister
There was a big update last night of the deploy script, quickclasp, cando and clasp.
15:10:50
drmeister
I'm bringing back the fork-server as well. So with jupyterlab we start an instance of cando and the jupyterlab starts a fork-client that tells the fork-server to fork a child and that then takes over the jupyterlab session.
15:12:13
selwyn
drmeister: re quickclasp, copying over the directory structure should just work, not sure why it hasn't
15:14:17
selwyn
at a guess, the version of sbcl that is used on your user account may be causing a problem
15:15:25
selwyn
or maybe it's not finding the correct quicklisp directory. i could login to check, but since i don't have access to your account, i'm not sure i would be able to diagnose anything
15:17:17
Bike
drmeister: you've had line nine clasp instances on bigmac running the regression tests since sunday, is that intentional?
15:23:09
drmeister
Bike: I'm thinking that we add some additional slots to FunctionDescription that point to multiple entry points and make FunctionDescriptions GC managed objects (FunctionDescription_O) and then Function_O entry_point's become tagged pointers to FunctionDescription_O.
15:23:42
drmeister
Call sites will then use the FunctionDescription_O, index into the call-site vector and call the appropriate entry point.
15:25:08
drmeister
We are thinking of adding a non-moving pool to MPS that is automatically managed and supports interior pointers for code and FunctionDescription_O's and Code objects will live in this non-moving pool.
15:26:10
drmeister
Then code will not move in one session, it will be GC'd and there will be some fragmentation and an image save/restore will do one round of code compaction.
15:27:20
drmeister
There will be a separate ObjectFile_O object that lives in the AMCZ pool that the FunctionDescription_O object will point at and keep alive.
15:27:46
drmeister
The ObjectFile_O objects will be saved during image save and used to generate runnable Code objects at image restore time.
15:28:33
drmeister
I'm probably going to move literals directly into the code and have a vector of literal offsets for fixing up the code when literals move.
15:30:12
drmeister
I can implement all of this in macOS at any time. Linux still needs to catch up. I'm talking with Lang Hames.
15:30:32
drmeister
We may want to convert our compiler so that we generate one llvm::Module per llvm::Function.
15:31:24
drmeister
SBCL and I don't think SICL will do this - they have collections of functions that GC together.
15:32:08
drmeister
It's what we have right now as well. If it's not better to have one Function/Module then I can do this as well.
15:48:43
Bike
I'm not sure I understand the function description part. what memory reads actually happen at runtime?
16:01:40
drmeister
So (funcall #'foo 1 2 3) would read the tagged FunctionDescription_O pointer FOOFD out of the Function_O object in #'foo.
16:02:46
drmeister
Then it would call FOOFD[offset-for-call-with-3-arguments TIMES word-size MINUS FOOFD-tag] ?
16:03:48
drmeister
This adds one extra indirection. Currently we read the entry_point from the Function_O object in #'foo and call that.
16:06:27
drmeister
Oh yeah - I was going to attach the FunctionDescription_O objects to the Code. So that the FunctionDescription_O keeps the code alive.
16:06:52
drmeister
I can't make the pointers from the entry_point vector into the code keep the code alive. Interior pointers only work from the stack.
16:08:02
drmeister
So we add a GCArray to the end of the FunctionDescription_O and put the code in there. Then they live and die together.
16:10:04
drmeister
Right - then I need one FunctionDescription_O = one function (multiple entry points though) = one llvm::Module.
16:10:43
drmeister
If I have multiple functions in a block of Code then I have a problem of what do I do with multiple FunctionDescription_O objects - it doesn't work.
16:11:33
drmeister
SBCL solves this problem with special pointers that are interior pointers to entry points in blocks of code. They are on the heap but they are interior pointers that keep the entire code block alive.