[LLVMdev] an OS around LLVM

mindmachine at free.fr mindmachine at free.fr
Sun Jan 26 09:04:10 CST 2014

Thanks a lot for this information, that helps! I'll have a close look at SVA.

Currently, I plan to use asm.js as portable low-level language, but that might
change in the future. I made this choice after reading:


By the way, my project is no longer an OS. It's now a desktop environment. The
new address of my project is:


Again, thanks for replying.



Selon John Criswell <criswell at illinois.edu>:

> On 12/17/13 8:03 AM, mindmachine at free.fr wrote:
> > Hi all,
> >
> >
> > If it's not the right place to ask, please forgive me.
> >
> > Currently I'm working on a new operating system concept, called "Om".
> >
> > The first feature would be Android-like apps, coming in *.opk files that
> would
> > contain all needed resources and source-code expressed in LLVM-IR assembly
> > language.
> >
> > http://sett.com/openminded-os/uid/88508
> >
> > How does it sound ?
> I've seen several suggestions made on this thread on topics related to
> what you want to do.  To be honest, I don't really have a good idea what
> your goal is, and I didn't have sufficient patience to wade through your
> blog to find out.  As a suggestion for the future, you should describe
> your goal or goals more specifically in the email to the list.
> What you need really depends on what your goals are.  If you want some
> sort of language in which application code is represented so that it is
> portable across difference architectures, then I think LLVM would be a
> good choice.  That said, there are several issues that LLVM doesn't deal
> with that you would need to address.  The biggest one is
> architecture-specific details that are exposed in source-languages like
> C/C++ and are often encoded in the TargetData information within an LLVM
> IR bitcode file.  Examples include pointer size, endianness, memory
> alignment requirements, etc.  Note also that you'll have to deal with
> how these details are exposed at the source language level.  Languages
> like C make these details visible, so the programmer can write
> non-portable code.  Languages like Java can keep these details hidden,
> allowing Java programs to be much more portable.
> I believe the PNaCL work addresses some of these issues.
> If you want *everything,* include the OS kernel, to be represented in
> LLVM IR, then you should take a look at the LLVA/SVA work.  In that
> work, we removed the inline assembly code in the OS and replaced it with
> high-level instructions that we (logically) added to the LLVM
> instruction set.  It still isn't portable in the way that PNaCL is, but
> it could probably be extended to do so.  You can find the SVA
> publications at http://sva.cs.illinois.edu/pubs.
> As an aside, my (admittedly biased) opinion is that SVA is a very good
> platform for doing novel things with operating systems and compilers.
> We've used it to protect Linux and FreeBSD from memory safety errors
> using SAFECode-like techniques and simpler control-flow integrity
> approaches, and we'll have a paper out in March on using it to protect
> applications from compromised operating system kernels.  We haven't
> open-sourced the code yet, but if you're up for some low-level coding,
> you can write a new implementation of the instructions.
> Finally, regarding TCG, I'm not sure that TCG will be that much better a
> fit than LLVM IR.  TCG doesn't have pointer sizes the way LLVM does, but
> all of your loads and stores will still have a size argument (8, 16, 32,
> 64 bits).  It is not clear to me that a TCG program can be converted
> from working with 32-bit pointers to 64-bit pointers automatically.
> Also, I think LLVM provides many more optimizations than TCG and makes
> writing optimizations and code transformations easier.
> Hope some of this helps,
> -- John T.
> >
> >
> > Julien
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the LLVMdev mailing list