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

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. no floating support in EFI C
3. no C++ support in EFI C
4. no assembly support in EFI C, all assembly must convert to C

I am wondering that does LLVM support model which structure layout is
determined at run time??
If not, do I need to modify the parser in clang to support this feature??

thanks

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

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 struct layout like
>     struct S{
>         void* X;
>     };
>     is not static.
> 2. no floating support in EFI C
> 3. no C++ support in EFI C
> 4. no assembly support in EFI C, all assembly must convert to C
Ok, all of this is easy except #1.
> I am wondering that does LLVM support model which structure layout is
determined at run time??
No.
> If not, do I need to modify the parser in clang to support this feature??
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.

-Chris

Hello Chris
> If not, do I need to modify the parser in clang to support this feature??
>
> 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.
>
Does that struct field offsets are no longer constant would crash the
following optimization in LLVM??

thanks

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

On Apr 2, 2010, at 10:17 AMPDT, Chris Lattner 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 struct layout like
>>    struct S{
>>        void* X;
>>    };
>>    is not static.
> 
>> If not, do I need to modify the parser in clang to support this
feature??
> 
> 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.
LLVM may not be a good match for this project, but there's prior art
elsewhere; have a look at ANDF.

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
instructions? Would that solve the problem?

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. no floating support in EFI C
> > 3. no C++ support in EFI C
> > 4. no assembly support in EFI C, all assembly must convert to C
>
> Ok, all of this is easy except #1.
>
> > I am wondering that does LLVM support model which structure layout is
> determined at run time??
>
> No.
>
> > If not, do I need to modify the parser in clang to support this
feature??
>
> 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.
>
I have read the EFI specification v1.10 and find the natural indexing about
solving the dynamic structure layout problem:

19.4.4 Natural Units
Natural units are used when a structure has fields that can vary with the
architecture of the
processor. Fields that precipitate the use of natural units include pointers
and EFI INTN and
UINTN data types. The size of one pointer or INTN/UINTN equals one natural
unit. The natural
units field in an index encoding is a count of the number of natural fields
whose sizes (in bytes)
must be added to determine a field offset.
As an example, assume that a given EBC instruction specifies a 16-bit index
of 0xA048. This
breaks down into:
• Sign bit (bit 15) = 1 (negative offset)
• Bits assigned to natural units (w, bits 14-12) = 2. Multiply by index size
in bytes = 2 x 2 = 4 (A)
• c = bits 11-4 = 4
• n = bits 3-0 = 8
On a 32-bit machine, the offset is then calculated to be:
• Offset = (4 + 8 * 4) * -1 = -36
On a 64-bit machine, the offset is calculated to be:
• Offset = (4 + 8 * 8) * -1 = -68

By this indexing model, the dynamic struture layout problem seems to be
solved by the underlying EBC vm.
Although the data field is at different address between 32-bit and 64-bit
processor.
Both can use the same encoding.

Does it means that the issue 1 can be solved??

thanks

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