00:00:05 What I haven't been able to figure out is how we have a MIPS binary at all. 00:00:53 The SB-POSIX bug is, at least, fairly obvious once you look at it. (-: 00:01:00 the missing rdev? 00:01:11 Spot on. 00:01:14 cool. Sounds plausible; the last thing I had seen was a bogus LRA, so that must be it. 00:01:49 Let me guess... you're in target-2, and there was an INTERNAL-ERROR, and it died trying to do a backtrace? 00:02:14 nyef: ARM has predication on indirect branches? 00:02:39 pkhuong: ARM has predication on ADD and SUB instructions, and the program counter is a GPR. 00:02:49 well, not quite, because I had backported a type fix that meant pcl compilation didn't have a type check trap, and ran through. But yeah, I was looking at that problem. 00:03:32 pkhuong: And that's before you involve the barrel shifter. Fun and games. (-: 00:03:33 For a moment I was looking in the wrong direction, because rather than a bogus LRA I had a follow-up type error, because INT-SAP was pretty unhappy about its argument being not just an invalid 32 bit pointer, but rather a negative 64 bit number. 00:04:00 -!- edgar-rft [~GOD@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: nuclear meltdown] 00:04:12 lichtblau: I'm planning to commit the LRA fix at some point after we're out of code freeze, and after I've made sure that it still builds. 00:04:12 ... and there are a few places where we incorrectly cast register values to unsigned long instead of leaving them as long long. 00:04:23 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 00:04:58 nyef: I was about to say :) 00:05:41 Just thinking about handling its rotated immediates in SBCL triggers headaches. 00:06:04 -!- nyef [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has left #sbcl 00:06:09 nyef [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has joined #sbcl 00:06:11 Oops. 00:06:32 -!- nyef [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has left #sbcl 00:06:34 nyef [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has joined #sbcl 00:06:39 Ah, there we go. 00:07:02 pkhuong: "(unsigned-byte 8)" is a lot easier to think about then the real limits. 00:07:22 sure, but that's not very heroic ;) 00:07:50 You want heroic? How's about working NLX, and trying to get VOP RETURN-MULTIPLE to function? 00:09:31 Sorry, I still don't understand calls. 00:09:59 I think my next test case after this is MULTIPLE-CALL-NAMED, then UWP, then maybe either tackling the ALIEN-FUNCALL mess or doing something that could involve the number stack. 00:10:38 How about floating point? Do you understand floating point? 00:11:45 mostly. 00:13:18 Oh, good. Because that's one of the parts of the ARM port that I'm really hoping not to have to do. 00:14:20 I should have a glut of free time after this week or the next. If QEMU/x86-64 is usable, I'll have a go. 00:15:08 I'm not sure how close I'll be to needing floating-point by then, but I'm hoping for fairly close. 00:15:34 I already have a good chunk of call/return, NLX, and hairy argument parsing working. 00:18:52 Okay, return-multiple worked once. It must be good. Or, at least, unlikely to fail noticeably until actually put under serious load. 00:24:02 well, that's a lot of fragmentation. VFP does non-vector FP. Cortex-A8 only have a slow ersatz of the VFP unit. All A8 have NEON, though, which does scalar and vector processing. But A9 don't all have NEON. 00:25:07 Lovely. I've yet to even look at things seriously, and while I have three ARM devices, I accidentally bricked one, and am unwilling to risk a second, leaving only one device that I use to test with. 00:25:27 I guess there's always backend-subfeatures or something like that, and possibly even a soft-float implementation? 00:26:17 I think if we assume VFP, we can depend on the OS's soft-fp for really low-level devices, with, basically a "don't do that" note in the manual. 00:26:56 Fine by me. And I don't have a problem assuming vfp, vfpv3 (whatever that is), or neon. 00:27:26 But, that's because my only working target machine mentions those in /proc/cpuinfo. 00:28:29 I'm also having to assume EABI, without OABI compatibility, which is a pain in the R7, but I've still found some cute ways to take advantage of it. 00:30:13 The more I read, the angrier I get ;) We can't support for IEEE in NEON: it's always in flush-to-zero mode. 00:32:39 I'd say something sarcastic, but I'm sufficiently uneducated as far as floating point goes as to be unable to appreciate quite what that means, other than "the hardware is doing something brain damaged". 00:35:03 it's not necessarily brain damaged, just extremely speed-oriented: it pretends denorms are zeros (and VFPv2 doesn't even get the sign right when it does). 00:35:50 I'll take time to talk to a few people and draw a table up, see if there's an obviously less bad choice, especially given that we don't expect to run on tiny devices anyway. 00:36:05 If we can't conform to IEEE, can we at least conform to CL? 00:36:29 And would that affect the suitability of ARM for cross-compiling SBCL to another platform? 00:37:53 We'd have to lose the :ieee-floating-point feature ;) 00:38:33 I think we already avoid denorms in host code, because some (*cough* CLISP *cough*) don't support them. 00:38:38 Not that anyone dispatches on it. (-: 00:42:03 -!- joshe [~joshe@opal.elsasser.org] has quit [Ping timeout: 260 seconds] 00:42:57 Ohh, NEON doesn't do double floats. That settles it. 00:45:22 Should we just write a soft-float implementation and use that? 00:45:49 It'd give us the chance to remove the SOFT-FLOAT-INFINITY-KLUDGE, at least. 00:47:27 I'm not stoked about having to share unboxed (I assume you went for a split design) registers when just about any chip that has a chance of running SBCL probably has an FP unit (it might be half-fledged, but still) 00:48:04 Yeah, cheneygc for now, even. 00:49:01 Although gencgc should be fairly easy. 00:50:24 And there's only three unboxed registers, and four boxed registers, and the rest are for things like the program counter, stack and frame pointers, NIL, the link register, and the interior pointer (though I'm thinking I can "get away" without an interior pointer, especially given that the link register partakes of the interior-pointer nature). 00:53:12 funny. ARM suggests we use the link register as temp-reg (: 00:54:32 We need for the link register to partake of the interior-pointer nature for GC reasons, but if almost nothing uses LIP for its intended purpose then there's little stopping us from combing LIP and LR. 00:55:46 And the only reason that we can get away with squashing the two is the interrupt context scavenging fixes I put in a while back which promoted several registers to full interior-pointer nature from the half-assed always-relative-to-reg_CODE thing they were doing before. 01:04:55 ... %MORE-ARG-VALUES can leak stack values? 01:14:52 LiamH [~none@pool-173-73-131-126.washdc.east.verizon.net] has joined #sbcl 01:18:37 joshe [~joshe@opal.elsasser.org] has joined #sbcl 01:28:14 -!- ASau [~user@128-69-65-11.broadband.corbina.ru] has quit [Ping timeout: 240 seconds] 01:31:21 Heh. RECEIVE-UNKNOWN-VALUES is entirely predicatable. (-: 01:49:21 ASau [~user@128-69-65-11.broadband.corbina.ru] has joined #sbcl 03:22:25 -!- LiamH [~none@pool-173-73-131-126.washdc.east.verizon.net] has quit [Quit: Leaving.] 03:53:54 -!- wbooze [~wbooze@xdsl-87-79-250-54.netcologne.de] has quit [Ping timeout: 265 seconds] 04:03:53 nyef: might ARM be the first SBCL target that's space rather than speed-optimised? (: 04:05:18 Maybe. Right now, I'm concentrating more on getting it working than on anything else. 04:11:21 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Remote host closed the connection] 04:11:32 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 04:32:30 Okay, I need to at least pretend to get some sleep. 04:32:34 -!- nyef [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.] 06:03:06 tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 06:33:00 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 06:37:53 -!- pkhuong [~pkhuong@gravelga.xen.prgmr.com] has quit [Ping timeout: 244 seconds] 06:38:01 pkhuong [~pkhuong@gravelga.xen.prgmr.com] has joined #sbcl 06:57:38 attila_lendvai [~attila_le@87.247.56.85] has joined #sbcl 06:57:38 -!- attila_lendvai [~attila_le@87.247.56.85] has quit [Changing host] 06:57:38 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:59:18 sdemarre [~serge@91.176.24.155] has joined #sbcl 07:57:03 prxq [~mommer@mnhm-590c29ff.pool.mediaWays.net] has joined #sbcl 08:21:41 -!- tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Quit: Leaving.] 08:29:27 -!- Krystof [~user@81.174.155.115] has quit [Read error: Operation timed out] 08:56:51 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 08:58:46 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 08:59:09 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 09:23:20 Krystof [~user@81.174.155.115] has joined #sbcl 09:23:20 -!- ChanServ has set mode +o Krystof 09:32:59 -!- sdemarre [~serge@91.176.24.155] has quit [Ping timeout: 260 seconds] 09:36:07 sdemarre [~serge@91.176.24.155] has joined #sbcl 09:45:28 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 09:57:29 -!- sdemarre [~serge@91.176.24.155] has quit [Ping timeout: 260 seconds] 10:46:04 attila_lendvai [~attila_le@87.247.56.85] has joined #sbcl 10:46:04 -!- attila_lendvai [~attila_le@87.247.56.85] has quit [Changing host] 10:46:04 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:17:45 -!- kanru` [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Ping timeout: 256 seconds] 11:40:22 sdemarre [~serge@91.176.24.155] has joined #sbcl 12:09:46 ok, I am half-way through the process, but it's open season on sbcl.git 12:09:55 working on updating the web page etc 12:14:52 gah, how is sbcl-page meant to work? 12:16:01 clearly I need to release more than once a month 12:20:34 is something specific going wrong with sbcl-page? 12:20:57 LiamH [~none@pool-173-73-131-126.washdc.east.verizon.net] has joined #sbcl 12:22:12 that part of the release process was always causing the most trouble for me, but I thought that the last few times it worked without any manual intervention 12:23:20 I had an empty sbcl directory 12:23:26 I'm sorted now I think 12:23:30 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 12:23:35 but the submodule didn't init correctly 12:23:48 I had to do a manual git submodule update --init 12:23:57 not to worry, the script had broken well before then :-) 12:27:20 -!- LiamH [~none@pool-173-73-131-126.washdc.east.verizon.net] has quit [Ping timeout: 244 seconds] 12:28:18 argh, now it complains because I don't have cl-ppcre 12:28:20 (it's right) 12:28:31 ok, lunch. Will sort out sbcl-page / stuff later 12:42:24 LiamH [~none@vpn219118.nrl.navy.mil] has joined #sbcl 13:05:34 -!- LiamH [~none@vpn219118.nrl.navy.mil] has quit [Ping timeout: 244 seconds] 13:35:40 LiamH [~none@pool-173-73-131-126.washdc.east.verizon.net] has joined #sbcl 13:40:01 gko [~user@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 13:55:34 I don't get it 13:55:43 I must have managed to do this last month 13:55:52 where on earth has my cl-ppcre gone? 13:56:53 you're building in a chroot, and weren't the last time around? 14:02:27 aha 14:02:29 other way round 14:02:39 but that definitely rings a bell 14:05:53 (I admire your remote telepathic debugging skills) 14:07:39 I learned from the master 14:44:39 -!- LiamH [~none@pool-173-73-131-126.washdc.east.verizon.net] has quit [Quit: Leaving.] 14:47:24 OK, I think I'm actually done. Or at least I have manually done all the steps that were meant to be automated as well as all the manual steps. 14:47:38 I know that we have that report about many different manual versions being available 14:47:47 but other than that, I look forward to seeing what the month brings 15:13:39 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 15:14:26 nyef [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has joined #sbcl 15:17:54 antgreen [~user@dsl-173-206-206-68.tor.primus.ca] has joined #sbcl 15:22:16 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 15:25:00 -!- hlavaty [~user@91-65-217-229-dynip.superkabel.de] has quit [Remote host closed the connection] 15:36:11 wbooze [~wbooze@xdsl-78-35-170-170.netcologne.de] has joined #sbcl 15:50:35 pnpuff [~aeiou@unaffiliated/pnpuff] has joined #sbcl 15:59:31 -!- wbooze [~wbooze@xdsl-78-35-170-170.netcologne.de] has quit [Ping timeout: 260 seconds] 16:08:02 wbooze [~wbooze@xdsl-87-79-194-179.netcologne.de] has joined #sbcl 16:22:12 -!- ASau is now known as P6MK 16:23:24 -!- P6MK is now known as ASau 16:32:55 ... Are we out of code freeze? 16:45:07 yeah 16:51:10 go go go 16:55:52 I have no current access to any of the machines that I have stuff to forward-port for, and have not dug the other commit that I wish to push out from my arm port tree yet, I'm afraid. 16:57:06 Hrm. I do, however, have access to my PS2, if I can find the cables and software required to boot it to Linux (might be a 2.2 or 2.4 kernel, though). 16:57:32 well, there's at least three weeks before I can summon up the energy for another code freeze 16:59:31 Okay, so I might be able to get a couple things in this weekend, and I should have access to my sparc, my mips, and possibly a ppc over the week... 16:59:42 -!- gko [~user@114-34-168-13.HINET-IP.hinet.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 17:04:54 nyef: What's the ARM tree commit? 17:07:06 "Thou shalt not MAKE-OTHER-IMMEDIATE-TYPE." 17:09:09 The VOP in question is inconsistently implemented, looks to be buggy on at least one backend, and is only ever used to create an unbound-marker, for which we have a VOP named MAKE-UNBOUND-MARKER. 17:09:39 Rather than implement MAKE-OTHER-IMMEDIATE-TYPE for ARM, I got rid of it. 17:10:03 What kind of MIPS did you end up working with, and how happy are you with it? 17:10:59 A linksys E3000, I believe, and I'm quite happy with it... as an ethernet switch. 17:11:21 I'm at ~50min rebuild time, which feels rather pre-21st-century to me. But maybe I'm remembering those 1990s RISC workstation too fondly. 17:11:44 I think that might be a GOOD rebuild time. 17:12:00 My sparc does a build in about that timeframe. 17:13:03 Also mightily disappointing is that was using a 64bit userland in IRIX back then, with n32 ABI only as a multiarch-like option. And ten years later, this Debian thing here runs a pure n32 userland on the shiny 64 bit CPU. :-( 17:14:30 (Not it matters much to SBCL, n32 is still a shiny new feature in our backend IIUC.) 17:15:53 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Ping timeout: 256 seconds] 17:16:09 my distinctly-post-21st-century during-PhD rebuild time was comfortably 90 minutes 17:16:27 youth of today, etc 17:17:51 Thinking about it, I cannot possibly have built SBCL on that SGI O2 back in 2001. What I'm remembering is probably the Gwydion Dylan build time. :-) 17:17:56 I've been finding myself wishing that at least host-1 would do a build based on dependency information, so I didn't have to wait for a full build of host-1 to test a new VOP... or most of a build to find that I'd made an error with it. 17:18:57 I'll easily believe that you can't have built SBCL on that O2 back in 2001, simply because you'd've already fixed the build problem if that were the case. (-: 17:24:29 I lived with 30-40 minute builds time on an x86 not long ago. 17:25:37 I still have 30 minute build times on my main sbcl-hacking system. 17:28:33 Re self build times, I wonder whether GENCGC/RISC wouldn't be even faster if we didn't trap through the kernel in allocation. The SPARC self-build time speedup is around 8% already, but considering how performance critical allocation is, those extra cycles might still be noticeable. 17:28:45 Anyway. Easier to order a MIPS computer from China than a Kindle from the US. Interesting times. 17:29:50 Hrm. Wait, always trap, or only when the region overflows? 17:30:05 nah, only on overflow. :-) 17:30:18 Okay, you had me worried there for half a second. 17:30:28 ... I actually accidentally trapped every time at first. Boy was that build slow! :-) 17:30:36 Heh. 17:31:50 Current ARM P-A loads R7 (OCFP, "scno") from a static symbol (*pseudo-atomic-interrupted*), compares against reg_NULL, and does a conditional SWI if the value is less than the address of NIL. 17:32:29 The SWI does a system call, the system call number is in R7, and the BREAK_POINT system call required to get a SIGTRAP is less than the address of NIL. 17:33:05 And if I hadn't been able to use a conditional SWI, I'd've had to stash the actual breakpoint *ELSEWHERE*. 17:33:46 -!- pnpuff [~aeiou@unaffiliated/pnpuff] has quit [Quit: Bye.] 17:37:59 -!- sdemarre [~serge@91.176.24.155] has quit [Ping timeout: 260 seconds] 17:38:41 pnpuff [~aeiou@unaffiliated/pnpuff] has joined #sbcl 18:26:26 -!- antgreen [~user@dsl-173-206-206-68.tor.primus.ca] has quit [Ping timeout: 255 seconds] 18:33:34 hmm. So, generally people seem think that a message which roughly means "beta version! do not use in production" ought to be optional, so that they can use it in production without getting a message. 18:34:06 and without having to recompile or do something very tricky like 2>/dev/null 18:34:07 Sounds about right. 18:34:18 Wait, is this for the kitten-of-death message? 18:34:38 maybe they are dog people? :-) 18:34:48 haha 18:35:47 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Quit: Leaving.] 18:36:57 There are people nowadays actively taking care of the windows port, no? 18:37:27 unconditional fprintf is a bit brutal, I suppose, and an ultraprofessional vendor might not have chosen this particular wording. But overall, it seems to help clarify that, inspite of the platform being very popular, it's a binary from the wrong branch. If the message pushed people towards using a binary from the right branch, it's a good message. 18:43:52 Given that the message was originally just to say "we're about to call into lisp", as a debugging aid while trying to get the port minimally working, I think a brutal implementation is reasonable. (-: 18:54:27 wait, what? undefined_tramp is a tagged lisp object sitting in the assembler code? that's a bummer. 19:06:28 how and why are we depending on that? 19:24:52 Debugger, for starters. 19:25:36 Some platforms have the undefined_tramp symbol actually be a function pointer, but most use it as a "raw" address. 19:27:07 I have a branch which puts all of the tramps into src/assembly/ rather than leaving them as runtime magic. 19:28:49 rep.or.cz ? 19:29:09 nyef: oh. do you happen to have access to that branch? All I need is a PPC undefined_tramp outside of the runtime. 19:29:20 Might be able to find it. 19:29:28 It required a bit of a hack to genesis, IIRC. 19:32:45 Found it. Going to see if it's somewhere public already now that I know which branch it is. 19:32:53 thanks, that would be nice 19:33:57 Might not be my only problem, but would certainly keep one possible issue out of the way. Currently I'm apparently trying to execute the string "Kill ourself with signal number..." as code, and I can see how that might not work. Same code works on x86, so the undefined_tramp bit sticks out as a prominent possible cause. 19:37:02 http://repo.or.cz/w/sbcl/nyef.git/shortlog/refs/heads/no-x86oid-assem.S 19:37:41 It's very rough, and only done for one or two ports, but ISTR it working. 19:39:10 So, I guess it doesn't do all of the tramps, but it points the way for it. 19:39:31 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 252 seconds] 19:42:35 very promising, thanks. 19:42:48 And I've just remembered why I wanted to destroy the x86oid assembler parts of the runtime, and it had everything to do with the windows port. (-: 19:45:32 Ports with sane GCs and call instructions that take offsets tend to have undefined_tramp as a function-like value. 19:46:04 This basically means SPARC, of course. 19:49:29 lichtblau: nice one, re static magic page. 19:50:27 lichtblau: on the kittens, I think that users aren't allowed to have votes 19:51:15 which would you rather, complaints about an unprofessional message, or complaints that we're not supporting the user's choice of deployment platform sufficiently well and would we fix all the problems immediately!? 19:53:31 pkhuong: Didn't want to waste a register as global-safepoint-page-tn, and a three-instruction safepoint sequence is also dumb. With this change, LOAD ZERO_TN, (-PAGE_SIZEish)NULL_TN ought to work. 19:55:29 safepoints everywhere? 19:57:19 either everywhere or nowhere. The #!+(AND nice-feature (NOT endless platform exceptions)) madness must stop. 19:58:21 And I realize that I'm currently contributing to said madness, but the goal must be to swipe it all away, really. 19:58:22 Can we not simply require that each platform either support nice-feature or not support it? 19:59:01 yea. encode NOT endless-platform-exceptions in one place for whether to allow setting nice-feature in the first place. 19:59:31 Isn't there a spot for that in the build process, fairly early on? 19:59:41 Sounds familiar 20:00:12 True, although I was thinking more generally, e.g. (AND nice-feature (NOT sb-thread)) is a case I don't want to think about anymore. 20:01:06 Another example: Why do we still have #!-linkage-table at all? Performance concern? OpenBSD? ...? 20:01:21 Easier porting to new CPU types? 20:01:30 ARM is currently #!-linkage-table, for example. 20:01:59 Of course, ARM is currently #!-unwind-protect, or would be if we had such a feature. 20:03:24 Well, soon we'll have an add-on feature for linkage-table that makes every second #!+linkage-table form even more complicated. And the odd thing is: Just the new feature alone would be easier than either of the two current cases. 20:03:50 Heh. 20:04:22 what's the new linkage table? 20:05:55 Anton's "use the linkage table for everything, even during cross-compilation" thing. 20:06:47 Nice. Means we can rebuild the runtime without having to re-run genesis? 20:07:17 wait, isn't the problem there the constant locations for things like nil? 20:07:30 I'm exaggerating a little, of course, because "having a linkage table" is certainly tricker than "not having a linkage table" in principle, but it's certainly easier than the current combination of #-sb-xc-host #!-linkage-table #!+linkage-table. 20:07:32 nyef: exactly 20:07:53 No, that's the inability to build the runtime without having to build at least half of the compiler. 20:12:17 -!- nyef [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has quit [Read error: Connection reset by peer] 20:12:41 nyef [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has joined #sbcl 20:13:00 Hunh. What happened there? 20:17:16 lichtblau: I had no issue with using a thread-base-relative page (: 20:19:27 pkhuong: ... which would also mean that interrupt-thread might not have to stop all other threads...? Haven't dared deviate from Anton's design yet though. 20:29:04 lichtblau: yup. that was the original design, exactly because of interrupt-thread. 20:30:50 -!- pnpuff [~aeiou@unaffiliated/pnpuff] has quit [Quit: .] 20:32:27 hmm. Maybe it's just because "thread-relative access" means "ugly safepoint sequence on x86"? 20:33:51 edgar-rft [~GOD@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 20:33:57 (Because no OS I have tried is able to report a si_addr for an instruction with fs prefix.) 20:37:20 nyef_ [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has joined #sbcl 20:38:00 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 20:39:34 right. 20:40:13 I was assuming that threads on win32/x86 would instead use nyef's thread-in-ebx branch 20:40:27 -!- nyef [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has quit [Ping timeout: 260 seconds] 20:46:28 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 20:47:06 That was, in point of fact, the REASON for the thread-in-ebx branch. 20:51:02 waste a whole register for the TLS base just to make interrupt thread slightly faster? 20:51:11 that seems like a poor trade-off. 20:51:20 well, also special variable access 20:52:46 Which on Windows is two movl instead of one, because we first need to fetch the thread from %fs:magicnumber. 20:54:16 nyef_, pkhuong: do you guys have plans regarding lp#1072739 (please say yes, so that I don't have to worry)? 20:55:44 LiamH [~none@pool-173-73-131-126.washdc.east.verizon.net] has joined #sbcl 21:01:27 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Quit: Leaving.] 21:08:47 sdemarre [~serge@91.176.24.155] has joined #sbcl 21:13:37 No plans here. 21:14:13 It does seem plausible that it could be the ordering problem, if the're's an unwind-protect involved. 21:29:22 -!- edgar-rft [~GOD@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: this computer sucks] 21:56:29 Quadresce [~quad@unaffiliated/quadrescence] has joined #sbcl 21:57:17 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Disconnected by services] 21:57:23 -!- Quadresce is now known as Quadrescence 21:59:01 -!- foom [jknight@nat/google/x-tpjgyogneamrzmpi] has quit [Read error: Operation timed out] 21:59:25 foom [jknight@nat/google/x-urvduoavbrafybmj] has joined #sbcl 22:04:07 -!- sdemarre [~serge@91.176.24.155] has quit [Ping timeout: 256 seconds] 22:15:23 minion [~minion@tiger.common-lisp.net] has joined #sbcl 22:15:23 specbot [~specbot@tiger.common-lisp.net] has joined #sbcl 22:47:48 nyef__ [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has joined #sbcl 22:50:47 -!- nyef_ [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has quit [Ping timeout: 255 seconds] 22:57:03 -!- nyef__ [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has quit [Read error: Connection reset by peer] 22:57:28 nyef__ [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has joined #sbcl 23:24:46 nyef_ [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has joined #sbcl 23:25:47 -!- nyef__ [~nyef@pool-70-109-148-190.cncdnh.east.myfairpoint.net] has quit [Read error: Connection reset by peer] 23:26:52 ... PPC KNOWN-CALL-LOCAL calculates the LRA into CODE-TN?!? 23:28:49 -!- LiamH [~none@pool-173-73-131-126.washdc.east.verizon.net] has quit [Quit: Leaving.] 23:32:06 Ah! No, I'm mis-reading the code. 23:33:44 Panic over, definitely mis-read the code the first time through. (-: