libera/#sicl - IRC Chatlog
Search
3:09:43
moon-child
so, sbcl supports ATOMIC-INCF on conses. At high safety levels, it will generate a cas loop; at low safety, it will take advantage of XADD (not checking whether the object pointed-to is actually a fixnum). Presumably the latter behaviour is not desirable for sicl. So atomic-incf
3:35:06
Bike
couldn't you do a cas loop generally, and optimize to xadd or whatnot when type inference can prove it's a fixnum
3:37:01
moon-child
I was going to say: I can't imagine there's any meaningful case where you could prove the car of some cons was a fixnum, and you would also want to do atomics on it
3:37:33
moon-child
because it would necessarily shared, so any alias analysis you might try would be nil. Would need global analyses, which I do not think sicl intends to perform
3:38:28
moon-child
but I realised you might be able to perform such an inference in one case: when the cons is only available to closures
3:42:12
Bike
also, this would also apply to more general kinds of things, like standard objects or arrays
3:46:21
moon-child
yeah, just specifically thinking of atomics as a case where hardware acceleration is more significant. Type declaration I don't think would be very helpful
3:47:52
moon-child
(defclass c () ((x :type (cons fixnum fixnum)))) (defparameter *x* (make-instance 'c)). Ok. Now you may protect against (setf (car (slot-value *x* 'x)) 'not-a-fixnum). But how do you protect against (let ((x (slot-value *x* 'x))) (setf (car x) 'not-a-fixnum))?
4:11:48
Bike
moon-child: yeah that's near impossible. i was thinking the more obvious case of a slot being declared fixnum.
4:14:13
Bike
ok but what i meant was that without the type declaration you could still do atomic-incf with the cas loop.
4:15:47
moon-child
hm, I guess I was not entirely clear initially. I don't think there should be a primop for atomic incf on conses, if there's no context where it would generate better code than the cas loop. Cas loop can live in userspace, but a portability library can make up the difference
4:22:45
Bike
i haven't figured out the best way to represent atomics in IR. what i have now is MIR operators to do atomic loads/stores/CAS on addresses. then if you cas a car or whatever it just reduces the car to address operations.
4:24:23
moon-child
I see. I was thinking about the duplication of operators that would be necessary in a more explicit approach
4:26:41
Bike
i also haven't yet implemented atomics for lexical variables, which seems important to completeness, but might require changing a lot of things throughout the compiler
4:30:59
Bike
and i'm not even sure about exposing cas since it's kind of more "internal" than something like atomic-incf or atomic-update, and what if it's better to use load-link or something instead, and blah
4:32:01
Bike
hmm. now that i'm thinking about it maybe not exposing cas and only exposing atomic-update would be good
4:33:39
moon-child
re update: think the implementation should expose more primitive functionality, and leave more 'sugary' things to utility libraries. Also there is an existing portability library which exposes only cas
4:34:50
Bike
but what if a target machine has ll/sc instead of cas? you can emulate cas with ll/sc, but then it's not really "primitive" functionality any more
4:36:19
moon-child
sure. I mean, you always have to decide what to abstract. I think cas and ll/sc both have fairly straightforward implementations in terms of each other, so it's not a huge deal
4:44:09
Bike
i mean practically speaking, it's probably eq except fixnums and singles are eql, but then you effectively have a new predicate between eq and eql
4:45:45
moon-child
I don't think it's a new predicate between eq and eql. It's defining the behaviour of eq in a particular way (which the standard leaves unspecified)
4:46:02
moon-child
hence, your extension is not 'we have cas', but rather 'we have cas, and eq is guaranteed t for eql fixnums'
4:48:21
Bike
an atomics extension requiring a pretty much unrelated extension like that is the kind of thing that bothers my sense of cleanliness