Eliminating runtime checks before memory operations and the need for GC is a potentially significant boost in performance, even if only for a subset of programs ("embedded C programs" in the paper).

Since, you want bitc to be useful in as many domains as possible (hopefully displacing C for low-level programming), and given a stated goal of Coyotos to scale up as well as down, it seems clear that the static analysis outlined in the paper would be of significant interest.

Furthermore, given the relative simplicity of components in a microkernel system, I would imagine they could be designed in such a way as to take full advantage of the analytical techniques.

From the paper:

"The key result of this paper is a compiler technique that ensures memory safety of dynamically allocated memory without programmer annotations, runtime checks, or garbage collection, and works for a large subclass of type-safe C programs."

How could that not be applicable to bitc? Am I missing something fundamental here that mitigates the usefulness of the above?

Sandro

On April 16, 2005 08:29 am, Jonathan S. Shapiro wrote:

> Sandro:

>

> Can you say why you believe that this is relevant for low-level systems

> languages and/or bitc?

>

> shap

>

> On Thu, 2005-04-14 at 13:19 -0400, Sandro Magi wrote:

> > Recently came across LLVM (http://llvm.cs.uiuc.edu/), and was pretty

> > impressed. I found an interesting paper of theirs and thought I'd share

> > in case some people haven't seen it. Looks like these techniques would

> > be very applicable to bitc as a low-level systems language.

> >

> > Memory Safety Without Runtime Checks or Garbage Collection:

> > http://llvm.cs.uiuc.edu/pubs/2003-05-05-LCTES03-CodeSafety.html

--

Active Club: Having Fun On The Quest For Truth

http://activeclub.homeip.net

My public key:

http://naasking.homeip.net/about/pub_key.txt

Attachment: pgp8JI4GxK6kI.pgp
Description: PGP signature

_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to