freenode/#sbcl - IRC Chatlog
Search
6:18:36
karlosz
hm, but this shouldn't have changed since the old days. sb-sys:structure!object has always existed
6:20:39
karlosz
Krystof: how did one do such a thing in your day? you would cross compile a fasl and load it into the host with just CL:LOAD?
6:22:40
karlosz
ive got no structs. the error i get is The loaded code expects an incompatible layout for class SB-C::DEBUG-SOURCE.
6:23:11
Krystof
I remember actually trying this for MIPS, where my host was so slow I could cross-compile PCL files one at a time and scp them across faster than the mips could just compile them
6:23:58
Krystof
hm, not sure. Possible that what I was doing meant that there wasn't any debug source
6:24:52
karlosz
would be great to hack on the XC in slime and actually load the code objects on the fly
6:36:49
karlosz
i disabled the layout check and now i get "undefined assembler routine sb-vm::generic-="
6:39:55
karlosz
*sigh* no more need to rename packages to cross compile, the work is offloaded onto actually loading these objects into the renamed system
6:42:51
karlosz
so having a cross compiler sbcl and a fresh sbcl to load the cross compiled objects works well
7:14:26
karlosz
the cool thing is that f is completely eliminated with the optimization and the (+ 2 .. ) can get folded with the 3 in F
7:14:52
karlosz
that's what i mean by exposing more data flow analyses by integrating the body of the function into the call graph
7:16:10
karlosz
those are deriving from the same source form, but the first one is with the upgraded locall analysis vs the second one which is stock SBCL
7:16:31
karlosz
i can't get the optimization to self build yet so clearly it has applications in self build as well
7:25:03
karlosz
technically this optimization should work for all local functions, not just those with tail calls. how do i put that in the pipeline...
11:52:14
flip214
stassats: I would appreciate it if you could provide some optimized convert-from-foreign-usb8 in CFFI..
11:52:52
flip214
I have a callback to lisp again which gets a void* and a length, and I need to get a (temporary) lisp array with element-type (unsigned-byte 8)
11:53:23
flip214
the CFFI function currently copies every byte out, one after another - which is the "right" thing to do as far as lifetime issues go.
11:55:48
flip214
How would I get a lisp array that points to these bytes, so I can call WRITE-SEQUENCE?
11:56:59
flip214
CFFI:mem-ref requires the bytes to be continuous in memory too... can't I cast or fake an array here?
11:57:49
flip214
of course, WRITE-SEQUENCE will also "just loop", so I can just move that loop into my callback function...
11:58:49
flip214
I get a pointer to foreign memory, and a byte count. is there a better way to push these bytes to a stream than looping myself here?
12:16:10
stassats
(with-open-file (stream "/tmp/test" :direction :output :element-type '(unsigned-byte 8) :if-exists :supersede)
12:16:10
stassats
(sb-impl::buffer-output stream (sb-sys:vector-sap (coerce "abcdefg" 'simple-base-string)) 0 7))
14:06:43
flip214
within swank I get a type error - #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD-OUTPUT* {1009730593}> is not of type SB-SYS:FD-STREAM
15:15:32
flip214
stassats: can SBCL encapsulate the runtime environment into a (void*) that can be passed to foreign functions, so that a lisp callback function can run closures that were defined outside the foreign call)
15:19:02
flip214
the callback is started and gets a (void*) to communicate some information (in C, typically a heap-allocated data structure)
15:21:17
Bike
you want to reference a closure in C as a function pointer plus a pointer to the closure environment?
15:22:49
flip214
and the lisp callback wants to use closures that got passed in to the outer lisp function (the one calling a foreign function)
15:27:07
flip214
the issue is that I actually get to pass in a vtable of functions, and one (void)* for the lexical scope
15:27:57
flip214
and I'd like to avoid reproducing the vtable as a structure in lisp, which I have to do if I need to store many individual closures in that structure
15:28:32
flip214
If I could pass the lexixal scope via the single void*, then the vtable can stay a foreign struct and can contain just the lisp functions' addresses
15:29:59
g_o
but doesn't that mean that you know where the vtable is from the get go? what if you have aslr?
15:31:52
flip214
g_o: the vtable gets allocated with another foreign function, and then individual members get set to the actual functions
16:11:01
stassats
now that the freebsd port has continuous integration, i wonder what it would take for other bsds
16:11:17
stassats
probably doing something manually on some cloud service, but that'll probably cost money
16:13:01
stassats
all the other arches being tested would be great too, i guess i could write some automated scripts for the gcc compiler farm
17:12:08
karlosz
i was worried that the locall optimization would be limited in use but examples like (labels ((f (x y) ...) (g (z w) ...) (cond ((...) (f 5 6)) ((...) (f 2 9)) ((...) (g 193 3)) ((...) (g 5 91)))) have convinced me that its worthwhile to do it for general functions, not just ones that tail call themselves
17:14:59
karlosz
right, i haven't looked into how to optimize functions which have to be local themselves, only on how to eliminate them
17:21:47
stassats
but there probably not a lot of leaf global functions which also don't use any stack space
17:27:14
karlosz
the only problem is that leaf functions are less common on x86 because of less registers
17:31:53
stassats
a function that only tail calls basically becomes the same as the callee (and you don't see it in the backtrace)
17:33:35
karlosz
i would pick off the local case first because that messes less with global call conventions
17:34:09
karlosz
and local leafs should be easy to recognize in IR1 - the tools are in locall.lisp alreadty
17:35:34
karlosz
it's low priority in the local case anyway - would shave off a few bytes here and there
17:47:49
karlosz
even that's not so obvious. the full call could be much more expensive than the local call
17:50:15
karlosz
the point is that i think ir2 vops are pretty much as high level as you can get for any good policy heuristic
17:51:01
karlosz
but what if some other big local function mentions those closure vars in the parent fnuction
17:52:30
karlosz
anyway, it sounds harder to do right than just rewiring local calls which are called multiple times but only return in one place, since that always reduces code size