llvm dev - Mar 2010 - [LLVMdev] Idea for Google Summer Code : C Compiler for EFI Byte Code implement in LLVM

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>

On Mar 19, 2010, at 2:40 PM, Louis Gerbarg wrote:
> 
> 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.
Ok, that makes sense.  It could be done by generalizing the notions of variably
modified types (which are VLAs in C99) to include pointers.
> 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>.
PNaCL is already (planned to be) built with LLVM/Clang.  They just fix the
pointer size at 32-bits, which also simplifies their SFI approach on 64-bit
hosts.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100319/504baa6e/attachment.html>

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>

On Mar 30, 2010, at 10:31 AM, 琬菁楊 wrote:
> 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??
Yes, if it is an error, it makes it much more feasible to implement.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100330/0b192afa/attachment.html>

Hello, Chris


> 2010/3/20 Chris Lattner <clattner at apple.com>
>
>
>> On Mar 19, 2010, at 2:40 PM, Louis Gerbarg wrote:
>>
>>
>>> 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.
>>
>>
>> Ok, that makes sense.  It could be done by generalizing the notions of
>> variably modified types (which are VLAs in C99) to include pointers.
>>
>
I have read the sizeof and VLA in C99
I found a example:
EXAMPLE 3 In this example, the size of a variable-length array is computed
and returned from a function:
#include <stddef.h>
size_t fsize3(int n)
{
  char b[n+3]; // variable length array
  return sizeof b; // execution time sizeof
}
int main()
{
  size_t size;
  size = fsize3(10); // fsize3 returns 13
  return 0;
}
And I found some information with clang about VLA
(http://clang.llvm.org/cxx_compatibility.html#vla)
Does llvm/clang doesn't support sizeof is evaluated at run time??

thanks

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

On Apr 1, 2010, at 1:27 PM, 琬菁楊 wrote:
> int main()
> {
>   size_t size;
>   size = fsize3(10); // fsize3 returns 13
>   return 0;
> }
> And I found some information with clang about VLA
> (http://clang.llvm.org/cxx_compatibility.html#vla)
> Does llvm/clang doesn't support sizeof is evaluated at run time??
Yes, clang supports vlas as defined in C99 and sizeof can return a dynamic
value.   C99 vlas cannot occur in structs though, and clang does not support
them in structs.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100401/efd61586/attachment.html>