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
17:53:17
karlosz
maybe it would be useful to have those heuristics anyway, since they could apply to global functions
18:01:06
stassats
(flet ((f (x) x)) (f 1) (f 2)) is derived as (integer 1 2), while we know it to be (integer 2 2)
18:03:32
stassats
suppose we have a lot of time to waste, and inline each local function, use that inline expansion only to derive the type