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

Hello all,

I am highly interestd in implementing C compiler for EFI Byte Code in LLVM
and participate in Google Summer Code.

EFI is a much larger, more complex,OS-like replacement for the older BIOS
firmware interface present in all IBM PC-compatible personal computers.
and the EFI specification provides for a processor-independent device driver
environment(like virtualmachine), called EFI Byte Code or EBC.

Intel(R) C Compiler for EFI Byte Code, the only one C compiler for EFI Byte
Code
(http://sx.intel.com/p-553-intel-c-compiler-for-efi-byte-code.aspx)
is not open source, and also a pay software.

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?

And I am wondering whether this kind of idea is valuable to the LLVM
community? or are there any other related ideas is more valuable?


thanks

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

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 'datalayout' explicit on the object file. I don't
know, however, if you can omit the layout definition and leave it for
run time.

If LLVM doesn't allow omitting the layout, it should, as we now have
an use case that needs it. If it does, it should be just a matter of
converting the current IR into EFI bytecode and creating intrinsics to
deal with the run-time variables. You could even benefit from having
different languages (LLVM supports) into EFI bytecode...

> And I am wondering whether this kind of idea is valuable to the LLVM
> community? or are there any other related ideas is more valuable?
I think that an open source compiler to EFI byte code is not only
desirable, but necessary.


cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

Hello Renato and all,

  I have few questions about your mail

2010/3/15 Renato Golin <rengolin at systemcall.org>
> 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 'datalayout' explicit on the object file. I
don't
> know, however, if you can omit the layout definition and leave it for
> run time.
>
As you say LLVM IR doesn't care the size of pointer, does it mean what I
only need to implement is the part that convert LLVM to EFI Byte code (just
like we regard native assembly) ??
>
> If LLVM doesn't allow omitting the layout, it should, as we now have
> an use case that needs it. If it does, it should be just a matter of
> converting the current IR into EFI bytecode and creating intrinsics to
> deal with the run-time variables. You could even benefit from having
> different languages (LLVM supports) into EFI bytecode...
>
I feel sorry about I am not vary familer with structure of LLVM that I feel
some confuse.With turely appreciation if you would explain more detail.
thanks.

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

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 model?
>
> Hi Ching,
>
> The LLVM IR doesn't care about the size of your pointers, and this is
> why you have the 'datalayout' explicit on the object file. I
don't
> know, however, if you can omit the layout definition and leave it for
> run time.
The layout for non-packed structures is, in this sense, left for
runtime.  The definition, if lacking any alignment attributes, will be
layed out in the backend according to the alignment rules then.  The
IR layout definition can be happily cross-platform if you always
access the structures in a type-safe way (using GEP, never castes,
etc).
> If LLVM doesn't allow omitting the layout, it should, as we now have
> an use case that needs it. If it does, it should be just a matter of
> converting the current IR into EFI bytecode and creating intrinsics to
> deal with the run-time variables. You could even benefit from having
> different languages (LLVM supports) into EFI bytecode...
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?
(Question is for Ching)

Andrew
>> And I am wondering whether this kind of idea is valuable to the LLVM
>> community? or are there any other related ideas is more valuable?
>
> I think that an open source compiler to EFI byte code is not only
> desirable, but necessary.
>
>
> cheers,
> --renato
>
> http://systemcall.org/
>
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>