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

[Lu Mitnick]

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>