On Wed, Feb 11, 2015 at 10:59 AM, Keean Schupke <[email protected]> wrote:
> There is only one entry point into the program. The others like interrupt > vectors and exceptions are re-entry points. The main entry stack frame > would still be there for all these re-entries, and only gets cleaned up on > program exit, by which time all the interrupt and exception vectors must be > cancelled if you don't want a horrible crash :-) > Keean: I think you're joking here, but since it leads to something (very) mildly interesting... What you say is actually not true in the EROS or Coyotos kernels. Yes, there is an initial entry point where all of the pre-user-mode initialization occurs. The end of that path is a call to sched_dispatch_something(), which actually *does* exit the kernel, effectively destroying the initial stack. The storage for that stack is subsequently used as the stack space for CPU0. Once that dispatch occurs, there can be mulitple re-entry points into the kernel, because many processors have more than one vector they may invoke. We actually converge all of them back onto a single path. But the stack context of main() is long gone by the time one of those gets reached. >From a terminology perspective, I consider those interrupt vectors to be entry points. You could certainly arrange things so that some assembler code appeases the hardware and then invokes a closure, but that can be tricky in practice. Interrupts do not tend to cooperate in concurrency regimes, which makes GC quite difficult in a kernel. Because of the way Coyotos is structured, I think we actually *could* GC in the kernel, but the kernel proceeds by allocating all memory to itself and then never releases it, so GC serves no purpose. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
