[LLVMdev] an OS around LLVM

John Criswell criswell at illinois.edu
Tue Dec 31 13:23:32 PST 2013


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




More information about the llvm-dev mailing list