2010/3/20 Louis Gerbarg <span dir="ltr"><<a href="mailto:lgerbarg@gmail.com">lgerbarg@gmail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On Fri, Mar 19, 2010 at 3:47 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br></div></div><div class="gmail_quote">
<div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;"><div><div></div><div><br><div><div>On Mar 19, 2010, at 11:08 AM, Ú{µ×·¨ wrote:</div><br><blockquote type="cite"><br><div class="gmail_quote">Hello Tristan and all,<br><br>I have already know that if I want to do this feature(c -> EFI Byte code) for GCC<br>

I should further modify the GCC front end(parser) to solve the problem (the size <br>
of pointer is determined at run time).<br>
<br>I have read a powerpoint about LLVM (<a href="http://llvm.org/pubs/2008-10-04-ACAT-LLVM-Intro.pdf" target="_blank">http://llvm.org/pubs/2008-10-04-ACAT-LLVM-Intro.pdf</a>)<br>It is the LLVM-GCC design graph (<a href="http://www.im.ntu.edu.tw/%7Eb95030/llvm_gcc.png" target="_blank">http://www.im.ntu.edu.tw/~b95030/llvm_gcc.png</a>).<br>



According to the above discussion , LLVM IR doesn't care about the size of pointers.<br>I am wondering how could LLVM support dynamic pointer size model without modifying <br>GCC front end??<br></div></blockquote></div>

<br></div></div><div>What do you mean by "variable sized pointers"?  What does:</div><div><br></div><div>struct  S {void *X; };</div><div><br></div><div>return for sizeof(struct S); ?</div></div></blockquote></div>
</div></div></blockquote><div><br>I have surveyed the UEFI spec2.3.<br>In my opinion, if the EBC VM is running on 32-bit processor, return value is 4<br>if the EBC VM is running on 64-bit processor, return value is 8<br><br>
If error out on any sizeof that include a pointer, does it means that no issue about pointer size determined at runtime??<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div><div class="h5"><div> 
<br></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div><div class="h5"><div>
</div></div></div><div>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.</div>

<div><br></div><div>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 <<a href="http://blog.chromium.org/2010/03/native-client-and-web-portability.html" target="_blank">http://blog.chromium.org/2010/03/native-client-and-web-portability.html</a>>.</div>

<div><br></div><font color="#888888"><div>Louis</div></font></div>
</blockquote></div><br>thanks<br><br>ching<br>