mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michael Meissner <meissner@spectacle-pond.org>
To: Rick Hohensee <humbubba@smarty.smart.net>
Cc: Michael Meissner <meissner@spectacle-pond.org>,
	linux-kernel@vger.kernel.org
Subject: Re: Why Plan 9 C compilers don't have asm("")
Date: Thu, 5 Jul 2001 12:54:09 -0400	[thread overview]
Message-ID: <20010705125409.A21739@munchkin.spectacle-pond.org> (raw)
In-Reply-To: <20010704210227.A19675@munchkin.spectacle-pond.org> <200107050154.VAA21513@smarty.smart.net>
In-Reply-To: <200107050154.VAA21513@smarty.smart.net>; from humbubba@smarty.smart.net on Wed, Jul 04, 2001 at 09:54:05PM -0400

On Wed, Jul 04, 2001 at 09:54:05PM -0400, Rick Hohensee wrote:
> > 
> > On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote:
> > > That's with the GNU tools, without asm(), and without proper declaration
> > > of printf, as is my tendency. I don't actually return an int either, do I?
> > > LAAETTR.
> > 
> > Under ISO C rules, this is illegal, since you must have a proper prototype in
> > scope when calling variable argument functions.  In fact, I have worked on
> > several GCC ports, where the compiler uses a different calling sequence for
> > variable argument functions than it does for normal functions.  For example, on
> > the Mips, if the first argument is floating point and the number of arguments
> > is not variable, it is passed in a FP register, instead of an integer
> > register.  For variable argument functions, everything is passed in the integer
> > registers.
> > 
> 
> I didn't know that, but...
> 
> You seem to be saying the use of assumptions about args passing is
> non-standard. I know. It's more standard than GNU extensions to C though,
> C_labels_in_asms in particular, and even in your examples it appears that
> the particular function abusing these tenets will know what it can expect
> from a particular compiler, since it knows what it's arguments are. It
> can't know what it can expect from any compiler. This perhaps is where
> #ifdef comes in, or similar. Well, it's not more standard than GNU, but
> the differences would be less detailed in the case of just dealing with
> various args passing schemes, and there may be some compiler-to-compiler
> overlap, where there won't be any with stuff like C_labels_in_asms.

Doing this is a losing game.  How many different platforms does Linux currently
run on?  Do you know exactly what the ABI is for each of the machines?  What
happens when Linux is ported to a new machine?  My point is:

	extern int printf (const char *, ...);
	printf ("%d %d\n", 1, 2);

and

	extern int my_printf (const char *, int, int);
	my_printf ("%d %d\n", 1, 2);

under some ABIs will pass arguments completely differently and as I said, I
have worked on various GCC ports that did this, so it is not a theoretical
possibility.

> It's illegal to not declare main() as int. I don't know of a unix that
> actually passes anything but a byte to the calling process. I got flamed
> mightily for this in comp.unix.programmer until people ran some checks on
> thier big Real Unix(TM) boxes of various types. Linux won't pass void
> either, you have to get a 0 at least. Compliance is subjective. It's
> easier when things make sense.

Yes, that is an artifact of the original UNIX implementation on the PDP-11 (16
bit ints, signal number is passed back in one byte, and the return value in
another byte).

-- 
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

  reply	other threads:[~2001-07-05 16:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-04  3:37 Rick Hohensee
2001-07-04  3:36 ` Olivier Galibert
2001-07-04  6:24   ` Cort Dougan
2001-07-04  8:03     ` H. Peter Anvin
2001-07-04 17:22     ` Linus Torvalds
2001-07-06  8:38       ` Cort Dougan
2001-07-06 18:44         ` Linus Torvalds
2001-07-06 20:02           ` Cort Dougan
2001-07-08 21:55           ` Victor Yodaiken
2001-07-08 22:28             ` Alan Cox
2001-07-09  1:22             ` Johan Kullstam
2001-07-08 22:29           ` David S. Miller
2001-07-06 11:43       ` David S. Miller
2001-07-21 22:10       ` Richard Henderson
2001-07-22  3:43         ` Linus Torvalds
2001-07-22  3:59           ` Mike Castle
2001-07-22  6:49           ` Richard Henderson
2001-07-22  7:44             ` Linus Torvalds
2001-07-22 15:53               ` Richard Henderson
2001-07-22 19:08                 ` Linus Torvalds
2001-07-04  7:15 ` pazke
2001-07-04 17:32 ` Don't feed the trooll [offtopic] " Ben LaHaise
2001-07-05  1:02 ` Michael Meissner
2001-07-05  1:54   ` Rick Hohensee
2001-07-05 16:54     ` Michael Meissner [this message]
2001-07-04 10:10 Rick Hohensee
2001-07-05  3:26 Rick Hohensee
2001-07-06 17:24 Rick Hohensee
2001-07-06 23:54 ` David S. Miller
2001-07-07  0:16   ` H. Peter Anvin
2001-07-07  0:37   ` David S. Miller
2001-07-07  6:16 Rick Hohensee
     [not found] <mailman.994629840.17424.linux-kernel2news@redhat.com>
2001-07-09  0:08 ` Pete Zaitcev
2001-07-09  0:28   ` Victor Yodaiken
2001-07-09  3:03 Rick Hohensee
2001-07-23  4:39 Rick Hohensee

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=20010705125409.A21739@munchkin.spectacle-pond.org \
    --to=meissner@spectacle-pond.org \
    --cc=humbubba@smarty.smart.net \
    --cc=linux-kernel@vger.kernel.org \
    /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®