This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc


Hello.  I'm actually an EFI engineer so this project is of great
interest to me.  I would be willing to lend a hand off hours if this
goes through, so please keep me in the loop.

I think the biggest hurdle would be the c front end since EBC (EFI
byte code) introduces variable sized pointers as well as a (u)intn
(natural sized integer).  The idea was you could have an addin card
with an option rom compiled with EBC that would work in any system
using EFI.  From my limited experience with the Intel EBC compiler
they just changed sizeof to a function.  For instance using iec the
following could fail to compile:

int array_mask[sizeof(my_array)/sizeof(array_entry)];

If array_entry had a pointer or natural sized integer the compiler
would complain and exit.  I did a little research to see if I could
just change sizeof to a function for gcc but found it would break
quite a few things, and even more optimizations (although it's
interpreted so optimization is not a priority).  I'm no gcc guru but
it seemed like quite a bit of work to the front end to deal with it.

The other hurdle would be the ABI.  It's very particular since it has
to accommodate calling into and from EBC, x86, x86_64, ia64, and any
other architecture available.  It's structured mainly on Microsoft's
stdcall ABI.

EBC's instruction set is fairly simple so I don't think it would be
very hard to create another target for gas.

There is an open source interpreter available from the EDK.  I'm not
100% sure if you can use it in the emulated environment, but there are
quite a few platforms to work on.



2010/3/4  <b95705030@ntu.edu.tw>:
> åè Andrew Haley <aph@redhat.com>:
>
>> There is no reason in principle this shouldn't be part of gcc.
>>
>> I think no-one has responded yet because they don't know what it would
>> be for, and how much work it would involve.
>
> What compiler doing is: c -> intermediate language -> asm(ex. x86).
> And then, c compiler for efi byte code is: c -> intermediate language -> efi
> byte code.
> For the c -> intermediate language part, I hope to use original Âsource code
> of gcc,so the main point of the project is implementing intermediate
> language -> efi byte code part
>
> In my opinion,the project has some how similarity with compiling c language
> to java byte code. And in fact,it has been done by some open source
> project(ex. egcs-jvm[http://sourceforge.net/projects/egcs-jvm/]). ÂI am
> wondering to know that trace some existing c to java byte code project would
> give direction to implement this project or not.
>
>> Is there an EFI interpreter that is free software?
>
> EFI,the
> specification[http://download.intel.com/technology/efi/docs/EFI_1-10_Update.zip]
> which is a replacement for the older BIOS that defines EBC virtual machine.
> So BIOS in the future will contain this Âpart. In additional some present
> BIOS (ex.BIOS of MAC, BIOS of virtualbox) has already support EFI.
>
>> Is this in any way related to plans for a free BIOS?
>
> YES, coreboot[http://www.coreboot.org/Welcome_to_coreboot]and
> gnufi[http://www.gnu.org/software/gnufi/]
>
>> Who would maintain this EFI back-end?
>
> The EFI specification was originally developed by Intel, and is now managed
> by the Unified EFI Forum[http://www.uefi.org/home/].
>
>> ... etc.
>>
>> Andrew.
>>
>
>
> thanks
>
> yi-hong
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]