Index Home About Blog
Subject: Re: long longs in c
From: mash@mash.engr.sgi.com (John R. Mashey) 
Date: Aug 16 1995
Newsgroups: comp.lang.c

In article <40g7uj$c74@hpuerci.atl.hp.com>, swm@atl.hp.com (Sandy Morton) writes:
|> Organization: Hewlett-Packard Company, Technology Solutions Lab
|> 
|> In article <danpop.808147613@rscernix>, Dan.Pop@mail.cern.ch (Dan Pop) writes:
|> |> long long is not a C feature.  Compiler specific questions belong to
|> |> system specific newsgroups, in this case comp.sys.hp.hpux.
|> 
|> Okay.  I'm not arguing with you and I plan to post my problem there as well.
|> But ... are you sure about long longs not being a C feature?  I was under
|> the impression they were being added to the ansi standard (thus the reason
|> HP is implementing them).  They are still very new, and until HP's 10.0
...


1) long longs are not part of ANSI C ... but probably will be, since:

2) They are implemented by many vendors.  3 years ago, there was an informal
working group that included many vendors, (addressing 64-bit C progrmaming
models for machines that also had 32-bit models),
and the general consensus was
that as much as we despised the syntax, it was:
        a) Already in CONVEX & Amdahl, at least
        b) Already in Gnu C
        c) And various other hardware vendors either already had it in
           or were planning to.
Somebody in this group was also on ANSI C committee, and observed that
fact of long long not being in ANSI C was no reason not to agree on doing it,
since standards generally codify existing practice, rather than inventing
new things, when reasonably possible.

3) On SGI, printf long long    uses    %lld.  I don't know what others do.


-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090    FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311


Subject: Re: long longs in c
From: mash@mash.engr.sgi.com (John R. Mashey) 
Date: Aug 17 1995
Newsgroups: comp.lang.c,comp.std.c

In article <danpop.808659017@rscernix>, Dan.Pop@mail.cern.ch (Dan Pop) writes:
|> 
|> In <40tdmr$j8k@murrow.corp.sgi.com> mash@mash.engr.sgi.com (John R. Mashey) writes:
|> 
|> >1) long longs are not part of ANSI C ... but probably will be, since:

(lots of people have implemented it, if not previously, as instigated
by 64-bit working group in 1992). 


|> Well, you'd better have a look at comp.std.c.  None of the committee
|> people posting there seems to be favouring the addition of long long
|> in C9X.  They're considering other schemes.  long long seems to be
|> doomed to be a vendor extension.


I believe this conclusion to be unwarranted ....
        a) Some features are random extensions by individual vendors.
        b) Some extensions get widely implemented in advance of the
           standard, because they solve some problem that cannot wait
           until the next standard ... after all, standards have no
           business changing overnight.
        c) Standards committees may well need to sometimes invent new
           things [like, when volatile was added years ago].
        d) However, if an extension is widely implemented, it is incumbent
           on an open standards committee to give that extension serious
           consideration ...  because otherwise, there is a strong
           tendency for the defacto standards to evolve away from the
           dejure standard... which is probably not a good idea.
        e) Again, as I said before, the 1-2 members of the 1992 group were also
           in the ANSI C group ... were where I got the opinion above from,
           i.e., don't let the non-existence of long long in the standard
           stop you from making progress - it is better to do something
           consistent.

IF long long has definitively been ruled out (as opposed to being disliked by
a few committee members), it would be interesting to hear more... as it
seems inconsistent with past behavior, which has at least sometimes
ratified existing practices that were less than elegant... and was
appropriate in doing so.
        
-- 
-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090    FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

Subject: Re: long longs in c
From: mash@mash.engr.sgi.com (John R. Mashey) 
Date: Aug 21 1995
Newsgroups: comp.lang.c,comp.std.c

In article <412dkr$7dm@newsbf02.news.aol.com>, ffarance@aol.com
(FFarance) writes:

|> > |> In <40tdmr$j8k@murrow.corp.sgi.com> mash@mash.engr.sgi.com (John R.
|> Mashey) writes:
|> >|> 
|> > |> >1) long longs are not part of ANSI C ... but probably will be,
|> since:
|> > (lots of people have implemented it, if not previously, as instigated
|> > by 64-bit working group in 1992). 
|> 
|> The "long long" type is unlikely to be included in C9X.  Although the
|> problem has been discussed in the EIR (extended integer range) working
|> group of NCEG (numeric C extensions group -- X3J11.1) for several years,
|> over the past two years is has been recognized as a faulty solution.

It is informative to hear that this has been recognized over the last two
years as faulty ... but there is a *serious* problem here...

SO, WHEN DO WE GET A NON-FAULTY SOLUTION?
        I.e., there are proposals.  When does one get accepted *enough* that
        vendors dare go implement it and expect it will actually persist
        (or close enough) in the final standard?  (For example, years ago,
        "volatile" was clearly known to be coming soon enough (1985/1986)
        to save those of us worried about serious optimization, even though
        the standard didn't get approved until later.)
=========
I'd like to go through some background, facts, and then a few opinions, to
observe that in the effort to get a "perfect" solution, we are now in the
awkward position of lacking a seriously-necessary feature / direction
in the standard, with the usual result: individual vendors go implement
extensions, not necessarily compatible.  This particular one is *very*
frustrating, since it is not rocket science, but rather predictable.
Note: none of this is meant to be criticism of people involved in the
standards process, which is inherently a frustrating, and often thankless
task.  It is meant as a plea to balance perfectionism versus pragmatism,
of which both are needed to make progress.  It is also a plea that people
involved in this *must* have a good feel for likely hardware progress,
especially for a language like C that has always been meant to make
reasonably efficient use of hardware.  While I have no special love for
"long long", especially its syntax, and while there are plenty of
issues that need to be dealt with, and while I hardly believe C's type
system is perfect ... 

I believe that we have a *serious* problem in 1995, to *not* have multiple
implementations of compilers accepting a 64-bit integer data type, such that
it was already well-lined up to become part of the standard.
The situation we are in, is like where we would have been ~1978, had we
not already had "long" in the language for several years.  That is:

        a) PDP-11 UNIX would have been really ugly in the area of file
	   pointers, since int hadn't been big enough for a long time,
	   that is, the 16-bit systems needed first-class 32-bit data,
	   regardless of anything else.  Structs with 2 ints really
	   wouldn't have been very pleasant.  Likewise, limiting files
	   to 64KB wasn't either. 
        b) Preparing cross-compilers and tools for 32-bit systems would have
           been more painful, that is, it was good to have first-class data
           on the 16-bit system to prepare the tools, and when done, to get
           code that made sense on both 16- and 32-bit systems.
        c) It would have been far more difficult to maintain portability
           and interoperability between 16- and 32-bit systems, that is,
           one could both write portable code if one was careful, and
           especially, one *could* provide structs for external data that
           looked the same, since both 16- and 32-bit systems could
           describe 8-, 16-, and 32-bit data.
Of course, this was in the days before people had converted as much code to
using typedefs, which made it pretty painful.

Deja vu...  in 1995:
        a) There is a great desire by many to have a UNIX API for 64-bit
           files on 32-bit systems (called the Large File Summit), since
           2GB file limits are behind the power curve of disks these days. This
           is no problem on 64-bit systems, and it's not really too unclean
           on 32-bit systems (if you've added a a first-class 64-bit type
           and can typedef onto it.  Yes, some older code breaks ... but
           well-typedefed code is OK.) Some people implemented this in 1994.
        b) Every major RISC microprocessor family used in systems
	   either already has a 64-bit version on the market [1992:
	   MIPS & DEC], or has one coming soon [1995: Sun UltraSPARC,
	   IBM/Moto PPC620, 1996: HP PA-8000].  Hence, some people have
	   already done compilers that have to run on 32-bit machines,
	   to produce code for 64-bit machines ...  just like running
	   PDP-11 compilers to produce VAX code.
        c) Right now, without a 64-bit integer datatype usable in 32-bit C,
           there is the same awkwardness we would have had, had we not had
           long back in the 16->32 days.

