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 ?
Julien
Check out PNaCL
http://www.chromium.org/nativeclient/pnacl
Cheers,
Sam
Sam Parker
Research Student
Electronic Systems Design Group
Loughborough University
UK
We (PNaCl team) are in the process of removing older documentation,
this is probably more accurate:
https://developers.google.com/native-client/dev/
Thanks, I hadn't heard about PNaCl, it's very interesting.
I'm currently swimming in http://llvm.org/docs/ trying to learn more about
LLVM-IR...
Selon JF Bastien <jfb@google.com>:
[...]
Thanks, I hadn't heard about PNaCl, it's very interesting.
I'm currently swimming in http://llvm.org/docs/ trying to learn more about
LLVM-IR...
You might also want to go look at this:
http://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format
...which was a pre-LLVM attempt to produce platform-independent binaries
which got translated into native code at install time. The spec was
kinda weird, though.
Also, in a previous life I worked on an operating system known as
intent/Elate, which was a successor to Taos, which was an operating
system entirely based around platform-independent binaries (it could run
on multiprocessor systems where each processor was a different
architecture, for example). Turns out that people don't actually want to
do that, which is why the company went bust and I now work on something
else...
You might get some benefit from looking at this document: https://github.com/archfrog/llvm-doc/blob/master/MappingHighLevelConstructsToLLVMIR.rst. It is planned to be moved into the LLVM docs soon.
– Mikael
You might wish to read this thread as well, for some backround on LLVM IR.
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html
Summary:
LLVM IR is target specific, not portable between different targets.
LLVM IR is actually a Compiler IR and not a virtual machine language.
You might wish to read this thread as well, for some backround on LLVM IR.
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.htmlSummary:
LLVM IR is target specific, not portable between different targets.
LLVM IR is actually a Compiler IR and not a virtual machine language.
After reading all this, I understand better now. LLVM IR is not what I need for
my OS concept Om. "TCG ops" might be closer to my needs :
http://wiki.qemu.org/Documentation/TCG
I have to dig this.
Thanks a lot everyone, this was very pleasant and interesting.
Julien
You also might want to check out LLVA and its successor SVA, which do sort of what you want.
micah
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.
Just a note that the link to the SVA publications page was incorrect.
The correct link is http://sva.cs.illinois.edu/pubs.html.
-- John T.
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:
http://ejohn.org/blog/asmjs-javascript-compile-target/
By the way, my project is no longer an OS. It's now a desktop environment. The
new address of my project is:
http://code.google.com/p/omenvironment/
Again, thanks for replying.
Cheers,
Julien
Selon John Criswell <criswell@illinois.edu>: