From owner-freebsd-hackers  Sun Nov 26 11:26:36 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id LAA26362
          for hackers-outgoing; Sun, 26 Nov 1995 11:26:36 -0800
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA26357
          for <hackers@freebsd.org>; Sun, 26 Nov 1995 11:26:32 -0800
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA15217; Sun, 26 Nov 1995 12:22:44 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199511261922.MAA15217@phaeton.artisoft.com>
Subject: Re: How long is long?
To: grog@lemis.de
Date: Sun, 26 Nov 1995 12:22:44 -0700 (MST)
Cc: terry@lambert.org, hackers@freebsd.org
In-Reply-To: <199511261252.NAA13345@allegro.lemis.de> from "Greg Lehey" at Nov 26, 95 01:52:15 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 4122      
Sender: owner-hackers@freebsd.org
Precedence: bulk

I thought Peter and I took this offline.  It was such an old post
he was responding to in the first place.


> > > Long doesn't and shouldn't mean "32 bits".
> > 
> > Maybe not.  But *something* should mean "32 bits".
> > 
> > The problem is that with a 64 bit int (which, despite your opinion of
> > DEC and grandfathering old software, is correct for the Alpha):
> > 
> > int == 64	:==	long == 64
> > short == 32	||	short == 16
> > char == 8
> > 
> > You lose access to either 32 bit or 16 bit sized types.
> > 
> > Period.
> 
> You're looking at this from the wrong perspective.  Even if you say:
> 
> > ANSI doesn't allow "long long" or "quad".
> 
> That means that ANSI is wrong.  If a language doesn't allow you to
> access to the primitive data types of your machine, then it's broken.
> In the case of C, the answer is obvious enough.  ANSI doesn't allow
> long long, but that doesn't mean you can't use it.  And how about
> short short?
> 
> I tend to agree with Peter that it's a good idea to keep data sizes
> roughly the same.  It may have been a mistake to increase an int from
> 16 to 32 bits when moving to the Vax, but that's history.  Modern
> computers have int lengths which are a power of 2, and that power lies
> between 3 and 7 in all cases.  Is it really that difficult to find 5
> different descriptions?  For example:
> 
> short short   8  bits

Uh, some of us call this one "char".  8-).

> short	      16
> int	      32
> long	      64
> long long     128
> 
> I don't think that this should be carved in stone; I'd prefer int8,
> int16 etc. for things which really *must* be that length (like data
> shared with other architectures), but it would make life a lot easier
> if people would adhere to the lengths anyway.

Let's clarify my perspective:

If there is a type that is treated as atomic (ie: it may be used as
the underlying type for off_t according to ANSI and POSIX), then the
type promotion has to promote to the largest one allowable.  The
target promoted type is, in fact, the stack alignment size.  This
only makes sense, since the stack alignment size and single cycle
bus fetch and register sizes dictate the efficiency of the fetch
process.  This is why Aztec on the Mac and Amiga 68k was correct
in setting sizeof(int) == 2 and Lattice (SAS) C was wrong in
setting sizeof(int) == 4.  An "int" is supposed to be the "natural"
type for the machine and take a single bus cycle to load.

This satisfies the ANSI C standard, which does not require prototyping
of functions, and further specifically allows me to use functions without
a prototype in scope.

Consider, specifically, "lseek".  It is [!>*BOGUS*<!] that I must have
a prototype in scope OR must explicitly promote non-quad arguments.  Both
of these actions are not required of standards conforming code.

How much of the pain-in-the-ass of porting something to FreeBSD by
programmers who don't voluntarily observe the voluntary writ of faith
of having prototypes for everything is caused by off_t?  Most of it,
I should think.

One need not be a Priest or a Nun to be Catholic.  One need not use
prototypes to produce standards conforming code, though the self
appointed Priests would have us act otherwise..

Conforming code should compile and run, even if not written by a
religious zealot.  This is the whole point of requiring off_t to
be an atomic type (which it is NOT in FreeBSD, but which we could
consider to be an alias for the atomic type "double" if we were
algning our stack correctly right now -- which we are not).

size_stack_alignment =	MAX(	sizeof(atomic_type_1),
				MAX(	sizeof(atomic_type_2),
					...
					MAX(	sizeof(atomic_type_n-1),
						sizeof(atomic_type_n)
					)
				)
			)


Even now we are screwing up.  The type "double" is atomic, and
sizeof(double) == 8.  Stack alignment should be 8 bytes.  MUST be
8 bytes for 64 bit MIPS processors without an unaligned access
exception handler, in any case, since the machine will fail to
operate otherwise.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.