(But what about 128-bits: I'd be pleased to have a 128-bit type as well
...  however, a pragmatic view says: we have the 64-bit problem right
now, we've had it for several years; we won't have the 128-bit problem
for quite a few years.  Based on the typical 2 bits every 3 years
increase in addressing, a gross estimate is: 32 bits/2 bits * 3 years =
48 years, or 1992+48 = 2040.  Personally, I'm aggressive, so might say
year 2020 for wanting 128-bit computers ... but on the other hand,
there are some fairly serious penalties for building 128-bit wide
integer datapaths, and there are some other impediments to making the
64->128-bit transition as smooth as the 32->64 one; In any case, I will
be very surprised to see any widespread use, in general-purpose
systems, of 128-bit-wide integer datapaths, in 10 years (2005).  I
wouldn't be surprised to see 128-bit floating-point in some micros, but
128-bit integers would indeed surprise me.  Hence, I'd much rather have
a simple solution for 64-bit right now.  Of course, a plan that allows
something sensible for the bigger integers over time is goodness.

BACKGROUND
If 64-bit microprocessors are unfamiliar, consider reading:
John R. Mashey, "64-bit Computing", BYTE, Sept 1991, 135-142.  This explained
what 64-bit micros were, the hardware trends leading to this, and that
there would be widespread use of them by 1995 (there is).  While a little
old, most of what I said there still seems OK.

SOME FACTS
1) Vector supercomputers have been 64-bit systems for years. One may argue
that these are low-volume, and for several reasons (word-addressing on
CRAYs, non-existence of 32-bit family members, etc, stronger importance of
FORTRAN, etc), some people might argue that these are not very relevant
to C ... but still, there are several $B of hardware installed, and,
for example, CONVEX has supported long long as 64-bit integer for years.
CRAY made int 64 bits, and short 32 bits.

2) In 1992, 64-bit microprocessors became available from MIPS (R4000) and
DEC (Alpha), and started shipping in systems. For {SPARC, PPC, HP PA},
the same thing happens in 1995 or 1996 - the chips have all been announced;
some people guess the Intel/HP effort appears in 1998.

3) From 1992 thru current, I estimate there must be about $10B installed base
of 64-bit-capable microprocessor hardware already sold.   Most of it is
still running 32-bit OSs, although some of the 32-bit OS code uses 64-bit
integer manipulations for speed.
I *think* >$1B worth is already running 64-bit
UNIX + programming environments, i.e., DEC UNIX and SGI IRIX 6 (shipped 12
months ago).
While some 64-bit hardware will stay running 32-bit software for a
while, new OS releases may well convert some of the existing hardware to
64-bit OSs, and an increasing percentage of newer systems will run the
64-bit OSs, especially in larger servers.  [2GB/4GB main memory limits
do not make the grade for big servers these days; while one can get
above this on 32-bit hardware, it starts to get painful.]

4) DEC UNIX is a "pure" 64-bit system, that is, there is no 32-bit programming
model, since there was no such installed base of Alpha software, i.e.,
that was a plausible choice for DEC.  SGI's IRIX 6 is a "mixed 64/32"
model, i.e., it is a 64-bit OS that supports both 32- and 64-bit
models, and will, i.e., that is not a transitional choice, as we
believe that many applications will stick in 32-bit for a long time.
IRIX 5 & 6 both support a 64-bit interface to 64-bit file systems in
32-bit user programs, i.e., somewhere underneath is a long long,
although carefully typdeffed to avoid direct references in user code.
DEC UNIX proves you can port a lot of software to 64-bit; IRIX proves you
can make code reasonably portable between 32- and 64-bit.

Both of these systems use the so-called LP64 model, i.e., at this instant,
the total installed base of 64-bit software (with possible exception of
CRAY T3D) uses LP64:
        sizes in bits
Name    char    short   int     long    ptr     long long       Notes
ILP32   8       16      32      32      32      64              many
LLP64   8       16      32      32      64      64              longlong needed
LP64    8       16      32      64      64      64              DEC, SGI
ILP64   8       16      64      64      64      64              (needs 32-bit)

(The comments mean: in LLP64 (Longlong+Pointer are 64), you need *something* to
describe 64-bit integers; in ILP64 (integer, long, pointer are 64) you'll
want to add some other type to describe 32-bit integer.  I didn't invent
this nomenclature, which is less than elegant :-) 

5) In 1992, there was a 6-month effort among {whole bunch of vendors} to see
if we could agree on a choice of {LLP64, LP64, ILP64}.  There was *serious*
talent involved from around the industry, but at that time, we could not
agree.  As it turns out, it probably doesn't matter much for well-typdeffed
code, i.e., newer applications.  Some older code breaks no matter what you
choose, and and some older code works on 1-2 of the models and breaks on the
other(s), with the breakage depending on the specific application.   What we
did agree on was (1) Supply some standard typedef names that application
vendors could use, if they wanted, and if they didn't already have their
own set of typedefs.  Some vendors have done this.  (2) Do long long as a
64-bit integer datatype (NOT as a might-be-any-size >= long), so we'd
at least have one.  NOTE: this is more for the necessities of ILP32;
LP64 and ILP64 could get away without it, but the problem is in dealing
with 64-bit integers from ILP32 programs ... similar to the 16/32-bit days.
As noted, there were several people in this group also involved in ANSI C,
and we asked them about the wisdom of doing this, and were told, unambiguously,
that we might as well go ahead and do it.  Whether it was good or not, it
was not for lack of communication...

6) Now, there is a new 64-bit initiative to get some 64-bit API and data
representation issues settled.  The first part (API), is crucial, and ISVs
really want it badly; that is, some vendors have already done 64-bit ports,
but a lot more are getting there, and we're starting to get into the "big"
applications that have masses of software, and not surprisingly, the ISVs
do not want to have to redo things any more than they need to.

OPINIONS:
1) There is a right time, and two wrong times, to standardize something.
If is standardized too early, before some relevant experience has accumulated,
bad mistakes can be made.  If it standardized too late, a whole bunch of people
will have already done it, likely in more-or-less incompatible ways, especially
in the subtle cases, or will have gotten into a less-than-elegant solution,
basically out of desperation to get something done.  I'd distinguish between
two cases:
        a) Add an extension because it is cool, because customers have
           asked for it, because it helps performance, etc, etc ... or
           because some competitor puts it in :-)
        b) Add an extension because fundamental external industry trends
           make it *excruciatingly painful* to do without the extension or
           some equivalent.
I think "long long" fits b) better than a); people aren't doing this for fun;
they are doing it to fit the needs of straightforward, predictable,
hardware trends that mostly look like straight lines on semi-log charts,
with a transition coming very similar to that which occurred going from
PDP-11 to VAX, i.e., not rocket science, not needing brilliant innovations.

2) So, when is the right time to have at least gotten a simple data type
available to represent 64-bit integers (in a 32-bit environment, i.e.,
assuming that long was unavailable)?

1989: nobody would even admit to working on 64-bit micros.
1990: MIPS R4000 announced (late in year).
1991: Various vendors admit to 64-bit plans; 2GB (31-bits) SCSI disks starting
1992: 64-bit micros (MIPS, Alpha) ship in systems from multiple vendors
1992/1993: DEC ships OSF/1 (I can't recall whether late in 1992, or in 1993)
1994: SGI ships IRIX 6 (64/32-bit)
1996: IBM/Motorola PPC620, Sun UltraSPARC, HP PA8000 out in systems;
      (PPC620 & UltraSPARC might be out in 1995, but for sure by 1996).
1996: ?
1998: ? Intel/HP 64-bit chip ??

From the above, it sure looks to me like we really needed to get *something*
for a 64-bit datatype in C (again, general agreement, not in a formal
standard), usable in ILP32 environments:
1991: would have been wonderful, but too much to expect.
1992: more likely, and there were some people with experience, and there
        were several real chips to help check speed assumptions.
1993: starting to get a little late
1995: too late to catch most of the effort.

Without going through the sequences in detail, the usual realities of
adding this kind of extension usually mean that somebody is adding the
extension to C a year before it would ship (on 32-bit system), and probably
2 years before there's a 64-bit UNIX shipped. This means there were several
companies with committed development efforts in 1991/1992.

So, in summary: it would have been really nice if we could have gotten
something agreeable (that is not blessed as standard, that always takes longer,
but with some agreement of intent) in 1991, or at least in 1992, late enough
for people to have some experience, but early enough to get something
consistent to customers that could still have a chance of being blessed
later on.  Proposals in 1995 ... are late enough that many vendors will
have already done the compiler work that they need to ship 64-bit 
products in 1996 or 1997...  Of course, this is hindsight, and I do feel
a little bad for not pushing harder on this in 1991.


|>      - After much analysis, the problem is not ``can I standardize
|>      "long long", or how to I get a 64-bit type, or what is the name
|>      of a 64-bit type'', but ``loss of intent information causes
|>      portability problems''.  This isn't an obvious conclusion.  You
|>      should read the paper to understand the *real* problem.

Hmmm.  Having started with C in 1973, from Dennis' 25-pager (that's all there
was), and having gone thru the 16- to 32-bit transitions, and Little-Endian ->
Big-Endian transitions, and being old enough to be at least acknowledged in
the first K&R C book, and having /managed various UNIX ports,
and worked on C compilers, and having moved applications around, and having
helped design RISC micros with some strong input from what real C code
looked like, and having helped design the first 64-bit RISC micro ...
I think I understand "loss of intent", which was certainly a major topic
of the 1992 series of meetings.  (we just couldn't agree on which intents
were more common or more important.)

