From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: int32_t [really: committtee]
Date: 3 May 1999 17:26:06 GMT

In article <7gjdk4$6j6$1@engnews1.eng.sun.com>, corbett@lupa.eng.sun.com
(Robert Corbett) writes:

|> If you are interested in changing the course of the C standards
|> committee, now is the time to act.  Getting a standard into
|> publishable shape is both grueling and tedious.  Many members of a
|> committee quit after a standard is published.  That means that it is
|> relatively easy to reach a position of prominence on the committee.

Well said ... I am always impressed that some people do it more than once ...

but in addition, I'd suggest there are some very useful things that people
could (and need to) be doing fairly soon, well before the committee really fires
up for the next one.   As these discussions have shown, there is no dearth of
ideas ... but many ideas simply do not work when they actually have to
be implemented in the context of real compilers, linkers, libraries,
application software, OSs, the usual downfall being that something that
sounds like a good solution for one problem has unintended side-effects.

Hence, I'd surely hope to see multiple implementations over the next couple
years that might establish a body of C-based experience for
evaluation by the next committtee, since otherwise, many new proposed
features would have to be new inventions in the committtee, and such
inventions are (correctly) viewed as guilty until proven innocent,
and they normally don't get in.

Here are a few of the things that people might want to work on:

1) Is there a parameterized type system that cleanly covers:
	- the existing environments
	- integers likely to have reasonable efficiency and
	  have typical in-line code generation [i.e., this is at least the
	  integer register width, with varying degrees of support for
	  2X the register width, but not normally 4X the width].

2) Is there an appropriate way to integrate bignum support, especially if 1)
exists? If required to support integers more than 2X register width,
most compilers would tend to use out-of-line function calls. Some people
would like to be able to write code that expressed the algorithms in one
way (rather than, for example, using long long for 64-bit, and bignums for
128-bit and above), and have the compiler do the right thing for a given
machine.

3) Many CPUs now have SIMD instructions that deal with vectors of 8-bit or
16-bit items, thus creating datatypes that don't seem very well-handled
in C, as relatively few compilers seem to be able to generate the SIMD
instructions directly, and vendors just supply libraries.

Are there language features culturally compatible with
C, such that more of this code could be written in it, and be portable amongst
the different implementations, and still be reasonably efficient?
Failing that, can somebody at least identify a "multi-media stdio" library
that can have more commonality?  The current state of the world is as
though sin, cos, etc had slightly different names and behavior everywhere.

It would be really nice if by 2005, there were several implementations
of these things floating around, with a couple years' live experience.

--
-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: multimedia stdlib [was int32_t]
Date: 5 May 1999 17:41:28 GMT

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

|> >the primary interest is in understanding if there are
|> >appropriate things to do to C to get to this hardware directly.
|>
|> I'm a bit dubious, but perhaps you have something concrete in mind?

In my comment, note the word "if" ...  i.e., I don't take it as a forgone
conclusion one way or another, I just observe that current CPUs now
support large sets of operations that are effectively inaccessible from
C ... and that may be the way that things work out, but it is of some
concern, because it inhibits portability.

As for something concrete, that will take a lot of work: there is some parallel
with FORTRAN and vector processing, and both C & FORTRAN and parallel
processing: compilers have learned, over time, how to start from the original
code and vectorize, but realistically, getting good code often
requires insertion of at least a few directives that help the compilers.

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