Re: P-Code vs TIL

Hi All,

I think this discussion seems to be going off at a tangent from the original
problem :-)

> > For the weight of a FORTH interpreter I'd rather see a way of
> > dynamically linking new object code into the kernel. You could then
> > specify a dynamically (or staticly) linked kernel kernel function
> > as the hander routine for a given interrupt. This would be a
> > reasonably general mechanism for kernel extensibility, but still
> > kind of expensive for a small microkernel. P-code seems the
> > way to go for the moment.

Unless I misunderstood the problem we weren't looking for kernel
extensibility (I just hack in a few more syscalls if I want to do that :-)),
simply a way of turning off an interrupt flag so that the kernel can get on
and pass a message to the appropriate server. I guess there's a possible
objection that we might want to do something quickly, but the current rs232
server actually stands up quite well and it's dealing with an awful lot of
M_ISRs. One of the bits of kernel code I've done over the last month or so
gets the RT and BG priority queues running so we can just stick speed
critical threads into the RT queue instead though and thus get the M_ISRs
delivered more quickly.

> Indeed, what we need here is a dynamic loader for kernel code.
> But the problem of having P-code, threaded code, or assembly is orthogonal
> to it, and orthogonal to having C, FORTH, or anything else as a source
> language. The compiler is outside the kernel. And once the compiler worked,
> it's easiest to use assembly or threaded code than P-code.
> The p-code interpreter for CAML-light itself is more than 10 KB !

At a guess the sort of P-code interpretter Andy described would be somewhat
nearer to a few hundred bytes. The idea of having to either have a linker
in the kernel or having to do mode switches in and out of kernel space to
call a user-registered function (that may or may-not find an interrupt is
really for it) doesn't particularly appeal to me.

This discussion about P-code has brought me to something I've been pondering
for a few months now though - writing something like a P-code server. Once
the 68k port is running I'd quite like to play with some ideas on CPU
independent code. VSTa's servers would allow large chunks of native code to
be handled efficiently, just leaving perhaps application logic in a highly
transportable format. I'd envisage that messaging would be handled as a
"low-level" operation in such a development. Anyway it's just an idea and I
don't know how much of it's been tried before (anyone know if this has been
done on Mach at all?)

                        Regards,
                        Dave
Received on Sun Nov 13 12:45:33 1994