One more time: I claim "how I get a 64-bit type" IS a problem; I don't
think it's the only problem, and there may well be more general ways to
handle these issues (and as soon as I dig up gnu zip so I can look at
the files, I'll look at the SBEIR files).

 BUT, I CLAIM THAT IT IS A *REAL*
PROBLEM WHEN $9B OF COMPUTERS CAN'T EVEN USE A SIMPLE C INTEGER DATATYPE TO
DESCRIBE THEIR OWN INTEGER REGISTERS.   ($9B = $10B - $1B running 64-bit OSs).


|>      - The use of "long long" causes more harm (really!) because it
|>      creates more porting problems.  As a simple example, while we

Causes more harm than what?  Remember, some of us had no choice but to
figure out something to do in 1991 or 1992, to get 32-bitters ready to
deal with 64-bit.  In any case, whether it causes more harm or not,
a whole bunch of us found some 64-bit integer data type *necessary*.

|>      might believe that "long long" is a 64-bit type, what happens
|>      when you move the code to 128-bit machines?  The "long long"

It is *very* unlikely that there will be any 128-bit-integer CPUs used in
general-purpose systems in the next few years;
it would be nice if we could handle them, and the
64->128 transition earlier in the sequence than we did this time.
I'd be delighted if a better type system were in place well before the
time somebody has to worry about.  [I expect to have retired long before that,
but I do have colleagues young enough that they will have to worry about :-)]

We tell everybody to use typedefs anyway; and some do;
we do our best to typedef all of the APIs so people use the right things;
would it have made people happier to have called this int64_t or __int64_t?
But, in any case, as far as I can tell, anyone who is using this is just
treating it as a 64-bit integer.  If somebody is doing something else,
I'd be interested in hearing it.

|>      type will probably map into the X or Y typedef above.  This
|>      will cause porting problems because whatever "long long" is
|>      mapped into, some will believe it is (and use it as) ``the
|>      fastest type of at least 64 bits'' and others will believe it
|>      is ``exactly 64 bits''.  Thus, in the port to 128-bit machines,
|>      we have to track down these implicit assumptions because
|> programmers
|>      *rarely* document their intent (e.g., ``I want the fastest 32-bit
|>      type'') and, mostly, they believe the type itself documents
|>      intent (!).  This is how porting problems are created.

Like I say, I am *seriously* worried about supporting 64-bit integers on
32-bit machines, and *seriously* worried about source compatibility
between 32- and 64-bit machines ... 128-bit machines are far away, and
citing them as a big concern isn't a big help right now, although any
major change to the type scheme should certainly be played off versus the
realities, especially before all of us old fogies who've actually gone
through 2 factor-of-2-up-bits changes are out of this business :-)
 


|> >    c) Standards committees may well need to sometimes invent new
|> >       things [like, when volatile was added years ago].
|> 
|> This solution wasn't ``just invented'', but developed over years by
|> analyzing what the *real* problem is.  The nature of the solution matches
|> the nature of the problem.  BTW, bit/byte ordering/alignment and
|> representation (e.g., two's complement) will be addressed in separate
|> proposals.  The SBEIR proposal only addresses range extensions.

Sorry, I didn't mean to imply that committees invented random features on the
spur of the moment, but rather sometimes had to create features found in
few, if any existing implementations.  I.e., "invent" was not a pejorative
in any way.

|> >    e) Again, as I said before, the 1-2 members of the 1992 group were
|> also
|> >       in the ANSI C group ... were where I got the opinion above
|> from,
|> >       i.e., don't let the non-existence of long long in the standard
|> >       stop you from making progress - it is better to do something
|> >       consistent.
|> 
|> In 1992, that was probably a reasonable opinion.  Since then we understand
|> the problem and have solutions being worked now.

Again ... if the solutions are being worked on now ... they are too late,
I'm afraid.


|> I think if we could have fixed "long long", even with a 90% solution,
|> we would have done it.  Among the reasons for not including "long long"
|> are: we'd have to solve this problem again 10 years from now when people
|> were asking for "long long long" for their 128-bit machines; "long long"
|> causes more portability problems *across different architectures* than
|> it helps.  Years ago, many people wondered out aloud if we could find
|> a ``right'' solution that solved the problem for once and all.  The
|> SBEIR proposal is one solution.

We agree on lots of things; I don't think long long solves all the problems.
I'd hope there's something better for
128-bit than long long long ... but I am really concerned that the common
law "the best is the enemy of the very good" is in operation here.

I think I have good reason to believe that 128-bit-integer machines are
25 years away, i.e., longer than the existence of C...

Meanwhile, $9B (and growing fast) worth of computers ...  and having long long,
*demonstrably* has helped a bunch of porting efforts already.


-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090    FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

Subject: Re: long longs in c
From: mash@mash.engr.sgi.com (John R. Mashey) 
Date: Aug 22 1995
Newsgroups: comp.lang.c,comp.std.c

In article <danpop.809087008@rscernix>, Dan.Pop@mail.cern.ch (Dan Pop) writes:
(Hmm, some rather strong and pejorative statements about many people):

|> In <41b0qq$juj@murrow.corp.sgi.com> mash@mash.engr.sgi.com (John R. Mashey) writes:
|> 
|> >One more time: I claim "how I get a 64-bit type" IS a problem; I don't
|> 
|> And the solution is straightforward: have a 64-bit long.  C has 4 basic
|> integral types and each of them can have a different size: 8, 16, 32 and
|> 64 bits.  Only brain dead software, making unwarranted assumptions about
|> the relative sizes of int's, long's and pointers will be affected.

In the real world, any vendor who, in 1991, declared that in their 32-bit
environment, the sizeof long would now be 8 bytes, would have been lynched by
their ISVs.  Worse, such vendors would immediately have dropped to the
bottom of the port lists, incurring serious financial damage.
These things may be irrelevant to someone in a research environment, some of
which place highest priorities on 1) their own code and 2) free software
and relatively little on software from ISVs.
But these things are *not* irrelevant to many of the rest of us.  Those
in research environments, paid for with research funding, may not consider
these things important ... but a vendor that ignores such issues usually
gets hurt badly, in many cases, going out of business.  This effect is
most commonly seen in high-end technical computing, where mean-time to
bankruptcy is a an important parameter for purchase, and where
environments difficult to program have died pretty badly.

|> Because of DEC OSF/1, most free software has been already fixed.
|> It's high time to stop looking at the model imposed by the VAX as being
|> the holy grail.

Nobody that I know involved in such decisions thinks the VAX model is
the holy grail...

|> The "long long" pseudo-solution wasn't needed in the first place, it was
|> a mistake made by vendors who didn't have the balls to do the right thing,
|> then other vendors followed like lemmings.  It comes a time when the
|> mistakes of the past have to be admitted and corrected.

These are fairly strong, and unnecessarily impolite words, that cast aspersions
upon people with whom you may not agree, but may well have to deal with
differing sets of requirements than yours.

-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090    FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

Subject: Re: long longs in c
From: mash@mash.engr.sgi.com (John R. Mashey) 
Date: Aug 22 1995
Newsgroups: comp.lang.c,comp.std.c

In article <41cv0r$pej@newsbf02.news.aol.com>, ffarance@aol.com
(FFarance) writes:

|> nightmares.  Thus, "long long" is attractive *now*, but will cause
|> problems
|> with 128-bit architectures.  32-bit machines started to arrive around 1978
|> and 64-bit machines around 1991 (my dates are approximate).  128-bit
|> machines will become available around 2004.

I agree with many of the comments before this, but we still have the problem
upon us already.  Again, I make no representation that long long, or
whatever its called, is a panacea...  Again, we are where we would have
been if we hadn't had long, years ago, in doing the 16->32 transition.

