libera/#sicl - IRC Chatlog
Search
3:14:19
beach
hayley: Should I be worried about you? You haven't submitted any pull requests for some time, and now I need to add to the register allocator with my new instructions, so it is bound to create conflicts. I don't know how you work, but the way I do it is I try to make the bootstrapping script pass after a small number of modifications, and then I push those modifications so that others can work with the modified code.
3:14:27
beach
Also, how come you haven't given me feedback on the handling of literals? Is it that what I wrote i incomprehensible?
3:16:12
hayley
Nothing to be worried about. I read the chapters you mentioned and I don't really have anything to say, as the description is fine.
3:17:27
beach
The reason I asked for feedback is that *I* don't know whether it's fine, so I need that feedback.
3:18:30
hayley
I've held off making a pull request because I still haven't worked out how the THREAD object should work, and bootstrapping produces a lot of warnings (which I introduced) related to being unable to generate LIR for return value-related instructions.
3:20:04
hayley
Well, you run bootstrapping with MIR-to-LIR disabled, so the warnings shouldn't be a problem.
3:20:48
beach
But I turn it on from time to time to check that I didn't introduce any gross mistakes.
3:22:02
beach
And about the thread object, perhaps we need to work that out together. It is not obvious to me.
3:23:05
hayley
There are quite a few warnings generated (particuarly while loading ctype), so I'm somewhat worried that those warnings would make it hard to find the other warnings.
3:23:45
hayley
I just pulled from your repository, and bootstrapping with MIR-to-LIR enabled still works, so I will make a pull request now.
3:34:04
hayley
This morning I went on a bike ride, and saw someone with a shirt that said "It worked on my machine!"
3:36:31
mfiano
Well, I have run out of patience communicating with CptKirk and their other aliases over the last week.
3:37:49
mfiano
I have implied they should use #clschool for most of their questions to no avail. I also think we should have an april IRC channel, as a lot of activity lately was about the history of APL or things not even indirectly related to CL
3:42:59
beach
hayley: You should let me know when you have time and feel like discussing this tread object thing.
3:50:21
beach
mfiano: I think that an #april channel would be good. I may suggest it if this kind of exchange continues.
3:57:45
mfiano
Yes, that would be good. I prefer a more focused channel. I didn't subscribe to lessons in
3:59:44
hayley
APL is growing on me, admittedly. Probably because array munging requires fewer pointless constructs in APL than in Python.
4:03:30
beach
I was lucky to go to the university that I did. We had a course, second or third year, I can't remember, where Lisp, APL, and Simula were introduced. And this was 1977 or so.
7:13:28
heisig
Yes, we are back home. But I'll leave for another (paid, official) two-week trip tomorrow.
7:15:06
heisig
It is a summer academy organized by three German universities. And I organize one of the eight groups there.
7:15:44
heisig
We have brilliant participants, and we'll be hiking and programming all day long. I'm very much looking forward to it.
7:16:42
heisig
About the handling of literals. One thing I wonder is how SICL fasl should work in terms of safety and backwards compatibility between different versions of SICL.
7:17:30
heisig
I am mostly afraid that malicious fasls could write literal objects to the wrong location. Is that a legit concern?
7:17:37
beach
SICL FASLs are way safer than those of other systems, since they don't contain any executable code.
7:22:50
heisig
Let me reformulate the question. Should regular code be able to write to code vectors?
7:25:21
beach
I don't think we do, no. My plan is to hide all the compiler and loader stuff in a separate environment.
7:26:07
heisig
In the extreme case, we could use CPU features such that only certain privileged code can write to code vectors. I'm thinking of CLOSOS here.
7:27:04
heisig
The reason why I brought this up is that resolve-load-time-value triggers a write to a code vector, and I was wondering how we'd make sure that only the 'right' object is written to the right location.
7:27:13
beach
Code vectors could be allocated in read-only pages, and only privileged code would be able to alter the page status (temporarily).
7:27:58
heisig
beach: Right, something like read-only pages. But the implementation is not important right now, it is rather what we advertise as being allowed.
7:29:02
heisig
So the kinds of error checking performed by resolve-load-time-value should be stated very explicitly. Or one might have to change the API to something that doesn't involve indices into the code vector.
7:31:29
heisig
One way to avoid 'resolve-load-time-value' completely would be to define fasls as containing a vector of thunks, where thunk K corresponds to object K, assuming that all objects with index less than K have already been initialized.
7:33:08
moon-child
I don't think hardware protection features are warranted. Access to privileged data will already be handled by capabilities; why should this be different?
7:33:30
moon-child
in such context, one might allow a trusted user application to write it own assembly (cf sbcl vops)
7:35:25
heisig
beach: I think 'resolve-load-time-value' is overly specific and possibly not ideal, so it shouldn't be part of the specification.
7:37:33
hayley
I think having a read-only replica of memory would generally be handy (you can pass a read-only replica of any object with no wrapper overhead), but of course objects that are referenced by the replica would still be mutable.
7:37:40
beach
heisig: All I am trying to do right now is to make sure I can create an executable file. The specification is meant for getting feedback. Nothing is set in stone.
7:37:59
hayley
In the case of code objects, it should be simple enough to not hand out code objects still.
7:41:25
heisig
Apart from my concerns about 'resolve-load-time-value', I really like the new treatment of literals.
7:41:30
beach
I really don't understand what the problem is. This way of handling literals does nothing more sophisticated than what the code generator must do, which is to generate instructions and store them in memory.
7:42:53
beach
All I am doing is figuring out in which order things must be done, given that the code generator must first generate the code in order to find out where instructions are located, before it can fill in data that depends on such locations.
7:44:21
heisig
Yes, forgot that in SICL, LOAD does many of the things that used to be done by COMPILE-FILE.
10:56:20
hayley
We haven't come up with any other uses for it, but I suspect it would eventually also hold another "thread object" which would be used by other threads (say, in (bt:all-threads)), and thread-local allocator state.
10:57:20
beach
Fair enough. However, for the current problem, I suggest we just generate a NAMED-CALL instruction with the additional return values.
10:57:53
beach
Accessing the thread object is going to be expensive, so an additional inexpensive named call is not going to make a difference.
10:58:26
beach
The thread object is a standard object with an indirection, and the additional values might be in a vector with yet more indirection, etc.