llvm dev - Dec 2010 - [LLVMdev] Modify the LLVM front-end to support EFI C and Add LLVM to EFI Byte Code(EBC) target

Hello all,

I want to the do followings:

(1) Modify the LLVM front-end(clang) to support EFI C

(2) Add EFI Byte Code target to LLVM

I am wondering to know which task should I do first, modify front end or
porting LLVM?

thanks

yi-hong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101217/f02338e2/attachment.html>

On Thu, Dec 16, 2010 at 5:42 PM, Lu Mitnick <king19880326 at gmail.com>
wrote:
> Hello all,
>
> I want to the do followings:
>
> (1) Modify the LLVM front-end(clang) to support EFI C
>
> (2) Add EFI Byte Code target to LLVM
>
> I am wondering to know which task should I do first, modify front end or
> porting LLVM?
>
> thanks
>
> yi-hong
As long as EFI C isn't radically different from normal C, I would
suggest adding a EBC target to LLVM first. Otherwise you have no way
to test the clang modifications.

- Michael Spencer

On 12/16/10 17:42, Lu Mitnick wrote:
> Hello all,
>
> I want to the do followings:
>
> (1) Modify the LLVM front-end(clang) to support EFI C
>
> (2) Add EFI Byte Code target to LLVM
>
> I am wondering to know which task should I do first, modify front end or
> porting LLVM?
You might want to look at the challenges discussed in this thread, 
mainly that pointer size is a run-time not a compile-time value in EFI C 
and EFI Byte Code:
http://comments.gmane.org/gmane.comp.compilers.llvm.devel/30158
("Idea for Google Summer Code : C Compiler for EFI Byte Code implement 
in LLVM", starting 2010/03/10)

-Isaac

Hello Isaac and all

I have read the challenges discussed.

I summarize the issues may occurred in the followings:

Would you mind to give some advise?

1. struct layout may be not static, which means that struct field offset are
no longer constant in this model.

Such like the following example:

struct S{
    void* x;
    int e;
};

struct size(S) is 5 byte for 32-bit processor and 9 byte for 64-bit
processor, it also effect the struct field c offset.

sol.

We can use the natural indexing in EBC specification to solve this issue.

Assume BASE be the address of c in R0, then the address of c.e is content of
R0 add (0 + 1 * sizeof(void*)).

If the EFI C code is c.e = 4, the assembly generated is MOVI @R0(1, 0), 4
after compiled.

(Notation @R1 (+n, +c) means the memory which address is content of R1 add
(c + n*sizeof(void*)).

The EBC assembly above indicate move immediate value 4 to memory which
address is content of

R0 add (0 + 1*sizeof(void*)).

2. sizeof is evaluated at runtime because the pointer size (void*) is
determined at runtime.

sol.

This issue could be solved by implementing sizeof as an intrinsic, and the
code of sizeof intrinsic could be as follows:

            MOVI           R1, 0
            MOVI           R2, Label
            ADD32         R1, @R2 (1, 0)
Label:   UINT32
            UINT32   4
            UINT32   8

R1 ends up with the size of the void*.

3. void*-typed automatic variables cause dynamic activation record.

sol.

Consider a Function call of function foo() which does not have any
parameter.

Although there is only return address in the activation record (which type
is void*), the activation record

size is determined at runtime. It doesn’t know how many bytes should be
subtracted from

sp (stack pointer register). With natural indexing, we can just generate
assembly such like

SUB SP, R1, with R1= sizeof(void*) and can be calculated as above.

thanks

yi-hong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101217/aad7c78d/attachment.html>

On 17 Dec 2010, at 03:15, Michael Spencer wrote:
> As long as EFI C isn't radically different from normal C, I would
> suggest adding a EBC target to LLVM first. Otherwise you have no way
> to test the clang modifications.

As was stated in the last post on this subject, EFI C has integer types that
have a size determined at run time.  I can't see how this would be
integrated into the existing IRGen infrastructure in clang without some serious
modification, nor how you would represent these in LLVM IR.  Mapping from a
language that has variable-sized ints, to a target that has variable-sized ints,
via an intermediate representation that does not have variable-sized ints would
be tricky, I suspect.

David

-- Sent from my PDP-11