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

=?Big5?B?2nu117eo?= ching1119.cs96 at g2.nctu.edu.tw
Tue Mar 30 12:31:32 CDT 2010

2010/3/20 Louis Gerbarg <lgerbarg at gmail.com>

> 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); ?
I have surveyed the UEFI spec2.3.
In my opinion, if the EBC VM is running on 32-bit processor, return value is
if the EBC VM is running on 64-bit processor, return value is 8

If error out on any sizeof that include a pointer, does it means that no
issue about pointer size determined at runtime??

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.cs.uiuc.edu/pipermail/llvmdev/attachments/20100331/fa8486c3/attachment.html 

More information about the LLVMdev mailing list