From: Michael Meissner <meissner@spectacle-pond.org>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Pavel Machek <pavel@suse.cz>, kernel list <linux-kernel@vger.kernel.org>
Subject: Re: i386 cleanups
Date: Wed, 18 Apr 2001 18:02:57 -0400 [thread overview]
Message-ID: <20010418180257.A17877@munchkin.spectacle-pond.org> (raw)
In-Reply-To: <20010417232614.A4377@bug.ucw.cz> <Pine.LNX.4.31.0104171443060.1029-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.31.0104171443060.1029-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Tue, Apr 17, 2001 at 02:46:09PM -0700
On Tue, Apr 17, 2001 at 02:46:09PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 17 Apr 2001, Pavel Machek wrote:
> >
> > These are tiny cleanups you might like. sizes are "logically"
> > long.
>
> No. Sizes are not "logical". They are whatever you decide they are, ie
> it's purely a complier convention.
Not purely a compiler convention, but an ABI requirement. In particular, Linux
GCC adheres to the ABI specified in the System V UNIX Intel386 (tm) Processor
Supplement, and on page 6-66, in figure 6-70, the specification for stddef.h
says that:
typedef int ptrdiff_t;
typedef unsigned int size_t;
typedef long wchar_t;
> At least earlier, size_t was defined as "unsigned int" in user mode, and
> doing anything else would make gcc complain about clashes with its
> compiled-in __builtin_size_t that it uses for the builtin prototypes (ie
> if you had a declaration for "void *memcpy(void *dest, const void *src,
> size_t n);" and your size_t didn't match the gcc builtin_size_t, you'd get
> a "redefined with different arguments" warning or something).
While, I grant that this is one area the ABI could have been improved upon
(alignment of floating point, and reservation of EBX as GOT pointers are other
sore spots), it is the ABI of record. Yes, we could certainly choose a
different ABI for Linux, but it is probably too late for that in the case of
the x86.
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: meissner@redhat.com phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482
next prev parent reply other threads:[~2001-04-18 22:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-17 21:26 Pavel Machek
2001-04-17 21:46 ` Linus Torvalds
2001-04-18 22:02 ` Michael Meissner [this message]
2001-04-17 22:57 ` Jeff Garzik
2001-04-18 9:10 ` Abramo Bagnara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010418180257.A17877@munchkin.spectacle-pond.org \
--to=meissner@spectacle-pond.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®