re: 128-bit machines available in 2004: let me explain why I seriously
doubt that this is going to happen in any widespread way. You apparently
got 13 = 1991-1978, then 2004 = 1991+13.
a) 32-bit machines,. of course, got popular in in the 1960s with S/360s...
however, the time between generations is more closely related to the
number of bits of addressing, i.e., proportional to number of bits added.
b) But in any case, using DRAM curves, and microprocessor history, and
sizes of physical memory actually shipped by vendors (I've plotted all
these things at one time or another, some is in the BYTE article I noted):
        1) DRAM sizes get 4X larger every 3 years; this has been consistent
           for years; if anything it might slow down a little after the
           next generation, or maybe not.
        2) 4X larger = 2 more bits of physical addressing.
        3) Of course, virtual addressing can consume address bits faster.
           For a program actually using the data, a reasonable rule-of-thumb
           is that there are practical programs 4X larger than the physical
           memory that are still usable, i.e., whose reference patterns
           don't make them page too much.   Hennessy disagrees with me some,
           claiming that memory-mapped file usage can burn virtual memory
           faster, and I somewhat agree, but I also think it takes a while for
           such techniques to become widely used.  In any case, even this
           tends to be at least somewhat bound by the actual size of
           physical disks.
        4) So, assuming that large microprocessor servers started hitting
           4GB (32 bits) in 1994 (and that's a reasonable date: SGI sold
           some 4GB systems in 1994, and some 8GBers either at the end of
           1994 or beginning of 1995.  So, if I pick a date for 4GB,
           knowing there are always some bigger systems, it's 1994.
           1994:        32 bits (4GB)
           1997:        34 bits (16GB)
           2000:        36 bits (64GB)
           2003:        38 bits (256GB)
           ....
           2042:        64 bits (16Billion GB)  (hmmm, seems unlikely :-)
           On the other hand, my 4:1 rule claims that the virtual memory
           pressure is at least 2 bits ahead of the physical, or 3 years
           earlier, and then there's the increasing use of mapped files,
           and then allowing for somebody being more aggressive than the rest
           of the crowd ....  and I come back to my 2020 estimate.
        5) Note that IRIX already has a 64-bit file system and files;
           the largest single file we've seen is 370GB.  Assuming disks
           somehow maintain their current progress of 2X every 2 years,
           and that 4GB 3.5" SCSI disks are around in force:
           Right now, a 64-bit file pointer can address all the data in
           4Billion 4GB disks ... which not everyone can afford :-)
           by 2020, assuming straight-line progression, suppose we've gotten
           13 doublings, you'd want to have a single disk of 32,000 GB (!),
           and now a 64-bit file pointer can only address 2**19 or,
           512,000 of such disks, still likely to be adequate for most uses.
        6) Finally, while the first 64-bit micro came out in 1991/1992,
           and the second in 1992, it is 1998 (?) before all of the major
           microprocessor families get there, and whereas there were at least
           some 64-bit systems many years ago in the supercomputer world,
           offering some ueful experience, I haven't noticed *any*
           128-bit systems anywhere.
        7) Bottom line: something very strange would have to happen to start
           seeing serious use of 128-bitters in 2004.  While your comments
           on C have serious credibility ...  I'd like to see some reasoning
           to justify 2004, because every bit of trend analysis I've done or
           seen says much later...



|> From the perspective of WG14, we expect to complete C9X around 1999.  It
|> seems silly to solve the same problem 10 years from now.  Also, the
|> portability problems *greatly* increase with the use of "long long" even
|> if you restrict yourself to 16-bit, 32-bit, and 64-bit architectures.

But again, I've got some serious portability problems, right now, that
don't seem to get solved except with an integral 64-bit type that is
useful in 32-bit environments, and of course, must persist into 64's.
While I used to care about non-power-of-2-sized architectures, that seems
less of an issue that it was the old days.

Oh well, it looks like we're doomed to a sad state of affairs over the
next few years: a whole lot of people will write code with an extension
that won't be part of the standard; the extension won't benefit from the
standards process, but it will get used, perhaps with yet more flags
(like -ANSI and -ANSI+longlong, i.e., useANSI, but don't flag long longs.
Sigh.)


-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090    FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

Subject: Re: long longs in c
From: mash@mash.engr.sgi.com (John R. Mashey) 
Date: Aug 25 1995
Newsgroups: comp.lang.c,comp.std.c

In article <41je47$20h@newsbf02.news.aol.com>, ffarance@aol.com (FFarance) writes:
|> > From: Dan.Pop@mail.cern.ch (Dan Pop)

|> > I must be missing something. 

Yes.
Frank answered it well:

|> Changing the size, alignment, effective precision, etc., of a "long" or
|> any other data type will break binaries.  You'll be forced to recompile
|> and port everything.  For example, your library routine uses a structure

