Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.lang.c
Subject: Re: Types
Message-ID: <8067@utzoo.UUCP>
Date: Sat, 23-May-87 20:47:13 EDT
Article-I.D.: utzoo.8067
Posted: Sat May 23 20:47:13 1987
Date-Received: Sat, 23-May-87 20:47:13 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP>, <293@osupyr.UUCP> <8024@utzoo.UUCP>
Organization: U of Toronto Zoology
Lines: 53

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

You are almost right:  there is *no* way to insert asm statements which
can be expected to cross compiler boundaries.  Note that compilers are not
required to (a) implement asm statements at all, or (b) generate assembler
output at all.

More generally, there is a problem in that the legal ways of using a
C variable in assembler are highly variable, a function of the compiler
as well as the machine.  For example, on many RISC machines the only
memory-reference instructions are Load and Store.  This means that the
extent to which the compiler puts variables into registers will *greatly*
influence how you write code with asm.  Whether a given variable is a
legal operand for a particular instruction will be very compiler-dependent.
This problem simply has no general solution.  Such a requirement would
degenerate to a motherhood like "the compiler should be as helpful as
possible to assembler programmers", which is (a) useless and (b) not an
obviously desirable statement.

Note that asm is not in X3J11 C at all, except for a mention in the
"Common Extensions" appendix.

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

Please define "whenever possible".  Most programmers would applaud a
compiler that made the code run faster at the cost of sometimes disregarding
"register" directives.

>	3.  Allow the programmer to force non-promotion of floating to double,
>	whenever the programmer feels there is a good reason to do this.

X3J11 already makes this an option for compilers.  Some mandatory way of
doing it might be useful, but it's a secondary issue:  compiler implementors
whose customers are concerned about numerical issues will do it as a matter
of course.

>	4.  Allow floating point numbers to be given in hex...

This can already be done, albeit clumsily and in somewhat machine-dependent
ways.  However, since those adverbs also apply to doing it in hex, I see
no reason for action on this.

>	5.  Require that the compiler honor parentheses...

This is somewhat defensible in floating-point arithmetic, but a major loss
otherwise.  "If you want Fortran, you know where to find it."
-- 
"The average nutritional value    Henry Spencer @ U of Toronto Zoology
of promises is roughly zero."     {allegra,ihnp4,decvax,pyramid}!utzoo!henry