mod.std.c Digest V9#3

[Orlando Sotomayor-Diaz]

From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>


mod.std.c Digest            Fri, 16 Aug 85       Volume 9 : Issue   3 

Today's Topics:
                   C standard for options (2 msgs)
                  Response to multitasking wishlist.
           Support for multiprocessors in C standard (wish)
----------------------------------------------------------------------

Date: Thu 1 Aug 1985 2:09
From: <ihnp4!watmath!watbun!kgdykes>
Subject: C standard for options
To: water!cbosgd!std-c

 >
 >Is the committee considering some standardization of the options? There are
 >semantics associated with these options that affect the code produced. Eg
 >
 >-Dxxxxx		make xxxxx a defined preprocessor variable
 >-Ixxxxx		xxxxx is a directory in the search list for include files
 >-O		optimize
 >-c		compile but do not remove external symbol table
 >-o xxxxx	Output file is xxxxx
 >-P		Preprocessor pass only.
 >-E		Preprocessor output also goes to stdout
 >-S		Produce assembly language file
 >
 >Most of these have already become pseudo-standards on UNIX machines, while
 >some are pseudo-standards across the board. Nailing them down would help
 >users of the C compilers make effective use of them. Maybe the committee
 >could consider a "suggestions" section for the standard in which matters
 >of standardization outside the input file could be discussed. This would
 >make it easier for a later standards body to actually go and standardize
 >things.

There are systems out there that have already defined STANDARDS for THEIR
command-line options and things like that. For instance CP5/CP6 has
all of the above mentioned options explicitly standardized in an entirely
different format/name.  I would rather the "system" be standardized, not
the language-invocation across systems.  How many normal programmers seriously
do development across different operating systems? Twould be far friendlier
for the on-one-machine users (the majority) to have all the different-language
processors behave the same.

          - Ken Dykes
            Software Development Group, U. of Waterloo
            Waterloo, Ontario, Canada.  N2L 3G1
            {ihnp4,decvax,allegra,utzoo}!watmath!watbun!kgdykes
            kgdykes%watbun at waterloo.csnet
            kgdykes%watbun%waterloo.csnet at csnet-relay.arpa

------------------------------

Date: Fri, 2 Aug 85 02:08:47 PDT
From: sun!guy (Guy Harris)
Subject: C standard for options
To: std-c at cbosgd


There is no standard (yet) for command-language syntax, so there are limits
to how much good this will do.  Furthermore, some compilers may have more
options for, say, optimizing than "optimize" and "don't optimize".
Standardizing command-line options to C compilers to this degree is not
practical.

------------------------------

Date: Fri, 2 Aug 85 09:56:19 cdt
From: rice!neuro1!baylor!kitty!peter
Subject: Response to multitasking wishlist.
To: baylor!neuro1!cbosgd!std-c

> In every C implementation I know  (XENIX286, VAX SYS5, 3B2, M68000)
> the statement
> 
> 	int a;
> 	.....
> 	if(a+=1) x;
> 	else y;
> 
> is compiled into the equivalent of
> 
> 	ADD	1 to _a
> 	JZ	label for y
> label for x
> 
> What this means is that _a is incremented and the condition code set in an
> uninterruptible single instruction.

Certain implementations (Z-80, for example) may not be able to do this. I would
support something like

	char a;
	...
	if(++a) x;
	else y;

Being atomic, since increment is an atomic operator. Not all processors,
however, have an atomic form of "add const to memory", for const <> 1.
I don't think RISC does (if you have objections to the Z80 as an example).
Any RISCy people out there care to comment?

------------------------------

Date: Fri, 2 Aug 85 02:08:47 PDT
From: sun!guy (Guy Harris)
Subject: Support for multiprocessors in C standard (wish)
To: std-c at cbosgd

1) Not all machines support "add 1 to a memory location and set the
condition codes based on whether the result is zero or not" as a single
instruction.  The IBM 360 has a C implementation, but no such instructions
(it's pretty much a load/store architecture).  As such, you're going to get
a *lot* of warnings out of C compilers if you have to be warned if this
operation can't be done in one instruction.  If your application requires
such an instruction for synchronization, you should have gotten that warning
by reading the architecture manual for your desired target machine - not by
trying to compile your application...

2) As you point out, in a multiprocessor environment you need more than an
uninterruptible instruction like that - you need one that locks out other
processors from referencing that location.  This means you need a
special-purpose synchronization primitive; different hardware provides
different such primitives, so it's not clear what a C-language primitive to
provide this would be (or how you'd provide it if the machine didn't support
it).  As such, the best you can probably do is either to use inline
assembler, a postprocessor that converts calls to a particular procedure
into such a primitive, or a C compiler that has a builtin function to access
that primitive.

------------------------------

End of mod.std.c Digest - Fri, 16 Aug 85 08:02:03 EDT
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c at BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.