freenode/#sicl - IRC Chatlog
Search
15:31:06
Bike
beach: Your plan for local exits through unwind-protect or special bindings is to not handle it in ast-to-hir but rather a later pass, right?
15:36:04
beach
The plan is to discover an instruction I1 such that the successor I2 is in a different dynamic environment, and to determine statically whether there is an UNWIND-PROTECT entry "in between" the two dynamic environments.
15:39:40
beach
As I recall, just because I didn't feel like modifying AST-to-HIR, but maybe I changed my mind at some point, and decided the right place is AST-to-HIR after all.
15:41:14
beach
Now that you mention it, I think I decided AST-to-HIR is right, but since I am not using unwind-protect during bootstrapping, I dropped it for the time being.
15:43:10
Bike
you'd have to set up some more information in the context, probably. not hard but probably kind of involved.
15:44:24
Bike
anyway, ill probably take a look at it... doing it in ast-to-hir makes much more sense to me, but i remembered you were talking about doing it later, so i wanted to make sure i wasn't missing something
15:45:56
beach
So every time the dynamic environment is augmented, the stack has to be pushed to, rather than just the dynamic environment in the context being altered.
15:48:29
beach
I suppose when the stack is popped through an UNWIND-PROTECT, one would have to do a full unwind, as in abandoning intermediate exit points, and then call the thunks in the UNWIND-PROTECT entries.
15:49:19
beach
It would probably be infrequent enough that it could be handled the same way an UNWIND-INSTRUCTION is handled.
15:50:44
Bike
So to abandon intermediate exit points in this context, what you'd have to do is call the cleanup thunk with a dynamic environment argument that doesn't have those exit points in it?
15:51:49
beach
That or an environment in which those exit points are explicitly marked as abandoned, the way I do in SICL.
15:52:42
beach
Or you could do what you want, if you use the freedom the Common Lisp HyperSpec gives you.
15:53:52
Bike
I still don't understand how it would be more efficient to abandon those exit points, but that's neither here nor there
15:54:41
Bike
not doing so. the EXIT-EXTENT:MEDIUM proposal that wasn't adopted, i think it's called
15:55:11
Bike
anyway, i was thinking about this last night, and couldn't come up wiht any way to reliably mark an exit as no longer valid without explicitly marking it so on the way out, so that's that
15:56:23
Bike
The issue says some implementations were more efficient when they abandoned those exit points, and I don't understand how that would happen
15:58:19
Bike
I thought maybe it was because with longer extents you can do things like (block nil (unwind-protect ... (return))) to prevent any kind of exit at all, but the issue doesn't describe that as a problem or anything
16:02:30
beach
So the more I look at Clasp activity, the more I am convinced that it would have been easier to rewrite Cando in Common Lisp from scratch.
16:02:32
beach
But then, the more I look at Clasp activity, the more I am impressed by the momentum it has created. I don't know whether that momentum has to do with people just wanting C++ interoperability, or whether it has to do with the charisma of drmeister.
16:09:40
Bike
I mean, people do view C++ integration as desirable. Personally, I'm pretty interested in systems that can include code from different compilers... Lisp is bad at this, Python is bad at this, C++ is better but still pretty terrible
16:12:28
Bike
I mean the situation is that the underlying operating systems are written so that they can use code from anywhere, but practically speaking nobody does except in using different C compilers
16:13:37
beach
I think they *can* use code from anywhere, but in practice they make it more or less hard to do so.
16:14:57
Bike
Yeah. I mean there's not much effort put in for anything beyond C. You're right that it's difficult to do, but I'm curious how it would look.
16:15:39
Bike
What you're doing in SICL, where code is vetted by the compiler, that's a fine alternate strategy, and you hopefully get some advantages because you're less half-assed than this posix situation
16:16:13
Bike
i mean, as concerns clasp, people probably mostly just want to link webkit or whatever, though.
16:18:42
beach
I am just completely disconnected from the world of C, C++ and such. I don't need to write any software that depends on external libraries. For which I am grateful of course.
16:26:07
Bike
With a lot of sciences the situation is that somebody wrote code for it in the 70s and nobody's bothered looking at it since. When I was in college I worked on a system for neuron simulation that was like, tens or even hundreds of thousands of lines of code that needed to run in a particular 90s version of Borland Delphi
16:27:03
Bike
drmeister works pretty damn hard but it's kind of a challenge to rewrite a bunch of systems like that
16:27:52
beach
Wow, that's bad. I kind of know the situation, because I consulted for the CEA here in France, and they had (likely still have) Fortran libraries that they need, but that nobody knows how they work anymore.
16:28:39
Bike
Lot of that too. With Clasp it doesn't help that those libraries are doing quantum electrodynamics or whatever instead of something lots of people understand like linear algebra.
16:30:06
beach
For the CEA, the situation was actually even worse, because several people developed personal versions of code for the same problem, and no version was sufficiently maintainable or documented that anyone dared tough it, let alone merge different versions.
16:30:50
beach
There was one guy who knew what he was doing, and he was the one who invited me to consult and give talks.
16:31:36
Bike
Haa. Yeah that sounds about right. Actually with the neuron thing this was the old version of the software, and the guy I worked with was on the losing end of a split with some other people who rewrote it in Python (but lost a lot of functionality)
16:32:31
Bike
If anything I'm glad drmeister has used as much lisp as he has - I mean he has rewritten some of the chemistry in lisp. It's pretty forward thinking by comparison with this situation.
17:38:38
Bike
In SICL every function gets its dynamic environment as an actual argument, right? Hypothetically, could you just have it in a thread local global instead?
17:39:31
beach
I do it the other way around, I use the dynamic environment to find the reified thread.
17:43:34
beach
So when you bind a special variable, you access the thread to store the old value on the stack, and you install a new value in the cell in the thread.
17:44:33
Bike
well sure, I mean like, below that level. To do that in clasp we just have the special variable table declared "thread_local", and the C++ compiler takes care of it in some way I don't understand.
17:45:53
beach
Access to "global" variables is not as straightforward as it used to be in C-like languages anyway.
17:45:59
Bike
and in SICL you have, what, the end of the dynamic environment stack be a thread object?
17:47:32
beach
I may have to change that decision, depending on how much work the thread-local memory allocator would have to do to find the thread.
17:47:39
Bike
i only just realized the fairly obvious fact that reading a thread local variable in C must be more involved than dereferencing a pointer, even ignoring linking issues
17:53:59
froggey
thread local variables for simple static executables are very simple. the gs segment register holds a pointer to the thread's TLS area and variables are just that plus an offset
17:55:41
shka_
beach: I was thinking about Pinker's explanation of what makes prose understandable and efficient
18:07:06
Bike
I found a Drepper paper explaining how it works in relation to shared objects and yeah, involved
18:43:49
Bike
the current Cleavir representation of dynamic environments should be fine across implementation. the question is what to do with local unwinds. We could, for example, insert UNBIND- and UNWIND-DEPROTECT- instructions on the local unwind paths... and for unwind-protect, a funcall of the cleanup thunk as well
18:44:23
Bike
SICL might want to give those funcalls a dynamically-passed dynamic environment to handle exit point abandonment, or it could just take whatever dynenv was in place when the unwind-protect was entered, and rely on the entry marks
18:45:46
Bike
on SICL UNBIND- and UNWIND-DEPROTECT- would just pop the dynamic environment entry (I think that's how it works?). on clasp UNBIND would replace the symbol value and UNWIND-DEPROTECT would be a nop.
18:47:48
Bike
the alternate would be to forgo individual instructions and just have a like LOCAL-UNWIND instruction that does everything
18:48:09
Bike
maybe with a better name than that though, i've been using "unwind" interchangeably with "nonlocal"
19:06:55
beach
froggey: Oh, so the GS register is actually available and usable? I should just use it for the reified thread then.
19:08:13
Bike
wikipedia says "Four of the segment registers, CS, SS, DS, and ES, are forced to 0", so i guess the other two are fair game
19:09:25
beach
I should read up on the segment registers, but not tonight. I am off to spend time with my (admittedly small) family.
19:15:23
Bike
maybe i was reading the output wrong or something, cos stuff online says gs. i don't know