On Sat, 2007-01-13 at 19:30 +0100, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 12/01/2007 hora 09:30:
> > Since there is only one coyotos system call, there isn't much of a
> > decision to make here. The rest is a matter of stubs that will be
> > compiled by CapIDL.
>
> But then, how will a capability invocation look like? cap.method()?
>
> What about access of various registers, including those of the virtual
> registers page, and FCRBs?
I think you have a bunch of things mixed up. I suspect that this is more
a Coyotos question than a BitC question, but I will answer it here.
First, you have a layering problem. There is a layer at the trap
instruction and a separate layer at the capability invocation stub
procedure. At the trap layer there is only one system call: invoke
capability. Its arguments determine the capability that is invoked and
also the arguments and the return results.
Invocation stubs are generated by CapIDL. Stubs are language-dependent,
because they must cooperate with the language run-time system to
allocate storage.
So, to answer your questions specifically:
The virtual registers page
http://www.coyotos.org/docs/ukernel/spec.html#3.1
is simply a BitC structure in a special heap. It is not subject to
garbage collection. A reference to it is available to the stub code. It
may or may not also be available to the application globally -- this is
not decided yet for BitC applications.
An FCRB is simply an object named by a capability. Access to it occurs
by invoking capabilities in the usual way. Incoming "registers" in the
FCRB are delivered as part of the incoming message.
Finally, an invocation will *initially* look like:
method(cap, args) => result
because BitC is not an OO language. At some point we will introduce an
explicit mechanism syntactic mechanism for encapsulating v-tables, and
at that point the invocation will turn into:
cap.method(args) => result
With a little luck this will happen before we actually start generating
BitC stub code, but it's purely syntactic sugar.
shap
--
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
