[coyotos-dev] [bitc-dev] Standard library and Coyotos syscals
Jonathan S. Shapiro
shap at eros-os.com
Tue Jan 16 08:37:51 CST 2007
This is a continuation of a thread that started on bitc-dev. The earlier
thread of messages can be found in the archives starting at:
On Tue, 2007-01-16 at 07:18 +0100, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 15/01/2007 hora 12:15:
> > 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.
> I think I didn't realize that sender and receive block are just in the
> address space of the process, and so don't need any special instruction
> to be read or written. And IIUC, they would be allocated by the process
> itself, so it doesn't need any help from anyone to access them...
There are several components to a capability invocation:
invocation block the region of application memory that describes
the arguments being sent and the capability
No reference to this area is retained at the end of the trap.
This block CAN come from GC'able memory, but typically is
fabricated on the caller stack.
receive block The region of application memory that describes
where a long incoming message should go. This
may include pointers to an extended receive
This region is referenced from the FCRB. It is therefore always
"live" for GC purposes, and its virtual address must not change.
The receive string region pointed to from here, if any, should
be viewed as "hazarded by DMA". It can be subject to GC, but it
cannot be relocated until the associated FCRB is destroyed.
FCRB an in-kernel object that designates (among
other things) a pair (process, receive-block).
> > The virtual registers page [...] is simply a BitC structure in a
> > special heap. It is not subject to garbage collection.
> Why not subject to GC?
Well for starters: if you lose it you'll never run again, but more
The UPCB is not just a part of the heap. It lives in a dedicated page
that is known to the kernel. It is best thought of as a single-page
memory object that has been mapped into your address space. The
application is free to relocate where this page appears in its address
space, but the address must be page aligned. Further, the address is
stored in thread-local storage for use by the low-level run time. If the
page is moved, some care needs to be taken to make sure that the TLS
pointer to it is up to date at all time.
> > Finally, an invocation will *initially* look like:
> > method(cap, args) => result
> > because BitC is not an OO language.
> Well, now that I'm a Lisp zealot, I won't be bothered by such a
> BTW, is it still planned to switch to a less lispy syntax or the current
> syntax will finally remain?
I am oscillating. I was all set to make the switch, but then we realized
that it is very useful to have a layer of abstraction where a program
can be "well-formed" without being a valid program. This in the same
sense that an XML document can be well-formed XML (i.e. properly
bracketed) without being valid (i.e. conforms to some DTD).
In particular, it is really useful to be able to say:
and then write:
(SomeAnnotation ....stuff the compiler will ignore as long as it
is valid tokens that are properly parenthesized...)
This would give us a very convenient way to play with various kinds of
language extensions for non-compiler tools.
Jonathan S. Shapiro, Ph.D.
The EROS Group, LLC
+1 443 927 1719 x5100
More information about the coyotos-dev