[LLVMdev] Idea for Google Summer Code : C Compiler for EFI Byte Code implement in LLVM

[Louis Gerbarg]

On Fri, Mar 19, 2010 at 3:47 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Mar 19, 2010, at 11:08 AM, 琬菁楊 wrote:
>
>
> Hello Tristan and all,
>
> I have already know that if I want to do this feature(c -> EFI Byte code)
> for GCC
> I should further modify the GCC front end(parser) to solve the problem (the
> size
> of pointer is determined at run time).
>
> I have read a powerpoint about LLVM (
> http://llvm.org/pubs/2008-10-04-ACAT-LLVM-Intro.pdf)
> It is the LLVM-GCC design graph (
> http://www.im.ntu.edu.tw/~b95030/llvm_gcc.png<http://www.im.ntu.edu.tw/%7Eb95030/llvm_gcc.png>
> ).
> According to the above discussion , LLVM IR doesn't care about the size of
> pointers.
> I am wondering how could LLVM support dynamic pointer size model without
> modifying
> GCC front end??
>
>
> What do you mean by "variable sized pointers"?  What does:
>
> struct  S {void *X; };
>
> return for sizeof(struct S); ?
>

It doesn't, at least not for Intel's EBC compiler. They error out on any
sizeof that include a pointer.  A piece of EBC code can run in either a 32
bit or 64 bit environment, and everything in the compiler either needs to
cope with it (by conditionally choosing the size of offsets into structs,
for instance) or give up on it and abort. That also means that you cannot
compile code that depends on knowing pointer sizes in the preprocessor, etc.

I suspect getting something like this to work would require substantial
changes to any existing C frontend, since as a language assumes knowledge of
pointer size. On the other hand, it would allow for some neat tricks since
it would allow one to compile a significant subset of C code to a pointer
neutral intermediary form. Off the top of my head I can think of several
potential uses for that, such as PNaCl <
http://blog.chromium.org/2010/03/native-client-and-web-portability.html>.

Louis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100319/3227ee09/attachment.html>