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 ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of mindmachine at free.fr [mindmachine at free.fr] Sent: 17 December 2013 14:03 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] an OS around LLVM 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 _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
We (PNaCl team) are in the process of removing older documentation, this is probably more accurate: https://developers.google.com/native-client/dev/ On Tue, Dec 17, 2013 at 6:50 AM, Sam Parker <S.Parker3 at lboro.ac.uk> wrote:> Check out PNaCL > http://www.chromium.org/nativeclient/pnacl > > Cheers, > Sam > > Sam Parker > Research Student > Electronic Systems Design Group > Loughborough University > UK > > ________________________________________ > From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of mindmachine at free.fr [mindmachine at free.fr] > Sent: 17 December 2013 14:03 > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] an OS around LLVM > > 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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.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.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
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
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. On 12/30/13 12:00 PM, John Criswell wrote:> 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 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 > >