[coyotos-dev] [bitc-dev] Standard library and Coyotos syscals

[Jonathan S. Shapiro]

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:

  http://www.eros-os.org/pipermail/bitc-dev/2007-January/000844.html

 - shap

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...

Almost.

There are several components to a capability invocation:

  invocation block      the region of application memory that describes
                        the arguments being sent and the capability
                        being invoked.

      http://www.coyotos.org/docs/ukernel/spec.html#5.1

      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
                        string area.

      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
seriously:

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
> syntax...
> 
> 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:

(defannotation SomeAnnotation)

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.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100