llvm dev - Sep 2008 - [LLVMdev] Architecture Dependency of LLVM bitcode (was Re: compile linux kernel)

> hton and ntoh intrinsics.  These are needed to allow target code to
> deal with endianness in a target independent way.  (Ok, you could
> potentially write code that detected endiannes at runtime and chose
> multiversioned code based on that, but that is ugly and optimization
> prohibiting).
> 
Why not add types with explicit endianess? A trick I use for reading binary
files across platforms is to define the types int32, int32_le and int32_be :
int32 is platform-native, _le and _be are little and big endian,
respectively. I use and #ifdef in my types.hpp to determine which of _le and
_be is a typedef for the standard uint32, and the other is implemented as a
class with operator int32(). "add i32_be %X, 8" looks elegant to me,
and
quite easy (for someone writing the ir output to a text file, like me :) to
bolt on to existing code.

- Sherief

On Mon, 2008-09-29 at 15:03 -0400, Sherief N. Farouk
wrote:
> Why not add types with explicit endianess?...
The issues with architecture dependency are far broader than byte order.
LLVM in its current form is simply not intended to be machine neutral.
Quite the contrary: it is heavily machine dependent!

On Sep 29, 2008, at 12:21 PM, Jonathan S. Shapiro wrote:
> On Mon, 2008-09-29 at 15:03 -0400, Sherief N. Farouk wrote:
>> Why not add types with explicit endianess?...
>
> The issues with architecture dependency are far broader than byte  
> order.
> LLVM in its current form is simply not intended to be machine neutral.
> Quite the contrary: it is heavily machine dependent!
That statement is inaccurate. LLVM the language itself is machine  
neutral. The system as a whole hasn't figured out a way to represent  
target dependent information in a machine neutral way.

Evan

>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> The issues with architecture dependency are far broader than byte order.
> LLVM in its current form is simply not intended to be machine neutral.
> Quite the contrary: it is heavily machine dependent!
> 
I wasn't suggesting this to make LLVM able to compile architecture-neutral
kernels or the such. While I disagree with the machine-dependent statement,
my suggestion was just proposed in response to the following: " hton and
ntoh intrinsics.  These are needed to allow target code to deal with
endianness in a target independent way.". I just based it on how I try to
write endianness-neutral code in C++ even when dealing with endian-dependent
binary formats.

- Sherief