Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!hao!husc6!necntc!ima!haddock!karl
From: karl@haddock.UUCP
Newsgroups: comp.lang.c
Subject: Re: Types
Message-ID: <546@haddock.UUCP>
Date: Thu, 11-Jun-87 19:35:07 EDT
Article-I.D.: haddock.546
Posted: Thu Jun 11 19:35:07 1987
Date-Received: Sat, 13-Jun-87 09:42:45 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP> <293@osupyr.UUCP> <1173@ius2.cs.cmu.edu> <541@l.cc.purdue.edu>
Reply-To: karl@haddock.ISC.COM.UUCP (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 87

In article <541@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>>>1.  Have the compiler substitute locations in -asm- statements.
>>>Other than editing the assembler output, I do not believe there
>>>is any way to insert asm statements which can be expected to
>>>survive a change from one compiler to another.
>
>For example, suppose that the variable j has just been computed, and I want
>to transfer on overflow to loc.  On the VAX, in C this is
>	asm("	jov	xxx,LLL");
>[where xxx and LLL are the assembler's names for j and loc].  The only way I
>have been able to do this is to put in something for xxx and LLL, get the
>assembler listing, and then edit it.

If you're arguing that vendors should implement such a feature, I agree; it
makes asm() much more useful.  But there is no way this could be standardized.
ANY use of asm() is both machine- and compiler-dependent.  X3J11 does not
require that an implementation support asm() (it's a "Common Extension") or
even that it have an assembly pass.

>>>2.  Require that the compiler honor, whenever possible, assignments
>>>to registers.

This is meaningless.  The standard says nothing about machine registers; it
knows nothing about the underlying hardware.  (Even the rule that integers are
stored in binary is covered by the as-if rule.)  Whether a compiler is
conforming depends only upon the output of programs compiled by it.

>On the VAX, the compiler only lets me use half of the registers, and in cases
>in which I wish to specify that a variable be in a specific register, it
>refuses completely.  It refuses to put floating and double variables in
>registers.  Also, using C compilers for both the VAX and the PYRAMID,
>I have been unable to get the compiler to put a one-word union in a register.

Complain to the vendor, not the standards committee.

>>>3.  Allow the programmer to force non-promotion of floating to double,

Compilers are now free to use single-precision for float-only arithmetic.
Function arguments are promoted from float to double only in the absence of a
prototype.

>[Eddie Wyatt writes:]
>>	But heres the problem - floatfunc(3.0),  should 3.0 be pass as
>>	a float or a double?  To complicate matters, say floatfunc is
>>	external. Function prototypes may take care of this though.

They do.  Also, "3.0" is a double whereas "3.0F" is a float.  (This doesn't
affect your example, which should treat "3.0" and "3.0F" identically.)

>>>Also, on some machines, one cannot print out a floating number in hex.

If you want to pass an unpromoted float to printf("%x"), you'll have to use
something nonportable no matter what -- enclosing the float in a union, as
suggested by Eddie, is probably best.  Note that the number of "%x"'s is also
machine dependent.

>>>4.  Allow floating point numbers to be given in hex.  Try putting in
>>>2^-32 as a floating point or double constant.  Why should one have to
>>>risk computer roundoff when it is totally unnecessary?

If you mean you want to specify the bit-pattern of the floating-point number,
you can use a union or a pointer-cast.  (And I have no sympathy if your
program fails to port.)  I'll assume you just want base-16 scientific
notation.

One solution is to evaluate 2^-32 by some other means (e.g. "dc") and type in
the decimal digits.  When I give the compiler a decimal representation of a
floating-point number, I expect it to generate the nearest possible number.
If it didn't, I'd complain to the compiler vendor.

Alternately, you could write an expression such as 1.0/1024.0/1024.0/4.0; any
decent compiler will do the arithmetic at compile-time.

>>>5.  Require that the compiler honor parentheses.  When I want a
>>>subroutine to return (x - y - k*c) + f(y), I most emphatically do
>>>not want the compiler to do the "obvious" rearrangement to combine
>>>the two terms with y; this can be a major loss of accuracy.  To set
>>>a variable equal to the parenthetical expression is a significant
>>>loss of time.

Unless I specify otherwise (with unary plus), I most emphatically *do* want
the compiler to rearrange such an expression if that makes it more efficient.
(Btw, even assigning to a kludge variable (the pre-ANSI way to do this) need
not be a "significant loss of time" -- the optimizer should be able to note
that the variable is dead, and not bother to store it anywhere.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint