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

On 10 March 2010 16:57, 琬菁楊 <ching1119.cs96 at g2.nctu.edu.tw> wrote: > I think the main issue is that EFI C dialect is not ANSI-C compliant: the > size of pointer is determined at the run-time and therefore the layout of > the structure is not static. Does LLVM support this model? Hi Ching, The LLVM IR doesn't care about the size of your pointers, and this is why you have the

On Mon, Mar 15, 2010 at 10:50 AM, Renato Golin <rengolin at systemcall.org> wrote: > On 10 March 2010 16:57, 琬菁楊 <ching1119.cs96 at g2.nctu.edu.tw> wrote: >> I think the main issue is that EFI C dialect is not ANSI-C compliant: the >> size of pointer is determined at the run-time and therefore the layout of >> the structure is not static. Does LLVM support this

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

On Apr 6, 2010, at 1:10 AM, Tristan Gingold wrote: > > On Apr 3, 2010, at 2:36 PM, Russell Wallace wrote: > >> On Fri, Apr 2, 2010 at 6:17 PM, Chris Lattner <clattner at apple.com> wrote: >>> No, please don't. This is something we specifically do not want to support. The issue is not the parser, the issue is that struct field offsets are no longer constant in

Hello Chris, I have survey the efi specification and ask some question to efi engineer. Difference between EFI C and ANSI C is as following: 1. void* In EFI C, the void* is 4-byte for 32-bit processor and 8-byte for 64-bit processor. And it can appears in any where like ANSI C. So the main problem is that struct layout like struct S{ void* X; }; is not static. 2.

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

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

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 (

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

Hello Chris, Which won't matter (as long as sizeof is consistent), because EFI is a > closed system. > What is the meaning of closed system?? Is it 1. not open source 2. EBC binary is only running on a single EFI EBC interpreter and never interfacing with the outside VM?? thanks ching -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Apr 2, 2010, at 9:28 AM, 琬菁楊 wrote: > Hello Chris, > > I have survey the efi specification and ask some question to efi engineer. > Difference between EFI C and ANSI C is as following: > 1. void* > In EFI C, the void* is 4-byte for 32-bit processor and 8-byte for 64-bit processor. > And it can appears in any where like ANSI C. > So the main problem is that

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

Hi Tristan, > But it is not an error, otherwise it would be hard to use malloc() like > functions. > > I cannot understand that it would be hard to use malloc() like functions the parameter passed to malloc is evaluated at runtime what is the issue of malloc when sizeof is determined at runtime? thanks ching -------------- next part -------------- An HTML attachment was scrubbed...

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

On Mar 30, 2010, at 8:23 PM, Chris Lattner wrote: > > 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

On Fri, Apr 2, 2010 at 6:17 PM, Chris Lattner <clattner at apple.com> wrote: > No, please don't.  This is something we specifically do not want to support.  The issue is not the parser, the issue is that struct field offsets are no longer constant in this model. What about declaring that pointers are always 64 bits, for all purposes other than final code generation of actual pointer

On Apr 3, 2010, at 5:36 AM, Russell Wallace wrote: > On Fri, Apr 2, 2010 at 6:17 PM, Chris Lattner <clattner at apple.com> wrote: >> No, please don't. This is something we specifically do not want to support. The issue is not the parser, the issue is that struct field offsets are no longer constant in this model. > > What about declaring that pointers are always 64

> How does EFI describe structures if the pointer size can change? This > shouldn't be a harder problem than C struct -> llvm struct. I assume > the EFI bytecode has some way to describe them. What is it? EFI describe structures almost like C. There are EBC instructions that have two immediates: one for 32bits pointers and one for 64bits pointers.

On Apr 3, 2010, at 2:36 PM, Russell Wallace wrote: > On Fri, Apr 2, 2010 at 6:17 PM, Chris Lattner <clattner at apple.com> wrote: >> No, please don't. This is something we specifically do not want to support. The issue is not the parser, the issue is that struct field offsets are no longer constant in this model. > > What about declaring that pointers are always 64

Hi all, i am new on btrfs, i am testing KVM on btrfs (host: kernel x86-64 3.5.3), the performance is reasonable. I have two question on defrag, can someone help me? 1. According to btrfs wiki, defragment a COW file will produce two unrelated files. Does it apply to the "autodefrag" mount option? 2. Is there any command for the fragmentation status of a file/dir ? e.g. fragment