Big-endian Gcc on Intel IA32

[Richard Henderson]

On Mon, Dec 17, 2001 at 01:40:04PM -0800, Linus Torvalds wrote:
> Hmm.. It sounds like one of those "obvious in principle" things, but I can
> imagine that it falls afoul of a lot of the gcc optimizations (ie x86.md
> has a pattern for doing "load + and $255" with a "movzbl" instruction,
> which is legal only on little-endian data: on big-endian you can still do
> it, but you have to modify the address).

Except that if gcc had generated a big-endian load, you'd
have "load + swap + and" in the instruction stream, which
wouldn't use movzbl.

I don't think there's anything conceptually complex about
adding this extension, just tedious.

> I actually think that it might be equally powerful to just have a way of
> "tainting" certain pointers, and disallowing their use at compile-time
> unless the recipient claims to accept the specific form of "tainting".
> This is, in fact, more-or-less what the "const" qualifier does, but it
> might be useful to allow user-defined "taints".

This runs afoul of a long-standing misfeature that a pointer to
Thing forgets about the attributes that Thing carried.  Fixing
this is desirable, but no one has stepped forward to do it.

As for the user-defined taint, implementing that should be as
simple as defining a type attribute with some string/identifier 
argument that does nothing.  Since the attribute modifies the
type, a declaration with and without should be incompatible.

Dunno how far you'd be able to go with this, given the rabid
casting to unsigned long that tends to happen in the kernel...


r~