Antti wrote:
That is partially the point of bringing up some "crazy" ideas.
I like outside the box ideas, though not all have immediate use =)
Antti wrote:
If we optimally pack the information into those 5 bytes, our "atomic" system calls could have some interesting features. Having a one-byte-shorter instruction than, e.g. "mov eax, 123" & "int3", is an advantage in itself. Perhaps that is not enough so let's innovate.
Is it really any more "atomic" than your "normal":
Code:
mov al, 0x15; Select syscall function
syscall
It's certainly a lot slower.. And you have to pack the data into the byte, of course if that's done at compile time then there's not much of an issue but at runtime it becomes even slower and possibly bigger.. My above example also supports 256 syscall functions, but can't remember how many bytes the move to AL takes..
Antti wrote:
Brendan has mentioned his "batch processing" of system calls. What if we think about the idea of not returning to ring 3 immediately? If other system calls immediately follow, why don't we just interpret them? Writing a simple interpreter is easy if every system calls start with a byte 0xA0, 0xA1, 0xA2, or 0xA3 and has a constant length.
I thought Brendan's "batch processing" of syscalls is message based, in which case you could just provide the kernel/syscall handler with a message list, and thus you don't need any "interpreter" and again it's faster and easier..
Just trying to figure out if there are any use cases for using VAS (virtual address space) for syscalls, possibly saving one byte with significant runtime overhead just doesn't seem like it's worth it..
As for the TLB concerns the others raised, can't those be avoided by marking the page(s) present (so cached in TLB) and also marking it ring0 or something else to cause a #PF?