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

[琬菁楊]

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
4
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
>

thanks

ching
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100331/fa8486c3/attachment.html>