But I'd add a few more:
a) People use shared-libraries; you need to double those to support
both cases, since all the binaries a customer has don't magically
disappear and get replaced when you ship a new system.
b) Even more, ISVs, especially some rather important ones, create complex
applications that do things like dyamically loading binaries, that may
well have come from 3rd parties, and again, they don't all magically
get recompiled at the same time.
c) Strangely enough, not every program is self-contained; some read/write
data to disk.  If they ever wrote data structures containing longs to
disk, and the compiler then  decides that longs changed size, then even
a simple, single program breaks.  You can't just recompile it, you've got
to go through a serious cleanup.  [This, of course, is where "exact"
descriptors are good things, since they'd be the same under any model.]

DEC changed going from Ultrix to OSF/1 and this was sensible.  I note they
didn't change VMS...  I make no claim that every vendor that makes
a difficult transition will die, just that many who've made it hard to
program have, and that even the survivors have have suffered.

The "reasoned decision" comment was for 32-bit machines, i.e., why
everybody followed ILP32 in the 1980s.

You comment on ISVs ...  I don't know which ones you talk to, but I
talk to some pretty serious ones fairly often ... which is where I get
the opinions.
-- 
-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090    FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c
Subject: Re: long long -- part of what ANSI standard?
Date: 11 Apr 1997 00:55:49 GMT

In article <5ij0f6$b7b@solutions.solon.com>, seebs@solutions.solon.com
(Peter Seebach) writes:

|> Exactly... For this reason, the correct thing to do is use 64 bit
|> longs if you need a 64 bit integer type.  Then, all existing correct
|> code remains correct.  "long long" *breaks existing code*.  (Because
|> existing code has been given an iron clad guarantee by the standard
|> that long is the largest type, and yes, real code breaks mysteriously
|> when this is not true.)

As noted elsewhere, every choice breaks some existing code.
I posted more on this, but it is *not* a correct choice, on a system
that has forever used ILP32 (integer, long, pointer = 32 bits), to change
long to 64-bits; software vendors will definitely kill you.


|> <inttypes.h> is also in the standard, and provides (on machines
|> capable of the support) 8/16/32/64 bit integral types without breaking
|> the type system.  <inttypes.h> came from the 1991 work mentioned in an
|> earlier posting.


|> A real solution, one which lets the user specify integral sizes, would have
|> been preferable.  If you doubt this, wait a couple of years and see what
|> monstrosities are invented as all of the vendors scramble to provide the
|> 128-bit type, which will probably get called "long long long", except that
|> some vendors will make it "long long", and some will spell it int128_t.

Given that DRAM expands at 4X (2 bits)/3 years, and that virtual memory
more-or-less expands ~ memory sizes, and that we're in middle of 32-64-bit
transition now (call that 1992 start), and we just added ~ 32-bits,
32 bits / (2/3 bits/year) = 48 years + 1992 = 2040, *assuming*
DRAM keeps growing at same rate.  *Assuming* heavier use of memory-mapping/
sparse-file techniques, maybe it gets relevant by 2020.

Of course, 4X/3 (or 2X / 1.5 years = Moore's Law) is guaranteed not to
run forever, or even until 2040, so it may be that we do not see
128-bit (integer) processors, in any way like we saw 32, and now 64-bit
CPUs.  I wouldn't be surprised to see 128-bit floating-point sometime.

======
16->32, 32->64:P we've done this 2X thing twice; the first one was relatively
easy: Dennis just added long, well before the 16->32 move, and that was that.
32->64 has been more painful, for various reasons:
	- There aren't enough people around who went through the previous time.
	- It has more constraints that didn't exist 20 years ago, such as
	  CPUs that run both sizes of code together.

So: *maybe*, if we're lucky, it will go like this:

- By 2000, every microprocessor family used in general-purpose systems
	will have at least 1 64-bit member delivered in systems.
- By 2002, 32/64-bit portability will be as well-understood as
	16/32-bit portability got to be ~1980 inside Bell Labs.
- If not already in C, surely the scars will be fresh enough that people
	may adopt extensions that will cover 128-bit, and the
	difference between types-sizes that want to float and ones
	that do not (or at least, people will settle into well-accepted
	#ifdefs that achieve this result).  Hopefully, this could actually
	be in the standard by 2010.  If it's not, then the problem will be
	forgotten; everyone will assume that chips are 64-bit,
	and somebody (else) will get to do this again.
	In any case: the *right* solution, regardless of syntax, is that
	first-class-support for 128-bit ints will be in place in compilers
	for 64- and 32-bit CPUs 2-3 years before the first 128-bitter
	appears, and hopefully earlier.	
-- 
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD:    415-933-3090	FAX: 415-967-8496
USPS:   Silicon Graphics/Cray Research 6L-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389

From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c
Subject: Re: extended integers
Date: 13 Jun 1997 22:27:54 GMT

In article <5nfjad$15d@dfw-ixnews10.ix.netcom.com>, Douglas Gwyn
<gwyn@ix.netcom.com> writes:

|> I just circulated a proposal to formally allow implementations to use
|> extended integers in their standard headers, which provides a way to
|> resolve ptrdiff_t issues etc. as well as to sanction what the Committee
|> consensus was with regard to Kwan's <inttypes.h>. This is not as good
|> as defining a parameterized integer type along the lines of Frank
|> Farance's proposal, but it should suffice for the time being.
|>
|> Also, "long long int" was adopted for C9x. These have to have at least
|> 64 bits.

This sounds like a rational and pragmatic outcome: standards work
is often maddening & usually thankless, so, thanks to the Committee for
doing something reasonable in the real world, even if,
in a perfect world, things might have been different. This at least
means that something sensible will happen to cover the processors that
we'll have around for the next decade or so, leaving some time to
figure out if something better need be done.

--
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD: 415-933-3090 FAX: 415-932-3090 [415=>650 August!]
USPS:   Silicon Graphics/Cray Research 6L-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389


From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c
Subject: Re: Dealing with long long
Date: 20 Jun 1997 23:03:31 GMT

In article <5oeq4m$de1$1@eskinews.eskimo.com>, scs@eskimo.com (Steve
Summit) writes:

|> In article <5o9pbq$abs$1@murrow.corp.sgi.com>,
|> mash@mash.engr.sgi.com (John R. Mashey) wrote:
|> some day; there's clearly a lot of good information in it.
|> Apologies if the point I'm about to make was in there somewhere,
|> and I missed it.]

Thanx; no this wasn't covered, except indirectly under the category of
"It's harder than it looks, and people looked at it hard 5 years ago..."

|> I think it's worth pointing out one issue which is different
|> today than back during the first, 16-to-32-bit crisis: function
|> prototypes.  These don't solve the binary I/O problem, or the

They help, for sure, and I wish they had existed in C earlier
...but...

|> It seems to me that preparing new header files, containing
|> new prototypes for functions in precompiled object files and
|> libraries, *is* a tractable problem.  (But again, I don't
|> claim that this approach solves all the problems.)

...unfortunately, this tends to break most things where the parameter
passed is a *pointer* to an integer whose size is changed, or to
a structure containing such an integer.  Suppose, using Steve's example:
code compiled as:
	int f(x)
	long int x;
==> got a new declaration:
	extern int f(int);

had started,  instead:
	int f(x)
	long int *x;
It does not work to provide a prototype:
	extern int f(int *);

That is, you'd have (64-bit, in this example) longs in your code, which
worked fine, but when you passed a pointer to one, the receiving code would
think it had a pointer to a 32-bit item.  Little-endian & big-endian machines
happen to differ in which of these you might accidentally get away with:
Suppose we'd started with:
	int f(x)
	long int *x;
	{
		(*x)++;
	}

and the calling code looked like:
	long int y = 0;
	f(&y);

value of y: L.E.: 0x0000000000000001; B.E.: 0x0000000100000000

This appears to work on a Little-Endian machine, but not on a Big-Endian,
which fast occasionally came up years ago in letting certain unportable
code sneak by on Little-Endian systems.

If the example were:
	long in y = -1;
	f(&y);
value of y: 0xffffffff00000000; B.E.: 0x00000000ffffffff

--
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD: 415-933-3090 FAX: 415-932-3090 [415=>650 August!]
USPS:   Silicon Graphics/Cray Research 6L-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389


From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c
Subject: Re: Dealing with long long
Date: 23 Jun 1997 02:03:02 GMT

In article <danpop.866823129@news.cern.ch>, Dan.Pop@cern.ch (Dan Pop) writes:

|> But why was long defined as a 32-bit type on 32-bit platforms in the first
|> place?  Without this blatant proof of short-sightedness, the first real
|> "crisis" with the C integral types system would have occured at the
|> transition from 64-bit platforms to 128-bit platforms.
|>
|> >The reason DEC could move to the "sane" 8/16/32/64 system was that they
|> >*were* already requiring their  customers and ISVs to recompile (and
|> >port) as they *were* requiring their customers to move to a new system.
|>
|> What was preventing the other vendors from doing the same thing when they
|> introduced their 32-bit systems???  At that time, their customers were
|> in exactly the same position as DEC's customers when the Alpha was
|> introduced.  This is where Peter's "idiots" and "kooks" actually fit in.

1) With 20 years of hindsight, one might claim that more thought might
have been given to this (and I don't think any of the relevant people are
under the misimpression that C is perfect)...... but "blatant
short-sightedness" and "idiots" and "kooks"???

Perhaps it isn't clear to the readership that such comments effectively
target Dennis Ritchie, Steve Johnson, and their colleagues' decisions
of 1974-1976...

2) "long" came about ~1975; it actually *was* 64-bits on the 32-bit XDS
Sigma 5, but of course XDS got out of the computer business. So,
how did "long" get to be 32-bits on 32-bit systems?

2) While it might have been nice to have anticipated the industry-wide
use of C, and the issues to be faced 20 years' later with 64-bit micros,
these thoughts were not paramount at a time in which:
	- There were a few hundred systems using C, mostly inside Bell Labs.
	- The most common machine using C was a 248KB PDP-11/45,
	  ~.5 VAX-MIP system supporting 10-15 simultaneous users.
	- People still argued about the wisdom of using languages like
	  C for systems code; there were numerous lower-level languages,
	  and in fact, most systems code was still done in assembler in
	  many places.
	- People sometimes hoped that some FORTAN & COBOL code would be
	  somewhat portable across operating systems.
	- The key efforts were (making UNIX itself more portable and
	  doing the Portable C compiler) (1977-1978).
	- For most people in computing, the idea that a system language
 	  like C would be portable ... was considered at best a
	  research topic...
	- For years, it has been easy enough to buy books that tell you
	  how to write really portable C code, and the standards efforts
	  have supported this well, and many people have the relevant
	  experience and understand msot of the issues.
	  Such books were *not* available in 1977...

4) "long" came earlier, ~1975: it was desperately needed
on PDP-11s because neither 16-bit file pointers not int[2]s were really
very pleasant; in any case, despite use of C on 36-bit Honeywell 6000s,
and a few IBM S/360s, and a few other systems, PDP-11 was overpoweringly
the dominant C platform. (On XDS Sigma 5, long actually was 64-bit,
since it was a 32-bit CPU, but for various reasons, 64-bit integers
were relevant. Xerox got out of the computer business, however, and the
BTL-project got cancelled, although it actually had some good
side-effects on C.)

5) After VAXen (and 3Bs, important inside BTL) appeared, there was a period
in which code was shifting from PDP-11s to 32-bit machines, but both
were still important.  The UNIX code base had plenty of longs, because
PDP-11s needed them.

6) The VAX could have had 64-bit longs, but:
	- Code sequences would have been necessary, so there would have
	  been unpleasant performance hits.
	- They would have been especially unpleasant, since a VAX 11/780
	  wasn't *that* much faster than a PDP-11/70, that is, there wasn't
	  some huge leap of technology (the PDP-11 as high-end died
	  prematurely due to lack of address space).
	- People didn't understand portability so well; there was still a lot
	  of non-typedeffed code around.
	- So, more code would have broken, whereas with sizeof(long) == 4,
	  lots of stuff just worked...

