00:50:36 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 00:50:36 00:50:36 -!- names: ccl-logbot Bike drmeister Guest84109 jsnell stassats` Quadrescence ehaliewicz yacks scymtym scymtym_ nicdev segv- ASau kludge` xymox Subfusc pkhuong redline6561 Blkt antifuchs kanru fe[nl]ix pchrist abarch` specbot pegu brucem |3b| jdz danlentz fikusz @Krystof daimrod flip214 luis` antoszka ivan`` ferada DeadTrickster foom gko cmack milosn loke minion Posterdati asedeno_ bege christoph_debian 00:50:42 When I expand macros I copy the source information for the source to the transformed result. 00:50:44 not through intern, anyway. Most backquote stuff will splice input forms in verbatim, and an EQ hash table will pick these up. 00:51:20 If they don't, it's hard to avoid false positive and even harder to find useful matches. 00:51:22 Where I run into problems is backquote processing - it generates a lot of new code from source code. 00:53:19 I'm sorry - I don't follow what you are saying. 00:55:44 backquote just splices a lot of conses in as is, without copying anything. 00:56:12 an EQ table will catch such sones (or sexp) just fine. 00:56:15 *conses 00:57:18 ,@ in the middle does copy 00:58:53 stassats`: "a lot" and even ,@ is just a shallow copy. 00:59:09 Ok, I think I see. 01:00:31 To take a step back - does the SBCL reader map just conses to source code metadata or all generated objects? 01:03:05 Or did I misinterpret what SBCL does? 01:13:56 Are there any SBCL developers who would work (for money) to implement features? 01:20:07 fisxoj [~fisxoj@192-0-131-151.cpe.teksavvy.com] has joined #sbcl 01:21:08 working for money ain't fun 01:21:56 or at least, having to produce something, applied/basic research could work 01:23:20 -!- Bike [~Glossina@69.166.47.101] has quit [Ping timeout: 245 seconds] 01:25:40 Quadrescence: but anyway, what kind of features? 01:26:21 an O(1) case (for certain SPEED/SPACE combinations), which I think pkhuong started working on 01:26:34 in other words, a jump table 01:27:15 do you need it for something? 01:28:02 it would be highly preferable for some work yes 01:29:27 Quadrescence: I'd do it for free if it weren't for the defense. 01:29:55 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 01:30:29 write it into your thesis! 01:30:46 :))) 01:31:13 APPENDIX D. ON EFFICIENT STATE MACHINE IMPLEMENTATION IN COMMON LISP 01:32:21 stassats`: native code compilation and my thesis topic are about as different as possible while falling under "computer science." 01:32:29 i need to look again at the stack analysis bugs, what's the point of adding new features if there are glaring bugs 01:33:34 blog postable features are attractive 01:34:14 stassats`: pretty much, yes. My priority is fixing copy-more-arg, on x86oids at least. 01:34:16 and sb-safepoint are still not interrupt safe 01:35:42 Quadrescence: i don't even have a blog! 01:36:02 stassats`, you can blog on my blog as a guest blogger 01:38:44 what if TLS index allocation were implemented with a trap? the initial value would point to a piece of read-protected memory, and the fault handler will allocate it? 01:38:58 stassats`: I'd rather have TLS indices be allocated at load-time. 01:39:30 the number is limited, though 01:40:05 I was talking with some of the CMUCL guys over dinner and they had a bit to say about SBCL's trap and signal "envy". 01:40:39 stassats`: a trap isn't going to change that. 01:41:01 pkhuong: it'll be allocated only when accessed 01:41:34 stassats`: and how often do you load code that binds a special and then never call that code? 01:42:06 i don't use every part of the code i load 01:43:03 maybe if tls indexes could be expanded dynamically 01:43:09 stassats`: or just GCed. 01:43:57 that doesn't sound easy 01:44:51 stassats`: and yet it is. The only hard part is hooking into TLS index allocation... but that becomes easier if allocating TLS indices is off the hot path (I don't really care about progv ;). 01:46:11 -!- segv- [~mb@95-91-241-46-dynip.superkabel.de] has quit [Ping timeout: 260 seconds] 01:46:13 Recover unused indices after major GCs. The easiest way would be to have a bitmap, but the last time I did it, I just added a free list in front of the current counter. 01:46:24 special variables don't usually get unreachable, so how do you decide which to expunge? some kind of LRU? 01:46:39 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 260 seconds] 01:46:56 the main complaints I've seen about exhausting the TLS indices were from code that bound gensyms. 01:48:15 Quadrescence: I'd love to see their thread support ;) 01:48:44 pkhuong, ha ;) 01:53:45 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 01:55:35 is it necessary to fill the binding pointer entries with zeros? 01:56:30 andreh [~andreh@177.133.55.216] has joined #sbcl 01:57:54 the comment in unbind just says ";; Zero out the stack." 01:57:56 not why 02:07:51 Do we consider the BSP when scanning, during GC? 02:08:59 we do. 02:09:08 we have to, otherwise we'll lose values 02:09:26 but it shouldn't happen above the pointer 02:09:53 no, we could also just scan all of the binding stack, regardless of the pointer. 02:10:42 pranavrc [~pranavrc@122.164.227.199] has joined #sbcl 02:10:42 -!- pranavrc [~pranavrc@122.164.227.199] has quit [Changing host] 02:10:42 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 02:16:07 not zeroing saves whole 16 bytes 02:16:43 ok, binding-stack-pointer is a special variable itself on unthreaded builds. Better zero it out if user code can change the BSP. 02:17:06 what kind of user code does that? 02:17:26 and doesn't get all kinds of bad things happening? 02:17:41 worse than heap corruption? 02:18:57 worse 02:19:31 (let ((sb-vm::*binding-stack-pointer* 0)) (let ((* 10)))) => complete crash without even ldb 02:20:20 yes, that would do it. 02:21:21 but not bumping the bsp. 02:21:57 why would anybody do that? 02:23:29 why would anybody write code with nested return-from and clean ups? 02:23:57 because it's legal 02:24:28 yeah, ok. very good reason to zero it out: GC race. 02:24:53 bind increments the BSP, and then writes to the slots. 02:25:27 well, can't it increment it after that? 02:25:36 no. interrupt. 02:26:03 handle an interrupt, the handler binds a special, then resume from the handled, and the state is all wrong. 02:26:18 *resume from the handler 02:26:48 and with safepoints? 02:27:11 the best I can see is to have the GC zero things out. 02:28:01 With safepoints, thruptions and all, sure, it *should* be safe. 02:28:40 echo-area [~user@182.92.247.2] has joined #sbcl 02:35:59 alright, i can at least use a register instead of an immediate 0 02:37:25 that saves 6 bytes, not sure about performance 02:38:27 you could move RBP ;) 02:39:02 -!- christoph_debian [~christoph@ppp-88-217-85-203.dynamic.mnet-online.de] has quit [Ping timeout: 240 seconds] 02:39:03 what do you mean? 02:39:29 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Quit: Reconnecting] 02:39:37 If you're zeroing out a register to then overwrite with that, you can also store [RE]BP directly: it's a fixnum. 02:39:43 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 02:39:48 or aligned as such, anyway. 02:41:41 that's another 2 bytes, though now it depends on the value of RBP 02:42:02 so does our PA sequence though. 02:42:56 same for unboxed singles or doubles on stack, on x86-64. 02:43:16 i rather meant about out-of-order execution 02:43:59 i will a hard time measuring that, though 02:44:08 RBP is rarely written to. 02:44:57 during full calls? 02:45:47 or local calls. 02:46:18 there's plenty of latency after calls, at least for XEP prologue. 02:46:33 no, POP RBP 02:46:54 -!- scymtym [~user@8.75-67-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 264 seconds] 02:46:56 storing the BSP would also work. 02:48:06 threaded bind has a weird push old value/pop into BSP sequence, if you're worrying at that level. 02:48:44 yeah, i've noticed it 02:50:58 latency-wise, you're much more likely to be bottlenecked by computing the BSP or the TLS index than by RBP. 02:53:48 christoph_debian [~christoph@ppp-188-174-127-33.dynamic.mnet-online.de] has joined #sbcl 02:56:13 -!- andreh [~andreh@177.133.55.216] has quit [Quit: Quitte] 02:57:01 the symbol is stored in the binding space, but a tls index could be stored instead 02:58:40 would save going through tls-index-slot on unbind 02:59:05 now, is it fixnum or not? 02:59:12 is what fixnum? 02:59:17 tls index 02:59:33 tls index is word aligned. 03:00:35 ok, then it can be stored directly, unless some debugging thingy wants a symbol 03:01:30 right. Which I think does happen. I saw some code scanning the binding stack for unbound markers. 03:02:15 unbound markers are used for unwinding 03:03:15 it stores unbound-marker:RBP, and then unwinds the binding stack up to that point 03:08:43 looks like nothing else looks at the binding space 03:11:13 cmack` [~charlie@adsl-74-179-31-54.bna.bellsouth.net] has joined #sbcl 03:11:41 -!- minion [~minion@common-lisp.net] has quit [Disconnected by services] 03:11:45 minion [~minion@common-lisp.net] has joined #sbcl 03:12:59 and with storing the tls-index instead of a symbol, only the value part has to be zeroed 03:13:54 -!- cmack [~charlie@adsl-74-179-31-54.bna.bellsouth.net] has quit [*.net *.split] 03:25:01 stassats`: and what happens on unwinds? 03:25:09 business as usual? 03:26:06 unbind-to-here just needs to be adjusted too 03:26:40 and how does it detect entries that must be skipped? 03:27:20 unbind to here tests for zeroness. It could test for fixnumness, but not if TLS indices are stored instead of the symbol. 03:29:50 why does it have to skip anything? 03:30:09 because binding could be interrupted half way through. 03:30:27 or unbind, even. 03:30:35 the order in which the slots are written and cleared is important. 03:31:23 all i'm changing is writing a tls-index instead of a symbol 03:32:03 I thought you stopped zeroing out the binding stack as well? 03:33:30 not anymore 03:34:01 hopefully you'll document the assumption that tls indices are non-zero then. 03:35:33 tls-index of zero means it's not allocated 03:35:42 so, it's already assumed so 03:35:55 indeed. and hopefully you're document the fact that the binding stack machinery assumes that as well. 03:36:25 i would, though i'm not sure where to put it 03:36:43 in bind or somewhere else 03:37:07 it's these local hacks that glue more and more design decisions or accidents together that crystallise systems like SBCL and make it difficult to make later changes. 03:39:18 inside define-primitive-object looks like a better idea 03:44:56 why should unbind-to-here care about zero? all it does it zeros values, nothing bad about zeroing it again 03:47:13 it doesn't just clear values, it also restores bindings to their previous value. 03:47:36 after a partial bind or unbind, the value and/or the symbol/TLS index is bogus. 03:48:10 just noticed that 03:48:36 the order which binding stacck entries guarantees that, whenever the symbol [TLS index] isn't obviously wrong (non-zero), the symbol [TLS index] and the value are correct. 03:49:05 *the order in which binding stack entries are written guarantees that. 03:49:31 this should be better documented indeed 03:49:59 otherwise i fell reading poetry "what did the author mean?" 03:50:09 feel 03:50:14 like, sigh 03:51:05 so far, it's all local to a couple VOPs, so it's always been somewhat easy to piece together. 03:54:07 GC could treat binding stack specially and just disregard values with 0 key 04:19:21 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 04:51:48 -!- ASau [~user@p4FF97EC9.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds] 05:14:47 -!- fisxoj [~fisxoj@192-0-131-151.cpe.teksavvy.com] has quit [Ping timeout: 260 seconds] 05:21:42 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Read error: No route to host] 05:23:20 attila_lendvai [~attila_le@95.56.65.131] has joined #sbcl 05:23:20 -!- attila_lendvai [~attila_le@95.56.65.131] has quit [Changing host] 05:23:20 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:59:00 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Remote host closed the connection] 06:03:14 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 264 seconds] 06:06:30 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds] 06:09:19 pranavrc [~pranavrc@122.164.174.35] has joined #sbcl 06:09:19 -!- pranavrc [~pranavrc@122.164.174.35] has quit [Changing host] 06:09:19 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 06:13:54 edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has joined #sbcl 06:44:43 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 06:57:36 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 07:13:58 ASau [~user@p4FF967C4.dip0.t-ipconnect.de] has joined #sbcl 07:26:26 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Ping timeout: 256 seconds] 07:40:42 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 08:00:01 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 08:24:08 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 08:28:03 kwmiebach [~kwmiebach@xdsl-87-78-4-173.netcologne.de] has joined #sbcl 08:37:13 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 245 seconds] 09:03:45 attila_lendvai [~attila_le@87.247.61.184] has joined #sbcl 09:03:45 -!- attila_lendvai [~attila_le@87.247.61.184] has quit [Changing host] 09:03:45 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:30:16 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 246 seconds] 09:36:17 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 09:42:28 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 248 seconds] 10:51:34 -!- kwmiebach [~kwmiebach@xdsl-87-78-4-173.netcologne.de] has quit [Read error: Connection reset by peer] 10:52:13 kwmiebach [~kwmiebach@xdsl-78-35-238-184.netcologne.de] has joined #sbcl 11:06:18 yacks [~py@103.6.159.103] has joined #sbcl 11:19:43 -!- daimrod [daimrod@sbrk.org] has quit [Ping timeout: 260 seconds] 11:23:38 benkard [~benkard@2001:4ca0:0:f230:2ce4:749e:5f8b:c470] has joined #sbcl 11:41:59 -!- benkard [~benkard@2001:4ca0:0:f230:2ce4:749e:5f8b:c470] has quit [Quit: Textual IRC Client: www.textualapp.com] 11:42:06 -!- echo-area [~user@182.92.247.2] has quit [Read error: Connection reset by peer] 11:55:29 -!- cmack` is now known as cmack 11:57:11 pranavrc [~pranavrc@122.164.16.160] has joined #sbcl 11:57:11 -!- pranavrc [~pranavrc@122.164.16.160] has quit [Changing host] 11:57:11 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 11:57:57 benkard [~benkard@2001:4ca0:0:f230:1577:b6eb:97d1:6839] has joined #sbcl 12:08:42 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 12:09:01 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 12:33:37 teggi [~teggi@113.173.4.29] has joined #sbcl 12:39:12 -!- cmack [~charlie@adsl-74-179-31-54.bna.bellsouth.net] has left #sbcl 12:39:25 -!- drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 12:43:06 drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 12:44:18 -!- drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 13:01:11 segv- [~mb@95-91-241-70-dynip.superkabel.de] has joined #sbcl 13:07:09 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 256 seconds] 13:12:13 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 13:12:32 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 13:26:20 drmeister [~drmeister@166.137.86.38] has joined #sbcl 13:35:36 -!- benkard [~benkard@2001:4ca0:0:f230:1577:b6eb:97d1:6839] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 13:40:29 attila_lendvai [~attila_le@95.56.68.63] has joined #sbcl 13:40:30 -!- attila_lendvai [~attila_le@95.56.68.63] has quit [Changing host] 13:40:31 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:41:52 benkard [~benkard@2001:4ca0:0:f230:bd76:828f:109:3bdf] has joined #sbcl 13:56:33 -!- drmeister [~drmeister@166.137.86.38] has quit [Remote host closed the connection] 14:14:51 tylergoza [~tylergoza@user-24-96-98-239.knology.net] has joined #sbcl 14:15:47 -!- danlentz [~danlentz@c-68-37-70-235.hsd1.nj.comcast.net] has quit [Ping timeout: 260 seconds] 14:18:28 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 245 seconds] 14:19:37 danlentz [~danlentz@c-68-37-70-235.hsd1.nj.comcast.net] has joined #sbcl 14:20:13 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 14:33:59 easye [~user@213.33.70.157] has joined #sbcl 14:51:00 -!- Guest84109 [user@nat/google/x-xpokrszdylqtzwhk] has quit [Remote host closed the connection] 14:59:10 brown [user@nat/google/x-rozcvttdocfbshsk] has joined #sbcl 14:59:34 -!- brown is now known as Guest68639 15:04:30 yacks [~py@103.6.159.103] has joined #sbcl 15:07:03 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 15:08:54 Guest686` [user@nat/google/x-dujknifnavthsdtx] has joined #sbcl 15:09:12 -!- Guest68639 [user@nat/google/x-rozcvttdocfbshsk] has quit [Read error: Connection reset by peer] 15:15:49 re CCL's typecase, what does it do on something as simple as (typecase x (short-float ...) (single-float ...) (double-float ...) (long-float ...)) or, if it does have all 4 float types, array types that upgrade to the same thing? 15:20:43 dunno (probably barfs) but maybe a nicer way of writing the sb-simd-pack typecase anyway is ... #-sb-xc-host (t #!+sb-simd-pack (typecase ... )) 15:21:01 ccl's not in debian, therefore it doesn't exist 15:29:47 Krystof: or adding a #! feature when we're building the target image? 15:33:06 maybe, though I have a feeling that that will totally confuse me 15:33:36 I can read #-sb-xc-host (... block of code ...) as "block of code only on the target compiler" 15:33:57 the thing that went wrong was #-sb-xc-host #!+ ... but I couldn't understand that anyway 15:56:20 -!- benkard [~benkard@2001:4ca0:0:f230:bd76:828f:109:3bdf] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 15:57:33 -!- tylergoza [~tylergoza@user-24-96-98-239.knology.net] has quit [Quit: Leaving] 16:00:58 -!- Guest686` [user@nat/google/x-dujknifnavthsdtx] has quit [Read error: Connection reset by peer] 16:01:24 -!- teggi [~teggi@113.173.4.29] has quit [Remote host closed the connection] 16:50:00 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Ping timeout: 276 seconds] 17:13:03 Fare [fare@nat/google/x-rnbgdyuqnspifusn] has joined #sbcl 17:13:09 tylergoza [~tylergoza@user-24-96-98-239.knology.net] has joined #sbcl 17:27:13 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 18:09:10 Bike_ [~Glossina@69.166.47.109] has joined #sbcl 18:09:18 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 245 seconds] 18:09:49 -!- Bike_ is now known as Bike 18:36:46 *stassats`* ends up writing a large comment describing how binding special variables works on sb-thread-x86 18:41:03 prxq [~mommer@mnhm-590c1eb2.pool.mediaWays.net] has joined #sbcl 18:59:17 -!- Bike [~Glossina@69.166.47.109] has quit [Ping timeout: 248 seconds] 19:00:12 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 19:12:13 stassats`: could it go in the internals manual? 19:15:53 maybe 19:23:49 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 248 seconds] 19:24:38 brown [user@nat/google/x-xuvieytsuccqgocl] has joined #sbcl 19:25:02 -!- brown is now known as Guest48795 19:28:09 -!- Guest48795 is now known as reb 19:35:42 Bike [~Glossina@69.166.47.101] has joined #sbcl 19:46:31 -!- edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has quit [Quit: conversation lost because computer sucks] 19:55:02 now to untangle the build 19:59:27 l_ [~l@84.233.246.170] has joined #sbcl 19:59:40 -!- l_ [~l@84.233.246.170] has left #sbcl 20:06:01 huh, there's unbind-to-here in C too 20:07:00 and bind/unbind, and my store-tls-index-not-symbol obviously breaks 20:07:08 and means i have to do that for all other backends 20:09:13 trying to modify without test assembly for an architecture i don't know anything about doesn't sound promising 20:12:22 "think harder" 20:25:28 l_ [~ccnot@84.233.246.170] has joined #sbcl 20:26:15 -!- l_ [~ccnot@84.233.246.170] has left #sbcl 20:31:53 there's actually a section about binding special variables in the internals manual 20:31:57 i would just need to update it 20:32:33 there should be references in the comments "see internals manual section x.y" 20:37:06 -!- Bike [~Glossina@69.166.47.101] has quit [Ping timeout: 245 seconds] 20:39:26 -!- Fare [fare@nat/google/x-rnbgdyuqnspifusn] has quit [Ping timeout: 240 seconds] 20:50:09 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Remote host closed the connection] 20:53:55 Bike [~Glossina@wl-nat97.it.wsu.edu] has joined #sbcl 20:54:23 looks like my new binding scheme saves 160KB of the core 20:54:43 new binding scheme/better vops 20:58:07 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 21:04:32 i just have to port it to x86, ppc, mips, alpha 21:07:57 daimrod [daimrod@sbrk.org] has joined #sbcl 21:20:03 Fare [~fare@cpe-69-203-115-132.nyc.res.rr.com] has joined #sbcl 21:22:38 x86 uses FS for thread local storage, would it make sense to use GS in x86-64? 21:24:26 no. slower than a register and OS support is weak, iirc. 21:24:45 more code as well, probably. 21:28:05 -!- Fare [~fare@cpe-69-203-115-132.nyc.res.rr.com] has quit [Ping timeout: 268 seconds] 21:41:19 Fare [fare@nat/google/x-scoctsfmpdisotpn] has joined #sbcl 22:11:57 -!- kwmiebach [~kwmiebach@xdsl-78-35-238-184.netcologne.de] has quit [Quit: Leaving] 22:15:33 -!- Bike [~Glossina@wl-nat97.it.wsu.edu] has quit [Ping timeout: 248 seconds] 22:17:42 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 22:21:56 allocating tls at c-t could bring even more space/speed saving 22:25:01 load-time. 22:25:03 but yes. 22:25:12 huh, losing si-vector element size: 63 22:25:25 that can't be special variables 22:26:17 pkhuong: right, c-t would be nicer, but would break with separate loading 22:26:38 at least for sbcl variables tls-index could be known at ct 22:27:46 looks like more of a "rewrite DUMP-I-VECTOR" problem 22:28:15 prxq_ [~mommer@x2f66e88.dyn.telefonica.de] has joined #sbcl 22:28:36 -!- prxq [~mommer@mnhm-590c1eb2.pool.mediaWays.net] has quit [Ping timeout: 260 seconds] 22:28:38 right 22:28:47 *stassats`* looks at Krystof 22:31:44 (defvar *v* #.(coerce #(31) '(simple-array fixnum (*))) 22:35:59 how on earth did it work before? 22:42:33 it was broken in two places 22:42:43 now it's broken in just one, making it apparent 22:44:20 it was assumed that fixnums are 61-bit, now this is not true on x86-64, the new code queries saetp, the old just did a typecase 22:44:25 and upgrading made it alright 22:50:22 fop should probably just query saetp too 22:54:01 fisxoj [~fisxoj@192-0-131-151.cpe.teksavvy.com] has joined #sbcl 23:13:44 -!- tylergoza [~tylergoza@user-24-96-98-239.knology.net] has quit [Quit: Leaving] 23:17:39 Bike_ [~Glossina@69.166.47.105] has joined #sbcl 23:19:04 -!- Bike_ is now known as Bike 23:21:10 -!- ASau [~user@p4FF967C4.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 23:25:06 ASau [~user@p4FF967C4.dip0.t-ipconnect.de] has joined #sbcl 23:37:42 -!- DeadTrickster [~dead@62.122.188.214] has quit [Ping timeout: 256 seconds] 23:40:19 looks like it's better to dump the vector widetag instead of size 23:42:26 have a table of widetag->words-per-length, and then just do (allocate-vector widetag length (* length words-per-length))