freenode/clasp - IRC Chatlog
Search
6:48:42
Colleen
** TOPIC Clasp Developer Hangout - Combining CL and C++ for science | <https://github.com/drmeister/clasp> | <https://irclog.tymoon.eu/freenode/clasp> | <https://mailman.common-lisp.net/listinfo/clasp-devel> | Breaking News: <drmeister> I have the righteous sword of inlining to slay the princess and release the beautiful arithmetic dragon
9:05:55
drmeister
minion: memo for stassats: ext:compiled-function-file seems to work for me and M-. M-, jump me where I expect to go. Maybe I fixed it? My latest changes are in "newbuild"
9:14:29
drmeister
Currently I'm still using activation frames on the heap but in principle I could switch over to stack based frames and closures.
9:15:53
drmeister
dynamic-go-ast uses exception handling and local-go-ast uses environment cleanup/branch instructions.
9:17:11
drmeister
variable-get-ast and variable-set-ast - I'm still a little uncertain about those as well.
9:20:24
drmeister
stassats: I'll think on that. They most certainly do otherwise nothing would work. The variable-get-ast looks up the symbol in the environment and returns instructions for retrieving the variable (it's still works like an interpreter). Maybe I can do something more efficient now.
9:20:59
stassats
have a special variable, *current-lexical-env*, each time you start a new processing a body of LET/TAGBODY/LET, create a new instance of the environment with the added lexical information
9:21:45
stassats
now you also need a way to mark where the variables are coming from, so that if it's not originating from the same LAMBDA, they can be marked as captured
9:22:58
drmeister
The MINCOMP-XXX functions return these AST nodes and they have environments associated with then
9:24:06
stassats
when you start processing a lamda make it (let* ((new-lambda (make-lambda lambda-list)) (*current-lambda* new-lambda)) (setf (body new-lambda) (process-body ...)))
9:24:35
stassats
and when create variables you do something like (make-variable name value home-lambda)
9:24:57
stassats
then when you encounter a variable reference you see whether home-lambda matches *current-lambda*
9:27:10
stassats
or alternatively you can mark each node with the lambda node, then when you read or write a variable you push the node which reads or writes to the list of variable writers/readers
9:27:45
stassats
then when you process the resulting tree, you can check whether the variables are always read and written from within the same lambda
9:36:53
stassats
but maybe if you're not making a complex IR (since you're going to rely on cleavir), you don't need to collect readers/writers, just mark variables as being closed-over the time you encounter them