7) Hence, by the time there were "vendors" of UNIX systems who actually
did compilers, there was a large body of code on the VAX & elsewhere that
used long as 32-bit.  That gave these vendors (often startups) a choice
in the 1980-1984 timeframe:

A: Start with portable C compiler, existing UNIX code, retarget it
(as onto MC68000), leave the typesizes alone, expect that if the code
works for other people, it will work for you, and get on with it.

B: Realize that 10-15 years later, there would be 64-bit micros,
where it might be
better if sizeof(long) == 8, and that the conversion to 64-bit might be eased,
if the company were still in business.  Thus:
	1. Do a lot more work on pcc.
	2. Clean up all of the code in BSD or ATT UNIX.
	3. Explain to every ISV that this was a purer approach, and it would be
	   good for them in the long run, even if they had to do some cleanup
	   themselves....
	4. Be prepared to clean up each new release of UNIX that you got.
	5. Accept the fact that you'd be later to market, cost more, and
	   have less software ... but be theoretically better.

(Now, perhaps some companies made this decision B; although I don't know of any
offhand; in any case, they appear not to have survived.)

9. Summary: all of this got this way a *long* time ago; vendors had very little
choice; in fact, UNIX vendors who made sizeof(int) 2 suffered as well.
I was managing a SYS III port to MC68K inside BTL in 1982, and we already
had a 68K Blit compiler, but sizeof(int) == 2 broke a lot of code...

Anyway, in retrospect, it would hae been nice if, in 1974-1975, some
truly brilliant people had happened to anticipate a few more of these issues,
but they didn't, because a lot of other things were more important at the
time.  Those who've followed had to live within the constraints of the past.


--
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD: 415-933-3090 FAX: 415-932-3090 [415=>650 August!]
USPS:   Silicon Graphics/Cray Research 6L-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389



From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c
Subject: Re: Dealing with long long
Date: 24 Jun 1997 21:33:22 GMT

In article <RCB2CECHRurzEwuG@on-the-train.demon.co.uk>, "Clive D.W.
Feather" <clive@on-the-train.demon.co.uk> writes:

|> In article <5olq6h$79j@news.inforamp.net>, Peter Curran
|> <pcurran@xacm.org> writes
|>
|> >But the issue, to the best of my understanding, is that an
|> >implementation can introduce "long longs" into code that does not
|> >contain any, by defining some of the types required by the standard,
|> >such as "size_t," as "long long." If this is not true, then my
|> >concerns are greatly alleviate.
|>
|> Indeed, and they're not (alleviated).


To further understand, maybe people can provide some more information,
understanding that there is a difference between:
	1. What a standard says, where there is often a fine line between
		a. Specifying insufficently, and causing implementations
		  to diverge for no good reason.
		b. Specifying the minimum necessary.
		c. Overspecifying, and thereby disallowing many kinds of
		   hardware implementations
and	2. What people are actually doing, where the standard might have
	allowed something (that wouldn't work), but nobody is building
	those systems anyway, so it becomes a moot point.

So, the question is:
	Does anybody know of a specific implementation, whose plans are
	public, in which size_t is (unsigned long long)
	and sizeof (unsigned long) !=  sizeof (unsigned long long) ?

Example: in IRIX 6's, code compiled for 32- and 64-bit modes:
	int	long	long long	ptr	size_t
32	32	32	64		32	32	ILP32LL
64	32	64	64		64	64	LP64

I.e., above, size_t is the same size as a long, so the problem appears not
to arise. <types.h> size_t doesn't use long long as a base.

As far as I know, the main place that long longs get introduced into
typical 32-bit systems is for off64_t's, i.e., to use the new LFS
lseek64, tell64, ftruncate64, etc, i.e., if people want to access files
>2GB, but do not need larger address space [i.e., identical
to the original use of long on 16-bit PDP-11s].



--
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD: 415-933-3090 FAX: 415-932-3090 [415=>650 August!]
USPS:   Silicon Graphics/Cray Research 6L-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389



From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: int32_t
Date: 1 Apr 1999 01:29:45 GMT

In article <7du4ni$e8e$1@eskinews.eskimo.com>, scs@eskimo.com (Steve
Summit) writes:

|> Organization: better late than never
|>
|> In article <37015131.32781085@news.pathcom.com>, pcurran@acm.gov writes:

|> > HP, for one, said a year ago that 64-bit longs is their standard.
|>
|> Good for them!  This is clearly the right choice, on a processor
|> that supports a 64-bit type.

There may be some confusion here, since the original statement
was so imprecise,  so just be absolutely clear, which is easily findable
in public web pages:

1) HP/UX was ILP32, and then got to be ILP32LL64, I don't recall when.

2) By HP/UX 11.0, HP provided an entire 64-bit environment,
and it is LP64 (= I32LLLP64 if you like), and 64-bit HP/UX 11.0s
run either flavored binaries, which do not mix.

3) long is 32 bits in the 32-bit environment, as HP, like everybody else
was not about to change that.  I don't know offhand of *anyone* doing
IP32L64 at this time.

4) long is 64-bits in the 64-bit environment, meaning that HP made the
same choice as {DEC, SGI, IBM, Sun}.

--
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD: 650-933-3090 FAX: 650-933-4392
USPS:   Silicon Graphics/Cray Research 40U-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389


From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: int32_t
Date: 1 Apr 1999 07:15:51 GMT

In article <3702F312.ACDF064D@null.net>, "Douglas A. Gwyn"
<DAGwyn@null.net> writes:

|> John Mashey is not on the committee, and I rather suspect what
|> he meant to convey was that initial discussions occurred among
|> interested parties via e-mail back then.  He seems to think
|> that the issue was settled by an entirely non-WG14 meeting
|> among UNIX vendors (HP, Sun, SGI) several years ago.  But WG14
|> has made its own decisions for its own reasons after considering
|> arguments from other sources, including some that originated in
|> netnews discussion groups such as this one.

Yes, to make sure this is perfectly clear:
1) There was about 6 months of meetings that were NOT WG14,
and had no official standing whatsoever, but was just a bunch of
Fellows, Chief Scientists & such from major computer companies
and software companies getting together physically and by email.
This was occasioned by the fact that several vendors already had 64-bit
CPUs, and more were designing some, and file size pressures were growing,
and anybody who could plan a few years out could see that they'd need
64-bit pointers for some codes by the mid-1990s. Compiler teams industry-wide
were planning  64-bit object file formats, compilers, tools, etc.

2) Hence, it was deemed a good idea to see if we could agree on a
64-bit model, and the preceding related technologies, to try to do something
that was not irrationally anarchistic.

3) We were unable to get everybody to agree on any one of the 3 choices:
ILP64, LP64, or P64, and there were several strong proponents of each.
We did agree on inttypes.h (to help some problems), and we did agree that
we needed a type that could be 64-bits without breaking existing
32-bit code (i.e., to convert ILP32LL), and that it might as well be long
long (amongst the UNIX members anyway), given Amdahl and gcc.
The P64 groups needed a long long (while ILP64 and LP64 didn't),
but just about everybody wanted to extend their ILP32 to ILP32LL.

Of course, it turned out that the UNIX crowd generally went LP64,
at least partially because several of the early implementations were that.

4) There was concern about whether doing long long would cause later trouble
with C9X (which of course, being years away, meant nobody could wait),
and since there were several attendess who were WG14 members, they were asked
for their opinions, which basically came down to:
	"If you need it, go ahead: it's better that people do something
	consistently, and while there are no promises about what will happen
	with the next iteration of the standard, if a big chunk of the industry
	does it as a common extension that will get serious consideration."
This seemed both fair and modestly encouraging, so most of us did it.
Had anyone been able to compelling propose something different, we
would have done something different.

5) Hence, when I say it was mostly settled in 1992, I do not mean that
anything officially was settled, I mean that a substantial part of the
industry agreed to do something, because people couldn't wait any longer.
The Committee, while having the clear authority to set the standard,
is also rational in considering substantial experience already
implemented by many large hardware and software vendors.
maybe it was actually "settled" in 1983, when Amdahl starting doing this,
or later, when it got into gcc.

6) Anyway, there was every possible consideration given to standards,
but subject to the pressing demand that many players felt to have 64-bit
integers added into their 32-bit environments.

7) In some sense this shouldn't have had to happen this way, but
C89 didn't provide a type available to add 64-bit into an existing 32-bit
environment, and the dictates of hardware progress demanded one.

