From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10679 invoked by alias); 17 Dec 2001 23:01:03 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 9777 invoked from network); 17 Dec 2001 22:59:42 -0000 Received: from unknown (HELO dot.cygnus.com) (205.180.230.224) by sources.redhat.com with SMTP; 17 Dec 2001 22:59:42 -0000 Received: (from rth@localhost) by dot.cygnus.com (8.11.6/8.11.6) id fBHMxRl15733; Mon, 17 Dec 2001 14:59:27 -0800 X-Authentication-Warning: dot.cygnus.com: rth set sender to rth@redhat.com using -f Date: Mon, 17 Dec 2001 15:01:00 -0000 From: Richard Henderson To: Linus Torvalds Cc: dewar@gnat.com, gcc@gcc.gnu.org Subject: Re: Big-endian Gcc on Intel IA32 Message-ID: <20011217145927.A15728@redhat.com> Mail-Followup-To: Richard Henderson , Linus Torvalds , dewar@gnat.com, gcc@gcc.gnu.org References: <20011217211252.431D3F28BD@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from torvalds@transmeta.com on Mon, Dec 17, 2001 at 01:40:04PM -0800 X-SW-Source: 2001-12/txt/msg00951.txt.bz2 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~