- ArtParticipantMarch 12, 2014 at 8:21 amPost count: 8
In short, the state is saved/restored by a hardware mechanism. All the metadata is saved/restored with it.
The “call stack” on a Mill is not the same as on a conventional. On a Mill, data that is not part of programmer visible state (such as function or interrupt return address) is saved/restored by the spiller hardware, and if enough levels of interrupt and/or function call occur to push this data to main memory, it is pushed to a completely different memory block. Normally, except for debugging, this “saved state” region is protected from all access except by the spiller hardware. The programmer visible “call stack” (such as C automatic local function variables) on a Mill is in a memory privilege region containing only programmer visible variables.
This same spiller hardware mechanism is used by the OS to change thread contexts. How something like Unix fork is handled is NYF, and I will defer to Ivan to explain that when it is.
- Russell JohnstonParticipantMarch 12, 2014 at 6:09 pmPost count: 9
Ah, okay. What are the performance implications of this method of context switching? It sounds like they could be pretty good- spilled lazily, etc. I’m wondering specifically what it would mean for things like coroutines, continuations, etc. Or is that too closely related to fork()?
- Ivan GodardKeymasterMarch 12, 2014 at 6:32 pmPost count: 607
Everything is lazy and background, so performance is very good unless you do a deeply nested run of calls with lots of arguments and no work except the next nested call. “Very good” here means the usual one-cycle cost of a call.
There is support for coroutines (though NYF) and non-resumeable continuations. Scheme-style repeatable continuations require a garbage collector, which is not what hardware does 🙂
You must be logged in to reply to this topic.