00:00:29 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 00:16:38 -!- ASau [~user@83.69.227.32] has quit [Remote host closed the connection] 00:16:39 ASau` [~user@83.69.227.32] has joined #sbcl 00:27:16 (Or, far simpler even if it -is- a kludge, pass the argument to the VOP twice.) 00:29:59 So, this is probably an utterly silly question, but... On threaded systems, is there any reason we store the symbols on the binding stack instead of the TLS indexes? 00:34:36 nyef: to prevent GCing. 00:35:01 To prevent the symbols from being GCed? 00:35:20 now, whether that's useful is another question 00:35:31 I'd say not? 00:35:55 And without it, I might be able to get binding and unbinding on threaded systems to be cheaper than on unthreaded systems? 00:36:50 ISTM, getting the TLS index at load-time would work even better 00:37:09 Done, for x86-64. 00:37:24 Well, provided this build completes. 00:38:24 Fixing it up for the other threaded platforms should be straightforward, too. 00:38:54 Ah, damn. Build failure again. :-/ 00:40:22 This time for sure! 00:41:41 I already have it working for static-symbols, though, it's normal binding that's causing problems... And they should be more-or-less sorted now. 00:43:25 I love the function I have for finding a TLS slot for a symbol at load-time, though. It just uses PROGV to bind the symbol, then picks off the TLS slot. 00:46:36 and a load-time constant for the slot? 00:46:49 A fixup. 00:46:57 Gah. Build failed -again-. :-/ 00:47:01 I suppose you do even better when compiling to core? 00:47:16 mm, fixup is even cleaner. 00:48:29 Compiling to core is the same when it comes to obtaining the TLS slot. 00:48:56 Once this builds I'll finish off the commits and push to my public repo. 00:56:03 Anyway, bind is now probably on-par with unthreaded, and unbind might be a touch faster. 00:56:19 Modulo PROGV, which doesn't count because nobody actually uses it. 01:02:29 I use progv, once in a while 01:04:11 But not often enough for its speed to matter, right? 01:05:17 ASau`` [~user@83.69.227.32] has joined #sbcl 01:06:48 -!- ASau` [~user@83.69.227.32] has quit [Ping timeout: 245 seconds] 01:09:44 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has left #sbcl 01:12:01 Well, it survived to genesis, that's a good start. 01:12:15 ... And died in make-target-2. :-/ 01:13:07 -!- ASau`` [~user@83.69.227.32] has quit [Ping timeout: 240 seconds] 01:13:48 And, of course, the whole "lets -discard- the interrupt context when we get a memory fault" thing rears its ugly head again. 01:15:20 no, using progv in a tight loop sounds just wrong 01:15:59 Fare: I'd probably use COMPILE at runtime if I *had* to do that. 01:16:21 pkhuong, sounds about right - build a sexp, compile it. 01:17:03 -!- Fare [~Fare@ita4fw1.itasoftware.com] has quit [Quit: Leaving] 01:28:56 *nyef* takes one of the potential problem VOPs out of the loop and builds again. 01:55:29 hefner [~hefner@ppp-58-11-44-150.revip2.asianet.co.th] has joined #sbcl 01:58:42 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 02:02:15 Right, I give up for tonight. 02:02:36 Latest build failure was due to an unbalanced paren... and I use paredit. 02:09:32 5/win 5 02:24:04 froydnj [~froydnj@gateway.codesourcery.com] has joined #sbcl 02:33:33 Ooh. 2.6.35.5 is out, and has some intel and radeon driver fixes. 02:41:26 -!- morganb`` [~user@64-238-171-196.cab.apt.gru.net] has quit [Ping timeout: 264 seconds] 02:47:47 -!- nyef [~nyef@pool-70-109-134-127.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.] 02:51:30 rbarraud [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 02:51:38 -!- rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 264 seconds] 03:06:57 ASau [~user@83.69.227.32] has joined #sbcl 03:29:31 -!- hefner [~hefner@ppp-58-11-44-150.revip2.asianet.co.th] has quit [Ping timeout: 240 seconds] 03:29:57 -!- tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has quit [Remote host closed the connection] 03:36:44 hefner [~hefner@ppp-58-9-108-181.revip2.asianet.co.th] has joined #sbcl 04:12:11 -!- hefner [~hefner@ppp-58-9-108-181.revip2.asianet.co.th] has quit [Quit: Arrrr!] 05:29:38 -!- rbarraud [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 240 seconds] 05:33:35 slyrus_ [~chatzilla@adsl-75-36-215-204.dsl.pltn13.sbcglobal.net] has joined #sbcl 06:24:39 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 06:27:44 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 06:32:54 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 06:44:46 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 07:15:14 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 07:30:22 stassats [~stassats@wikipedia/stassats] has joined #sbcl 07:54:38 Bah SBCL does not allow (destruct foo (x (sb-int:missing-arg) :type nil)) :-) 08:28:27 attila_lendvai [~attila_le@89.135.206.66] has joined #sbcl 10:12:32 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 10:23:04 rbarraud [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 10:26:55 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 10:27:50 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 10:52:13 -!- attila_lendvai [~attila_le@89.135.206.66] has quit [Quit: Leaving.] 11:04:44 -!- rbarraud [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 255 seconds] 11:11:07 -!- Krystof [~csr21@92.24.94.2] has quit [Ping timeout: 240 seconds] 11:20:31 For some reason, we're seeing the following behaviour: 11:20:54 Using load start-swank.lisp, and eval (start-swank ) load other-file.lisp eval (main) 11:21:10 in that case, the swank thread is created but it hangs in accept-connection 11:21:34 and the reason is that sbcl is still in command line processing mode 11:22:07 because, if you interrupt, and at the debugger, invoke the "Skip command line processing" restart, accept-connection will magically start to work 11:22:24 So what's the magic bit that comes after command line processing? 11:24:10 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 11:24:54 Krystof [~csr21@92.24.90.5] has joined #sbcl 11:24:54 -!- ChanServ has set mode +o Krystof 11:43:55 -!- Krystof [~csr21@92.24.90.5] has quit [Ping timeout: 240 seconds] 11:57:41 Krystof [~csr21@92.24.92.20] has joined #sbcl 11:57:41 -!- ChanServ has set mode +o Krystof 12:45:36 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 12:48:42 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 12:53:26 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Remote host closed the connection] 13:06:33 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 13:22:39 nikodemus [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 13:22:39 -!- ChanServ has set mode +o nikodemus 13:24:55 afternoon 13:29:15 So, is x86-sse an appropriate name for a contrib shared by ecl & sbcl?.. What if in some undefined point in the future it gained support for AVX? 13:31:54 other options: sse, cl-sse, ia-sse, sse-ext, sse-intrinsics 13:32:29 it's ultimately a matter of taste, but i personally mislike the x86 prefix: it makes me expect that it will work on x86 but not on x86-64 13:32:54 but if you consider it the best name, i don't think that's going to be a showstopper :) 13:33:34 I have originally called it sse, but then thought that it might be better to elaborate 13:35:28 However, since sse is x86 by definition anyway, it might be redundant... 13:35:44 still more names: angasse, sgf (for SSE Goes Faster), blitz, cl-simd 13:36:54 cl-simd loses the reference to x86 completely 13:37:16 yeah, but then if more arches with different intrinsics are added you don't need a new contrib 13:37:22 that is not necessarily a bad thing 13:39:10 There is also the matter of package and feature naming, which is somewhat more important than the system name 13:40:56 Maybe the system can be called cl-simd, but define the #+x86-sse feature and x86-sse aka sse package 13:42:13 i think the sbcl feature should be called sb-sse or sse 13:42:59 hm, sse. yeah. the feature should be just place sse 13:43:09 plain sse, even 13:43:10 In ecl it is currently called sse2, because that's what is supported actually 13:43:16 good point 13:43:24 maybe sse2 is a better name 13:43:29 for the feature, that is 13:46:04 tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has joined #sbcl 13:48:59 Something called cl-simd should probably be safe to load at any time, but do nothing upon load if no support is available. 13:53:24 ...actually, x86-sse is a bit awkward to type too 13:59:19 angavrilov: alternatively, it could have dog-slow but portable versions of the intrinsics for non-sse2 hosts :) 14:02:19 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 14:08:52 -!- stassats [~stassats@wikipedia/stassats] has quit [Read error: Connection reset by peer] 14:09:09 stassats [~stassats@pppoe.178-66-49-186.dynamic.avangarddsl.ru] has joined #sbcl 14:09:12 -!- stassats [~stassats@pppoe.178-66-49-186.dynamic.avangarddsl.ru] has quit [Changing host] 14:09:12 stassats [~stassats@wikipedia/stassats] has joined #sbcl 14:15:31 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds] 14:27:02 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Read error: Connection reset by peer] 14:27:30 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 15:25:31 stassats [~stassats@wikipedia/stassats] has joined #sbcl 15:37:46 nyef [~nyef@pool-70-109-134-127.cncdnh.east.myfairpoint.net] has joined #sbcl 15:37:59 Hello all. 15:38:26 hi nyef 15:40:15 Anything interesting going on today? 15:52:57 Finally! Nailed the bug that was causing me so much trouble last night. 15:54:07 an insect? 15:54:37 Accidentally stripped the final STORE-TL-SYMBOL-VALUE from MAKE-CATCH-BLOCK. 15:55:08 mosquitoes give me most troubles at night 16:32:37 -!- Krystof [~csr21@92.24.92.20] has quit [Ping timeout: 265 seconds] 16:45:44 Krystof [~csr21@92.25.29.190] has joined #sbcl 16:45:44 -!- ChanServ has set mode +o Krystof 16:48:00 rmarynch [~roman@88.135.194.233] has joined #sbcl 16:58:36 cl-bench fails on SBCL 1.0.41/Linux32 with a message running # 16:58:37 Heap exhausted during allocation: 9670656 bytes available, 33030160 requested. Should I tweak something in cl-bench to make it pass? 17:02:56 I have tried three times, the result is the same error 17:14:42 well, I have added #-sbcl before STRING-CONCAT launch in do-execute-script.lisp, and it now passes to the end... 17:17:10 Umm... On x86-64, does a MOV to EDX clear the high-order 32 bits of the RDX? 17:17:47 nyef: not necessary. there are both variants 17:18:03 Hrm. Either the assembler is screwing up or the disassembler is. The trace-file says RDX but the disassembly says EBX. 17:18:10 Err... EDX. 17:19:14 Encoded instruction is BA17001020. 17:19:40 it is 32-bit 17:19:45 because there is no 48h 17:19:54 REX.W prefix 17:19:56 So it's not clearing the high-part of RDX? 17:19:59 no 17:20:07 I find myself... disconcerted. 17:20:43 I have recently written a assembler for x86-64 in CL, so I remember the stuff :) 17:20:50 Fair enough. 17:21:40 nyef: have you ever tried FASM? I find it very useful in such cases 17:22:08 it allows to assembly a single x86-64 instruction 17:22:26 I'm still disconcerted... And also suspecting that... Hrm. Okay, it's not populating the high bits within the body of the sequence, which would be the failure mode... 17:22:56 ... and generates _exactly_ it, without any other code. 17:22:57 Honestly, I'm going to chalk this up as something to investigate once this bughunt is over. 17:26:31 I guess this line from manual is about this case: B8+ rd MOV r32, imm32 E Valid Valid Move imm32 to r32 17:27:09 B8 and register digit should give BA, do they? 17:27:59 Umm... AX CX DX BX... Yeah, register index is 2. 17:28:14 (Don't know the indexes offhand, but do know the order.) 17:28:35 so, the disassembler lies 17:29:04 and what is before BA in the code stream? 17:31:15 In one case, I don't know. In the other, 49894C2438, which is listed as MOV [R12+56], RCX. 17:32:42 I think the disassembler may well be telling the truth here. 17:32:48 Well, it is not 49h (prefix for r8 and higher) or 48h at the end of that. It is strange that a program decodes 64-bit register. 17:33:02 sure, I just mixed it 17:33:17 Yeah, it's that it doesn't -encode- a 64-bit register. 17:34:14 where did you face this issue? 17:35:17 Simple test case: (defun foo () (let ((- nil)))), compile with :trace-file t. 17:35:22 Load and disassemble. 17:35:35 Compare the trace-file for VOP BIND to the disassembly. 17:35:43 One says RDX, the other says EDX. 17:37:54 I am on x86 (laptop) now, so I can't see that right now. The example is interesting :) 17:41:58 Right, I can't find a bug in the VOP I've been hacking. Time to take a break. 17:42:07 um, I think 32-bit insns implicitly clear high bits. we rely on that in several places 17:43:28 froydnj: in GCC? 17:44:02 rmarynch: well, gcc relies on it too, yes 17:44:43 you're supposed to use 32 bit insns as much as possible 17:45:09 does it gives the performance benefits? 17:45:16 yes. 17:58:59 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Remote host closed the connection] 18:19:59 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 18:20:41 rmarynch [~roman@88.135.194.233] has joined #sbcl 18:23:53 it clears for sure, I have just seen it with gdb and this simple code: int main() 18:23:53 { 18:23:53 asm ( "movq $867834657463709999, %rax"); 18:23:53 asm ( "movl $8, %eax"); 18:23:53 return 0; 18:23:54 } 18:24:12 rax = 8 at the end 18:31:30 yup. 19:01:16 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 19:41:38 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds] 20:08:20 -!- Krystof [~csr21@92.25.29.190] has quit [Ping timeout: 255 seconds] 20:23:03 Krystof [~csr21@92.24.99.161] has joined #sbcl 20:23:04 -!- ChanServ has set mode +o Krystof 20:25:44 ... Either (inst mov temp ) (storew temp ) isn't equivalent to (inst push ) (popw ), or something weird is going on. 20:37:56 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 20:51:56 Fare [~Fare@ita4fw1.itasoftware.com] has joined #sbcl 21:16:18 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 240 seconds] 21:24:17 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 21:51:04 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Quit: kclifton] 22:42:28 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 23:20:58 attila_lendvai [~attila_le@89.135.204.63] has joined #sbcl 23:32:12 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 23:32:58 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 23:37:24 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl