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

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?

On Apr 3, 2010, at 5:36 AM, Russell Wallace wrote:
> 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?
Yep.  That would be a fine approach, and probably conformant to the spec.

-Chris

Hello Chris, Rusell
> 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?
>
> Yep.  That would be a fine approach, and probably conformant to the spec.
>
I have some question about your disscussion.
the main difference is as follows:
>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
In my opinion, the main compiling process is C --a--> LLVM IR --b--> EBC
byte code
So as you say, solve the difference 2,3,4 in process a and assumed void * be
64-bit in process a
Then solve the difference 1 in process b??

thanks

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

On Apr 3, 2010, at 2:36 PM, Russell Wallace wrote:
> 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?
No, sizeof will report wrong values.

Tristan.

On Apr 6, 2010, at 1:10 AM, Tristan Gingold wrote:
> 
> On Apr 3, 2010, at 2:36 PM, Russell Wallace wrote:
> 
>> 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?
> 
> No, sizeof will report wrong values.
Which won't matter (as long as sizeof is consistent), because EFI is a
closed system.

-Chris

Helo Tristan
> 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?
>
> No, sizeof will report wrong values.
>
Could I modify the parser to let sizeof be a function.
And use natual indexing(ie. the Natural Units) :

19.4 Natural Indexing
The natural indexing mechanism is the critical functionality that enables
EBC to be executed
unchanged on 32- or 64-bit systems. Natural indexing is used to specify the
offset of data relative
to a base address. However, rather than specifying the offset as a fixed
number of bytes, the offset
is encoded in a form that specifies the actual offset in two parts: a
constant offset, and an offset
specified as a number of natural units (where one natural unit = sizeof
(VOID *)). These two
values are used to compute the actual offset to data at runtime. When the VM
decodes an index
during execution, the resultant offset is computed based on the natural
processor size. The encoded
indexes themselves may be 16, 32, or 64 bits in size. Table 19-4 describes
the fields in a natural
index encoding.

Table 19-4. Index Encoding
Bit #          Description
N               Sign bit (sign), most significant bit
N-3..N-1    Bits assigned to natural units (w)
A..N-4       Constant units (c)
0..A-1        Natural units (n)

As shown in Table 19-4, for a given encoded index, the most significant bit
(bit N) specifies the
sign of the resultant offset after it has been calculated. The sign bit is
followed by three bits
(N-3..N-1) that are used to compute the width of the natural units field
(n). The value (w) from
this field is multiplied by the index size in bytes to determine the actual
width (A) of the natural
units field (n). Once the width of the natural units field has been
determined, then the natural units
(n) and constant units (c) can be extracted. The offset is then calculated
at runtime according to the
following equation:
Offset = (c + n * (sizeof (VOID *))) * sign

to evaluate sizeof(void*) at running time?

Maybe it can use the following code to get the sizeof(void*) at whether
32-bit and 64-bit processor:

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

And use natural indexing mechanism to solve the dynamic structure layout
problem??

thanks

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