8) Once again, I reiterate, that amongst myriads of propsoals and
approaches, this was viewed as "the least bad".

--
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD: 650-933-3090 FAX: 650-933-4392
USPS:   Silicon Graphics/Cray Research 40U-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389


From: "Douglas A. Gwyn" <DAGwyn@null.net>
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: int32_t
Date: Thu, 01 Apr 1999 22:49:06 GMT

"John R. Mashey" wrote:
> 7) In some sense this shouldn't have had to happen this way, but
> C89 didn't provide a type available to add 64-bit into an existing 32-bit
> environment, and the dictates of hardware progress demanded one.

Yes; the origin of the problem seems to be that C89 lacked the
foresight to accommodate such expansion.  Something had to give.
It turned out to be the promise that all standard typedefs of
integer types could be contained in a (possibly unsigned) long.


From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c
Subject: Re: coding style advice for sizeof (long) < sizeof (size_t)?
Date: 5 Apr 1999 22:18:44 GMT

In article <t81zhzo186.fsf@discus.anu.edu.au>, Geoffrey KEATING
<geoffk@discus.anu.edu.au> writes:

|> This is why GNU/linux has off64_t.  You can choose between
|>
|> a) off_t is 'long' (and there is no off64_t)
|> b) off_t is 'long', off64_t is 64 bits
|> c) off_t is 64 bits (and there is no off64_t)
|> b) off_t is 64 bits, off64_t is 64 bits
|>
|> (depending on the system, the list above may have some overlap).
|>
|> Don't ask about 128-bit-length files...  This is simply implementing
|> someone's standard.

1) This is from the Large File Summit, and is widely implemented.
The LFS spec is partially derived from SGI's IRIX 5.3 XFS implementation
of 1994, and was driven by ISVs (like SAS) and a bunch of systems/OS vendors.

2) To relate the above to the models often discussed:

			off_t	off64_t			size_t
ILP32			32	none			32
ILP32LL (most)		32	64			32
ILP32LL (SGI -n32)	64	64			32

LP64*			64	64			64
IL32LLP64 (P64)	**	32	64			32
ILP64			64	64			64

* = what most UNIX folks do, ** = 64-bit NT

In SGI's case, there are actually 3 models:
	-o32 (the old 32-bit ILP32, later converted to ILP32LL ~1992)
	-n64 (LP64, ~1994)
	-n32 (ILP32LL, but implemented with 64-bit registers, more FP registers,
		hence impossible to make binary-compatible with the others,
		and people decided to go ahead and make off_t bigger so that
		more programs would recompile and automatically get to
		big files without having to go to LP64.  Neither
		-n64 nor -n32 is a "replacement" for -o32, in that many
		programs are still -o32, and there is still a full set of -o32
		libraries.

This brings me to something I still get questions on:

WHY PEOPLE DON'T JUST *CHANGE* LONG TO BE 64 BITS IN 32-BIT ENVIRONMENT:

In SGI's case (typical) of commerical UNIXes), if you look at a customer's
system:
	a) UNIXkernel
	b) About 60 SGI-provided dynamic-linked libraries for *each* of
	   the 3 programming models.  Of course, once you ship a dynlinked
	   library, you can never take it away, although you can replace
	   it with a 100% upward-compatible superset.  [Not everybody
	   seems to understand this ... but customers get seriously irate
	   when a new OS+librarires arrives, and their existing apps suddenly
	   break because a new dynlinked library isn't quite consistent.
	   The rules say that if you change an interface, you use versioning
	   to make sure the old and new versions are distinguishable,
	   and old programs get the right version.]
	c) Anywhere from a handful to hundreds of dynlinked libraries
	   from ISVs, either for use only in their own app suites, or for
	   others to use.  On NT, there are probably more (DLLs, that is,
	   in 5 minutes I found several hundred on my wife's NT system.]
	d) Executable apps, some with static-linked libraries, but most
	   with dynlinked ones from b) and c), which come from SGI,
	   multiple ISVs, and sometimes the end-customer.
	   A typical user of ISV apps probably has 10-20 apiece, but of course,
	   they are a different 10-20 apiece.
	e) Think of a giant directed graph, consisting of thousands of
	   apps (at the top), hundreds of libraries, and a customer, to have
	   a working system, picks a handful at the top, and all of the
	   connected pieces undeneath have to be consistent.  People have
	   proposed using thunks to fix inconsistencies; that doesn't work,
	   especially in the kind of intermingled dynlinked library setups
	   now found out there.

For each programming model:
1) SGI made the kernel support it.
2) SGI provided compilers, system librarries, tools.
3) ISV library vnedors recompiled their libraries.
4) ISV apps vendors recompiled their libraries, and then their apps.

There are thousands of applications, many of which are clean code,
portable enough to compile under any of the models.  Nevertheless,
binary compatibility constraints forbid flash-cut replacement of
one model by another.  Commercial customers expect:

1) A new OS+library setup arrives on new hardware.  One can install
compatible apps and then work.

2) Later, additional apps arrive (ISV schedules differ), and those
apps can be installed and work, including data interchange with the
existing apps.  Major ISVs often have a 1-3-year major release cycle,
and if you miss a release cycle, you wait until the next one.

3) Later yet, another new OS+library setup arrives, and it is installed
on the old hardware, and people expect the existing apps to continue to
work.  A vendor who does the following probably gets to go out of business:
	"There's a new programming model in which long has changed from
	32 to 64-bits; to make sure you switch, we've converted to this
	from our old way, and removed all of the old libraries.
	Recompile all your code, and rewrite your code to cope with
	binary data on disk or tape that was written with longs.
	Here is a list of ISV suppliers who already have converted their
	code.  Please talk to anyone not on this list and urge them to move
	up their release schedules, since their apps are broken on your system
	until they do.  Also, allow in your budget upgrade fees that you
	hadn't anticipiated."

I have had (unnamed) people recommend this approach to me, in the effort
to fight off long long... :-)

4) Hence, in practice, sane vendors *keep* the old models around (essentially
forever), and add new models alongside, but don't expect to intermix binaries.
Most ISVs strongly prefer to provide exactly 1 port of most of their software
on any given platform, for rational economic reasons.  If there is a good
reason to supply two, they might.  [For example, Oracle supplies
32-bit apps, and both 32- and 64-bit server].
If there are 2-3 alternate forms, they naturally pick whichever one
costs them the least to supply, and covers the most machines,
and switching to a new model must have some clear benefit; for example,
programs that *really* want to be 64-bit are motivated to convert ... but as
DEC found out early in Alpha's life, there were lots of apps that didn't
need to be 64-bit, and it cost a lot to get the apps moved.

5) On true 32-bit CPUs, converting ILP32 to ILP32LL is upward-compatible,
no slower, occasionally faster, and the binaries intermix with no trouble,
hence most vendors did this.  Simply replacing ILP32 with IP32L64 is
not binary-compatible, is never faster, and often slower, and so people
generally did not do this, starting with VAX UNIX.

6) On 64-bit CPUs, one can have:
6a) ILP32LL binary-compatible with earlier 32-bit family members.  This
is the overpoweringly popular choice, especially as augmented with the LFS
off64_t, etc stuff, which lets people get to big files in a more gradual
fashion.
6b) ILP32LL model, but using 64-bit registers, so that LL is fast.
This is popular in the games/embedded arena, where source compatibility
with 32-bitters is important, but binary compatibility is less so, and
the extra performance is worthwhile.
6c) IP32L64: so far, not a choice that people generally make, because
it breaks more programs than ILP32LL, and doesn't have big pointers,
and is usually slower than ILP32LL.

6d) P64 or LP64: for programs that care about large data, this is a major plus,
so people do use it, for those programs where it matters, and they happen
to be important programs, albeit relatively few in number.

7) In summary:  source code may be very clean, paranoidly
portable, good, etc ... but these days, lots of code doesn't exist in a vacuum,
but depends on *binary* interfaces with huge chunks of other code from
multiple sources.  While many data declarations are of interest only inside
the programs that use them, others manifest themselves outside, onto
disk, tape, or in binary interfaces, and *everybody's* idea of the sizes
of such data objects needs to change together, or very carefully.



--
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD: 650-933-3090 FAX: 650-933-4392
USPS:   Silicon Graphics/Cray Research 40U-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389


From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c
Subject: Re: coding style advice for sizeof (long) < sizeof (size_t)?
Date: 6 Apr 1999 17:04:50 GMT

