Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Portable 16 bit binary integer write Date: Mon, 19 Sep 2016 11:26:21 -0700 Organization: None to speak of Lines: 63 Message-ID: References: <50a1e8f4-4fb3-4491-97d0-54768bf28685@googlegroups.com> <4fde1133-61ff-4045-9cbe-cccff1408ad3@googlegroups.com> <0b757bbb-0494-44cb-bd5a-26f117aaa404@googlegroups.com> <2cf666d7-0755-4c70-adad-07dbafc2b2e7@googlegroups.com> <09cb4413-16a6-4b63-89d0-9dafe56562f6@googlegroups.com> <68e53f3a-5fcc-44fc-90c4-bcf8dc3db680@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="4122"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+hi6CxuEVo5ovOxkDH/Dee" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:7tTZMn/2I78fSfPE2Mc+sSxSjlc= sha1:1mzzY7Azq70R1mJmOmVBkMCCJhQ= Xref: csiph.com comp.lang.c:93809 David Brown writes: [...] > Perhaps the more significant change is that currently the C standards > document are each written to succeed and replace previous versions. > There is only one current valid ISO C standard - the version known as > C11. A "C compiler" made today has to follow that version of the > standard. If a future C standard dropped support for some older > hardware, then there would really need to be a fork in the standards - > so that C11 would still be a valid standard for old systems, with C20 > (or whatever) going onward for modern ones. The previous editions of the standard are officially obsolete in the eyes of ISO. That doesn't prevent anyone from using them. I'm not convinced that a formal fork would be necessary. Implementations could still claim C99 or C11 conformance. [...] > No, 64-bit int is not a sensible idea (IMHO). Extended integer types > could solve some of the problems it would create, but at significant > effort to toolchain authors, library writers (someone has to make a > "printf" that supports the different sizes in some way), and significant > inconvenience in data exchange. It is data exchange (by network > protocols, file formats, etc.) that drives the need for standardisation > here. N1570 6.2.5p5: A "plain" int object has the natural size suggested by the architecture of the execution environment [...]. For a 64-bit target, surely 64 bits is "the natural size suggested by the architecture". > And what is to be gained with 64-bit int? There is some hardware that > can operate more efficiently on a 64-bit object than a 32-bit object - > but such hardware is niche or obsolete (i.e., old Cray machines), and > therefore excluded. Is there any software benefit in having 64-bit int? > I think not - it is rare indeed that you actually need such a large > integer type, and C already has perfectly good ones that you can use in > that case (int64_t and long long int). I haven't looked into the relative performance of 32-bit and 64-bit arithmetic on modern 64-bit systems. It seems plausible (but is quite possibly wrong) that an N-bit system will perform most efficiently on N-bit data. On the other hand, I'm sure designers have expended some effort to make 32-bit arithmetic efficient -- largely *because* C implementations typically have 32-bit int. > It is not a coincidence that the only systems with 64-bit int are > ancient, and pre-date the common usage of 64-bit processors. Are there *no* modern 64-bit processors on which 64-bit arithmetic is faster than 32-bit arithmetic? Can you be sure there will be no such processors in the future? -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"