jon@boulder.UUCP (Jon Corbet) (10/13/84)
As long as we are discussing improvements to the language, I would
like to suggest a couple:
(1) Get rid of that requirement that all floating point arithmetic
be done in floating point. Here at NCAR, we have applications
that need to quickly crunch a few megabytes of data and get it
to the display, while the scientist is sitting there twiddling
his thumbs and wondering if the programmers should get raises
after all. 32 bits is plenty of precision for our calculations,
and the double precision slows things down enough that our
math intensive routines are still written in (UGH!) FORTRAN.
This is a drag, since I really campaigned hard for a C compiler,
and I still have to use FORTRAN. I don't care if I have to
set a compiler flag or whatever, as long as I can use single
precision arithmetic.
(2) The DEC C compiler allows a "readonly" designation on global
variables. This is handy to insure that one does not overwrite
static lookup tables and such. VAX type machines can easily
implement readonly variables. I suggest that readonly should
be part of the language in much the same way as register
variables -- i.e. the compiler does not have to implement things
that way if it is in a bad mood or the machine does not
support it.
--
Jonathan Corbet
National Center for Atmospheric Research, Field Observing Facility
{hplabs|seismo}!hao!boulder!jonquiroz@rochester.UUCP (Cesar Quiroz) (10/14/84)
OOPS! I did it again. Sorry, in my previous posting there is at least one 'too' that should be 'to'. Typing postings in Saturday nights seems dangerous all across the network: > As long as we are discussing improvements to the language, I would > like to suggest a couple: > > (1) Get rid of that requirement that all floating point arithmetic > be done in floating point. ????? At first impression, looks like old-style Forth ("you can do it with integers") is striking back. Happily enough, it seems the intention was "be done in double precision", a much saner proposition. (If this interpretation is another effect of the time of the day, please correct me). Ok, time to sleep, get away from the keyboards ... Cesar
karsh@geowhiz.UUCP (Bruce Karsh) (10/14/84)
> As long as we are discussing improvements to the language, I would > like to suggest a couple: > > (1) Get rid of that requirement that all floating point arithmetic > be done in floating point. I second this one. Does anybody have a good reason why there is no single precision floating point in C. Along the same lines, it would be nice if C supported longer ints than 32 bits. Often we have to go to floating point representations with concomittant loss of accuracy in order to represent quantities that vary over a large range. Of course, I understand that the standards people have enough problems without having to extend the language at the same time. Bruce Karsh
guy@rlgvax.UUCP (Guy Harris) (10/15/84)
> As long as we are discussing improvements to the language, I would > like to suggest a couple: > > (1) Get rid of that requirement that all floating point arithmetic > be done in floating point. ... I don't care if I have to > set a compiler flag or whatever, as long as I can use single > precision arithmetic. I presume you meant "done in double precision", not "done in floating point"; floating point is not required to be in double precision by the ANSI C draft standard. (It's not even so required by the PDP-11 hardware, but that's another story.) > (2) The DEC C compiler allows a "readonly" designation on global > variables. This is handy to insure that one does not overwrite > static lookup tables and such. VAX type machines can easily > implement readonly variables. I suggest that readonly should > be part of the language in much the same way as register > variables -- i.e. the compiler does not have to implement things > that way if it is in a bad mood or the machine does not > support it. Most all machines implementing UNIX can implement readonly variables - if you can have shared text, you can probably have shared readonly data. (To do it on machines with separate I&D space with programs that use separate I&D space would require changes to UNIX, but there do exist UNIX versions with those changes.) This is also in the draft standard, although they chose "const" instead of "readonly", possibly to make it compatible with the syntax used in Bell Labs' C++ language. "const" is actually fancier than, say "static", in that you can have a "pointer to const XXX" as well as a "const pointer to XXX"; presumably, this is so the compiler can detect code that tries to modify "const" variables (an oxymoron?) at compile time. I suspect it works as you suggest - i.e., an implementation can ignore it if it chooses. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
henry@utzoo.UUCP (Henry Spencer) (10/15/84)
> (1) Get rid of that requirement that all floating point arithmetic > be done in floating point. ... I assume you mean "be done in double precision"! The ANSI committee is ahead of you on this one. Expressions involving only "float" quantities may be done in "float" precision if the compiler so chooses. Note that this is not compulsory; it's up to the compiler implementors. Note also that constants are still "double" unless explicitly cast to "float", which is a nuisance (the alternative was nightmarish problems in deciding the type of a floating-point constant). Not ideal, but workable. > (2) The DEC C compiler allows a "readonly" designation on global > variables. This is handy to insure that one does not overwrite > static lookup tables and such. ... Again the committee is ahead of you. There is a "const" modifier in the draft, taken from recent Bell-internal versions of C. It does more than you suggest -- in my opinion, more than is really necessary -- but it can be used to get this effect in particular. It is not just a convenience; people who are putting tables into ROM for micros need it badly. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/16/84)
Both the full support for single-precision floating-point and "readonly" were in the draft ANSI C standard, last I heard.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/16/84)
C already supports ints longer than 32 bits. Nowhere does it say how long a "long" is; that is decided by the compiler implementor. I suggest you have a long talk with yours..
jon@boulder.UUCP (Jon Corbet) (10/16/84)
>> As long as we are discussing improvements to the language, I would >> like to suggest a couple: >> >> (1) Get rid of that requirement that all floating point arithmetic >> be done in floating point. ... > >I presume you meant "done in double precision", not "done in floating >point"; Yes, I certainly meant double precision. This is what happens when I do my netnews interaction before that all-important first cup of coffee has entered my bloodstream :-) Jonathan Corbet National Center for Atmospheric Research, Field Observing Facility {seismo|hplabs}!hao!boulder!jon
henry@utzoo.UUCP (Henry Spencer) (10/16/84)
> ... I suspect it [const] works as you suggest - i.e., an implementation > can ignore it if it chooses. Not quite. There are things that you cannot do to a variable of const type -- e.g., use it on the left-hand-side of an assignment operator -- and these must be diagnosed even if const things are not special in any other way. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
boone@mmm.UUCP (David Boone) (10/17/84)
The need for single precision routines is almost mandatory. On the pdp-11 the conversion from single precison to double precision involves only pushing an extra word of zero. On my 68k systems, with software handling the floating point, it takes around 12 instructions to perform the conversion (IEEE format). Don't say buy a floating point co-processor. I should not have to cover up with hardware botches in the language. ...!ihnp4!stolaf!umn-cs!mmm!boone David Boone
guy@rlgvax.UUCP (Guy Harris) (10/19/84)
> > (1) Get rid of that requirement that all floating point arithmetic > > be done in floating point. ... > > ... Note also that constants are still "double" unless explicitly cast > to "float", which is a nuisance (the alternative was nightmarish problems > in deciding the type of a floating-point constant). Not ideal, but workable. I presume the FORTRAN alternative (it's single precision unless specified with an exponent whose exponent character is 'd', not 'e', like "3.1415926535d0") was rejected for compatibility reasons; intuiting the type from the length of the string or somesuch is, I agree, nightmarish. The only alternative is to require it to be stated explicitly somehow; the question is whether the default should be "double" or "float". ("long" constants already require the length to be specified explicitly, by a trailing "L".) > > (2) The DEC C compiler allows a "readonly" designation on global > > variables. This is handy to insure that one does not overwrite > > static lookup tables and such. ... > > Again the committee is ahead of you. There is a "const" modifier in the > draft, taken from recent Bell-internal versions of C. It does more than > you suggest -- in my opinion, more than is really necessary -- but it can > be used to get this effect in particular. It is not just a convenience; > people who are putting tables into ROM for micros need it badly. And people who want to put tables or strings into shared code space, although there you can get away with them being in non-shared and writable data space. Currently, it's done with machine-dependent and implementation-dependent kludges, usually called "rofix" (for shoving everything into text space by turning ".data" into ".text" in the assembly output) or "yyfix" (for pushing YACC tables into text space). The latter changes with the System V YACC, as it depends on the exact shape of the generated "y.tab.c" to determine what are parse tables (to be put into one source file) and what is everything else (to be put into another source file). "const" is long overdue; I'm considering dropping it into our C compilers (although without the checking to catch attempts to modify constants at compile time). Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/19/84)
> > ... Note also that constants are still "double" unless explicitly cast > > to "float", which is a nuisance (the alternative was nightmarish problems > > in deciding the type of a floating-point constant). Not ideal, but workable. > > I presume the FORTRAN alternative (it's single precision unless specified > with an exponent whose exponent character is 'd', not 'e', like > "3.1415926535d0") was rejected for compatibility reasons; intuiting the > type from the length of the string or somesuch is, I agree, nightmarish. > The only alternative is to require it to be stated explicitly somehow; > the question is whether the default should be "double" or "float". ("long" > constants already require the length to be specified explicitly, by a > trailing "L".) I see no real problem with C floating-point constants continuing to be interpreted as double-precision. Examples: #define PI 3.14159etc. /* who knows how it's going to be used? */ float value = 1.5; /* compiler can figure this out */ double value = (float)1.5; /* throwing away precision for some reason */ float value = (float)atan2( 0.5, 1.0 ); /* args must be doubles */ Also, remember that such constants are currently doubles and any change needs to preserve this property to avoid breaking existing correct code. (float) is simple, unambiguous, and seldom explicitly required.
hansen@pegasus.UUCP (Tony L. Hansen) (10/22/84)
<And people who want to put tables or strings into shared code space, although <there you can get away with them being in non-shared and writable data space. One thing that comes up is some way of automatically making the format string arguments to printf statements be "const". (There are people who actually wanted to make all character strings be of type const by default.) It turns out that this is trivial if one uses the proposed function declaration syntax to say that the printf's first argument is a "char *const". The compiler can look at that, see that the string will never be changed and place the string into readonly (and potentially sharable) dataspace. I'm excited about this possibility. Tony Hansen pegasus!hansen