4 ms·

They've repeatedly said they want to run current software well, presumably including software that forks and does not follow up with exec (regardless of how ill

They've repeatedly said they want to run current software well, presumably including software that forks and does not follow up with exec (regardless of how ill-advised that may be; obviously opinions vary on this). Trapping to emulation on fork would seem to fly in the face of this. That being said I'm still not sure how you can get all of fork's semantics out of this mechanism... (For that matter various sneaky VM aliasing tricks ["magic" circular buffers mapped twice in a row so that any size and position block is contiguous, same file mapped in multiple processes with different (non-contiguous) memory mappings] are going to fail miserably with the virtual-addressed cache. It may well be worth not being able to do those things for the benefit of moving the TLBs, but it also flies in the face of "will run current software.")

willvarfar 9y ago
(team Mill) > "magic" circular buffers mapped twice in a row so that any size and position block is contiguous Yes this exact case is one of those that won't work. There are a handful of other things that don't work, like people who roll their own coroutines using assembler. We promise 'don't rewrite, just recompile' but your codebase has to be 64-bit clean and not use any assembly language for any other ISA and not make other unportable assumptions about the hardware. I can't think of any software that actually uses these circular buffers that wouldn't be worth adapting to the Mill rather than adapting the Mill to them; can you? ;)
- phs2501 9y ago
  How do you plan on supporting user/process level coroutines and multiple stacks / stack switching within the same turf? Obviously the CPU needs to be involved because you've got all the ancillary belt and spiller state that needs to be switched as well. For that matter have you guys touched on how stack unwinding is going to be handled yet? How do I implement exception handling, longjmp, CL's non-local GOTO, etc?
  - igodard 9y ago
    The next talk will be on threading, and will address all this. The IPC and threads talks belong together, but are too big to combine in one talk unfortunately.

willvarfar 9y ago

(team Mill) > "magic" circular buffers mapped twice in a row so that any size and position block is contiguous Yes this exact case is one of those that won't work. There are a handful of other things that don't work, like people who roll their own coroutines using assembler. We promise 'don't rewrite, just recompile' but your codebase has to be 64-bit clean and not use any assembly language for any other ISA and not make other unportable assumptions about the hardware. I can't think of any software that actually uses these circular buffers that wouldn't be worth adapting to the Mill rather than adapting the Mill to them; can you? ;)

phs2501 9y ago
How do you plan on supporting user/process level coroutines and multiple stacks / stack switching within the same turf? Obviously the CPU needs to be involved because you've got all the ancillary belt and spiller state that needs to be switched as well. For that matter have you guys touched on how stack unwinding is going to be handled yet? How do I implement exception handling, longjmp, CL's non-local GOTO, etc?
- igodard 9y ago
  The next talk will be on threading, and will address all this. The IPC and threads talks belong together, but are too big to combine in one talk unfortunately.