libera/#sicl - IRC Chatlog
Search
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.