In article <7eca2t$quu$1@shade.twinsun.com>, eggert@twinsun.com (Paul
Eggert) writes:

|> mash@mash.engr.sgi.com (John R. Mashey) writes:
|>
|>                                 off_t   off64_t                 size_t
|>         ILP32                   32      none                    32
|>         ILP32LL (most)          32      64                      32
|>         ILP32LL (SGI -n32)      64      64                      32
|>
|>         LP64*                   64      64                      64
|>         IL32LLP64 (P64) **      32      64                      32
|>         ILP64                   64      64                      64
|>
|>         * = what most UNIX folks do, ** = 64-bit NT
|>
|> Is this table correct?  If so, then 64-bit NT
|> does not have the problem of long being shorter than size_t.

Sorry, I tried to get too many things into this table, editing the NT
thing in later.  Let me expand & correct it:

				off_t	off64_t			size_t
1)	IL32LLP64 (P64) UNIX	32	64			32
2)	IL32LLP64 (P64) UNIX	32	64			64
3)	IL32LLP64 (P64) NT	32	64			64(sort of, ?)

1) In the first choice, the rationale would have been:
	a) Of the existing basic datatypes, only pointer changes size.
	b) Since most data structures on disk/exchanged between programs
	don't have pointers, such structures would stay the same size.
	c) Most object sizes fit into 32 bits anyway.
	d) Keeping most data small gains efficiency.
	e) yes, it is peculiar that ptr_diff must be bigger than size_t.

2) In the second choice, the rationale would have been:
	a) As above.
	b) As above, except size_t's also change size, but there aren't that
	many for them, and this avoids the surpise of e), and leaves more room
	for the future, as there get to be more larger objects.

I say "would have been", because AFAIK, none of the major UNIXes went
this way, although 1-2 vendors argued strenuously for it (although I
don't recall whether they intended to do 1) or 2), but in any case,
everybody went LP64 anyway, for consistency.

3) Regarding Microsoft, as I posted earlier, as far as I can tell, you
aren't supposed to use size_t, you're supposed to use SIZE_T, which is of
Pointer precision, and therefore 64-bits, and in some sense, doesn't
belong in the table at all.

So, the bottom line, I think is:
1) The UNIX folks generally went dual-model ILP32LL + (on 64-bit chips) LP64,
in both cases size_t has the same size as long.
2) Microsoft made SIZE_T bigger than long.

--
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD: 650-933-3090 FAX: 650-933-4392
USPS:   Silicon Graphics/Cray Research 40U-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389

From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: int32_t
Date: 31 Mar 1999 01:10:51 GMT

In article <37014A2C.BB88326E@technologist.com>, David R Tribble
<dtribble@technologist.com> writes:

|> If you don't count Microsoft Windows running on 64-bit platforms.
|> As I understand it, they've decided that 'long' is still 32 bits
|> wide on 64-bit platforms.  (I suppose they'll call it Win64 instead
|> of Win32.)  If that's so, and it's possible to have more than 4 GB
|> of virtual memory on your desktop (in the near future anyway), then,
|> yes, it will be a problem for some mainstream platforms.

Clarification:
At the Intel Hardware Developer Conference a month ago, Microsoft went
through the same stuff the've been telling developers for a while,
so here's what they say (extracted from large numbers of foils):

1) They are indeed using "LLP64", and their goals include:
-	"Porting from win32 to win64 should be simple.

-	Supporting win64 and win32 with a single source base is our goal.

-	No new programming models.

-	Require minimal change to existing win32 code data models."


2) They basically recommend the same thing as people often do elsewhere,
which is to use typedefs layered on top of the basic types, and absolutely
avoid the basic types in most code.  They say:

3) "Win64 sample types:
	Name				What it is
	LONG32, INT32			32-bit signed
	LONG64, INT64			64-bit signed
	ULONG32, UINT32, DWORD32	32-bit unsigned
	ULONG32, UINT32, DWORD64	64-bit unsigned
	INT_PTR, LONG_PTR		Signed Int of Pointer Precision
	UINT_PTR, ULONG_PTR, DWORD_PTR	Unsigned Int of Pointer Precision
	SIZE_T				Unsigned count of Pointer Precision
	SSIZE_T				Signed count of Pointer Precision

4) Win64 Data Model Rules
- If you need an integral pointer type, use UINT_PTR, ULONG_PTR, or DWORD_PTR.
	Do not assume that DWORD, LONG or ULONG can hold a pointer.

- Use SIZE_T to specify byte counts that span the range of a pointer.

- Make no assumptions about the length of a pointer or xxxx_PTR, or xSIZE_T.
	Just assume these are all compatible precision."

5) 64-bit integers map to __int64.

6) I make no value judgements on this, i.e., it is just posted to make
sure the facts are clear about what they are doing.  Observe, of course,
that:
	a) Microsoft has zero interest in non-power-of-two-bits words, ever,
	and hence is happy to embed 32s and 64s into typenames.

	b) Microsoft has zero interest in code developed on NT being portable
	to non-MS environments ... although it actually happens, that if you
	follow their advice about types, and *never* use int, long, etc
	directly, you can get code whose non-OS-dependent pieces might port
	easier amongst other 32- and 64-bit OSs, i.e., because they have
	attempted to remove the overloaded assumptions sizes by having more
	types that people actually use.  Hence the following odd effect occurs:
	Win64 code may be more portable amongst 32&64-bit UNIXes,
	than is slopper old UNIX code... :-)

	c) This is the way Win64 is, regardless of anything in C9X.

--
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD: 650-933-3090 FAX: 650-933-4392
USPS:   Silicon Graphics/Cray Research 40U-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389


From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: coding style advice for sizeof (long) < sizeof (size_t)?
Date: 22 Apr 1999 20:19:34 GMT

In article <7fno4u$fje@agora.dmz.khoral.com>, "Richard Krehbiel"
<rich@kastle.com> writes:

|> (http://msdn.microsoft.com/developer/news/feature/win64/64bitwin.htm) and I
|> saw no mention of size_t anywhere, only SIZE_T (which is new for Win64).
|>
|> Sounds like you're probably right, and I'm probably wrong.
|>
|> It means malloc can't create objects larger than 4G.  I suppose that means
|> Win64 programmers will begin migrating to VirtualAlloc and further away from
|> Standard C - and I suspect MS sees that as A Good Thing.

Microsoft presentation at Intel Developer Forum includes foil that says
(look carefully at the last line):

Pointer/Length Issues
- Many APIs accept a pointer to data and the length of the data
- In almost all cases, 4GB is more than enough to describe the length of
  the data.
- In very rare cases, >4GB of length is needed.
- We classify these as Normal objects, or Large objects

Another slide says (I think I posted this before):
- Use SIZE_T to specify byte counts that span the range of a pointer
- Make no assumptions about the length of a pointer or xxxx_PTR or xSIZE_t.
Just assume these are all compatible precision.'

And yet another slide syas:
- Supporting win64 and win32 with a single source base is our goal

I think Microsoft is giving very clear advice:
	- Forget you ever heard of size_t, use SIZE_t (or SSIZE_T) in
	both win32 and win64 code.
--
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD: 650-933-3090 FAX: 650-933-4392
USPS:   Silicon Graphics/Cray Research 40U-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389


From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: coding style advice for sizeof (long) < sizeof (size_t)?
Date: 23 Apr 1999 03:08:12 GMT

In article <371FBBF3.1D1889A5@jps.net>, Dennis Yelle <dennis51@jps.net> writes:
|> "John R. Mashey" wrote:

|> > I think Microsoft is giving very clear advice:
|> >         - Forget you ever heard of size_t, use SIZE_t (or SSIZE_T) in
|> >         both win32 and win64 code.
|>
|> I don't read it that way.
|> I think they are saying:
|>
|>     Use size_t for Normal objects, and SIZE_T for Large objects.
|>
|> If you are correct, why did they introduce the terminology
|> "Large objects" ?

Beats me .. it's just that in the info I looked at, I couldn't find any
mention of size_t where one might have expected it, and their directions
seemed very explicit to prefer SIZE_T ... which would let them have
SIZE_T to act like the long of ILP32LL and of LP64, but while using
P64 (= IL32LLP64, to be explicit).
--
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD: 650-933-3090 FAX: 650-933-4392
USPS:   Silicon Graphics/Cray Research 40U-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389


 










































































































































































































































































































































































































































































































































































































































































































































































































































































































































































Index Home About Blog