osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (02/12/85)
mod.std.c Digest Tue, 12 Feb 85 Volume 3 : Issue 1
Today's Topics:
Comments on machine cycles generated by C statements
union initialization and paper proposals
What is the current standard?
----------------------------------------------------------------------
Date: Wed, 6 Feb 85 09:54:59 pst
From: cbosgd!sdcrdcf!dataio!weil (Steve Weil)
Subject: Comments on machine cycles generated by C statements
To: sdcrdcf!cbosgd!std-c
This is my first posting to this newsgroup, and I have not always
followed the discussions, so please forgive me if this has been
covered.
It has been mentioned several times that device drivers do things which
are not guaranteed to be portable. While this may be inevitable, it is
desirable that on a given machine you could replace the compiler,
recompile the device driver and not break it. It is also possible that
on a VME bus or Multibus you would change the family of processor (and
compiler) but keep the same peripherals and you would not want to have
to rewrite the device drivers.
So we should try to list the assumptions about the compiler that most
device drivers make so these can be required or at least recommended
for compilers which follow the standard.
The most common assumption, which to my knowledge is NOT required by
the standard, is that an access to a byte sized object (variable or
structure field) results in an 8-bit data transfer on the bus, and an
access to a 16-bit object results in a 16-bit transfer.
Now I know that I am already making assumptions about the machine in
use by using these absolute sizes, but:
IF a machine has a data type which is 8 bits long, AND it has byte
addressable memory (or memory mapped I/O), is there any reason not
to require that the above assumptions be followed?
It is very common to define a structure as an image of some hardware
registers and then to read and write to fields in that structure to
poke the hardware. We should try to define those operations as well as
possible within the restrictions of the standard.
Some related issues:
Bit field operations may effect an unknown sized region of data
surrounding that bit.
If a data type which is longer than the bus width (or which is not
optimally aligned) is accessed then an unknown number of bus cycles
may occur in an unknown order.
Consider the following fragment:
long int x;
...
x |= 1;
Is it legal for the compiler to generate a shorter instruction than
a long access since it can determine at compile time that only the
low bits of 'x' will change ? (This would be a speedup on a 68K or
32016.) If 'x' is declared as a volatile is a full long transfer
required?
I am not trying to solve these issues on the spot, or trying to push
for any particular resolution, I feel these are real issues and I am
not sure if they have been adequately discussed yet. I believe that
the standard could be made more specific on some of these issues
without breaking much (if any) code and doing so would define the
language more accurately.
Steve Weil Data I/O
dual!unisoft!teltone!dataio!weil entropy!dataio!weil
------------------------------
Date: 30 Jan 85 20:02:38 CST (Wed)
From: cbosgd!ihnp4!utzoo!henry
Subject: union initialization and paper proposals
To: ihnp4!cbosgd!std-c
I think the people responding to Larry Rosler's comments on union
initialization are missing an important point. As far as I know,
nobody contends that the first-member rule for union initialization
is beautiful. The key point is: there is real live experience
with this rule, with a real compiler and real customers. In other
words, it is known to work in practice, not just theory. This is
of considerable importance when something is to be enshrined in a
standard. I'm not aware of comparable real-life use of any of the
various other proposals. Careful contemplation is *not* the same
thing. Standards committees have good reason for taking field-proven
proposals much more seriously than untried ones. Avoiding subtle
disasters is more important, for a standard, than maximizing beauty.
This is not to say that I like first-member union initialization.
Personally, I think it should have been "done right" (although I'm
not sure just how to do that) or ignored. If I'd been a committee
member, in the absence of field-proven "done right" solutions,
I think I'd have voted for ignoring the whole issue. Oh well.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: 2 Feb 85 04:00:51 CST (Sat)
From: cbosgd!ihnp4!utzoo!henry
Subject: What is the current standard?
To: ihnp4!cbosgd!std-c
> Well, we all remember that K&R is not a standard, but it is an attempt
> to describe how the language works. At best it is *de-facto*
> standard. However, since this feature is "omnipresent in UNIX C
> compilers" (it is also true in DECUS C, and probably in others), that
> sort of seems like a de-facto standard, too. So, which de-facto
> standard are you going to follow?
The usual custom is to say that the "correct" behavior is defined by
the documentation, not the code. Note that most of the world's C
compilers are *not* Unix C compilers, and probably most of them were
written from the documentation, i.e. K&R for openers.
> If all UNIX C compilers use it, and many other C compilers use it, too,
> it seems to me that we should be centering the standard around the
> language *as used*, not according to K&R.
I'd like to see some evidence for that magic word "many" before going
along with this. There are a lot of C compilers in the world nowadays,
many of them not Bell-derived. I'm unsure just how many of them follow
the Reiser preprocessor rather than K&R, but I have my doubts.
> ... Note that, as it stands, the
> existence of parameter replacement inside strings cannot be a
> non-standard extension since there is no standard and it is extremely
> common...
"No standard"? Come now. The C Reference Manual, as published in K&R
and (in later versions) in the Unix documentation, may not have been
formally blessed by anybody in particular, but it's most assuredly
what a compiler implementor would have pointed to as "the standard"
before ANSI started work.
> ANSI standard ought to encompass normal usage, and this is part of
> normal usage.
"Normal usage" *where*? Defining "normal usage" as "the way I do it"
or "the way it's done on my system" is not really satisfactory. The
question is, how widespread is use of the Reiser features? I wonder
about this, particularly since they are undocumented and thus unportable.
> ... we surely can do something as reasonable as not
> break C code written under UNIX.
Again, C code written where, and by who? Most C code under Unix that
I'm aware of uses none of these features.
> I consider myself an informed C
> person, but this is the first time it has come to my attention that
> this is not in K&R. ...
All I can say is that people who are seriously concerned about portability
have to be aware of these things.
> Shall we hew to [K&R] or to broad, nearly universal, actual usage?
Again, it seems to me that you have presented little or no evidence for
the bold claim of "nearly universal" usage.
> I must also disagree with the last statement about any replacement for
> this feature. There is no replacement in the standard. If there is no
> parameter substitution in strings, concatenation of strings doesn't
> solve anything.
Sure it does:
#define DIR "/usr/somewhere"
char *sysfile = DIR "/sys";
produces a value of "/usr/somewhere/sys" pointed to by sysfile. It's
certainly my impression that this has been the single biggest use of
substitution within strings, although it's unportable enough that B
news, for example, has to do the equivalent at run-time.
> ...the committee is willing to protect people with archaic loaders
> from working around it, but its okay to break a bunch of Berkeley 4BSD
> code? That's weird. ...
Not really. There *is* no satisfactory workaround for an archaic loader.
(As I have said before, if you think otherwise, put your money where
your mouth is by convincing a major manufacturer of this. Then I'll
believe you.) And the committee was explicitly constrained to avoid
breaking programs which (a) were legal C, and (b) did not depend on
implementation-specific extensions. Their job would have been impossible
if they weren't allowed to break anything anywhere. If a bunch of 4BSD
programs will break as a result, I'm afraid this says more about the
code quality and level of concern for portability in 4BSD, than about
the ANSI people.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
End of mod.std.c Digest - Tue, 12 Feb 85 04:50:37 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> replies to cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.
--
Orlando Sotomayor-Diaz /AT&T Bell Laboratories, Red Hill Road
/Middletown, New Jersey, 07748 (HR 1B 316)
Tel: 201-949-9230 /UUCP: {ihnp4, houxm}!homxa!osd7