Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: What is wrong with malloc?
Date: Thu, 9 Jan 2025 18:12:44 +0200
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <20250109181244.00001ef4@yahoo.com>
References: <vljvh3$27msl$1@dont-email.me>
	<vlle1n$2n1b0$1@dont-email.me>
	<vlm2tg$2dkpd$3@dont-email.me>
	<vlm8gd$2rfbl$2@dont-email.me>
	<vlma2d$2qolo$1@dont-email.me>
	<8734htrrbe.fsf@nosuchdomain.example.com>
	<vlmn36$2u3c1$1@dont-email.me>
	<87ldvlq8yw.fsf@nosuchdomain.example.com>
	<vlnlmb$37dk6$1@dont-email.me>
	<87cygwr1n6.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 09 Jan 2025 17:13:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="64cba65af7d6378e4f20d4ad73b70380";
	logging-data="3590799"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Ng4pE6jUucU522vOdSB8MogkFmyMEdcw="
Cancel-Lock: sha1:l+E+qYLRqy2cT/q9PidzLfF5Bpw=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 5665

On Wed, 08 Jan 2025 21:34:37 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> Phillip <nntp@fulltermprivacy.com> writes:
> > On 1/8/25 4:41 PM, Keith Thompson wrote:  
> >> Phillip <nntp@fulltermprivacy.com> writes:  
> >>> On 1/8/25 3:20 PM, Keith Thompson wrote:  
> >>>> Phillip <nntp@fulltermprivacy.com> writes:
> >>>> [...]  
> >>>>> C89 and C90 are better for 8-bit systems then C99 and newer.
> >>>>> Not that you can't do 8-bit on C99 but it's just not designed
> >>>>> as well for it since C99 assumes you've moved on to at least
> >>>>> 16-bit.  
> >>>> There were no changes in the sizes of the integer types from
> >>>> C89/C90 to
> >>>> C99, aside from the addition of long long.  (And an
> >>>> implementation with 8-bit int would be non-conforming under any
> >>>> edition of the standard, though it might be useful.)  
> >>>  
> >>>> Perhaps some C89/C90 implementations are better for 8-bit
> >>>> systems than some C90 implementations?  
> >>>
> >>> Yes, this is what I was saying.  
> >> I'm curious about the details.  What C89/C90 implementation are
> >> you using, and what features make it more suitable for 8-bit
> >> systems?  (Any useful extensions could be applied to a C99 or
> >> later implementation.  It sounds like the implementer just hasn't
> >> done that.)  
> >
> > Generally this only applies to use cases where specific instructions
> > generated by the compiler are different between c90 and c99 where
> > TOE's matter (timing of execution). For example, there are cases
> > (sorry I don't have examples because it's been a long time since
> > I've gone through this) where c99, in order to be more efficient,
> > will output a different set of instructions, but in certain cases,
> > those instructions, while more efficient, take longer to process on
> > the CPU or microcontroller. Whereas C89 and C90 may be more
> > inefficient but the instructions execute faster. It might only be
> > that C99 adds an extra 1-3 clock cycles, and in most cases this
> > isn't a problem or noticeable. But when you are dealing with
> > devices that are responsible for keeping a human alive (such as a
> > pace maker) the extra cycles can add up over time and will cause
> > trouble down the road. So this was the purpose behind my point of
> > reference earlier was just to say, that there are niche cases where
> > the statement that was made, wouldn't be accurate.  
> 
> Are you saying that, for example, "gcc -std=c90" and "gcc -std=c99"
> are generating different instruction sequences for the same code,
> with the same version of gcc in both cases?
> 
> Hmm.  I can't think of anything in the changes from C90 to C99 that
> would necessarily cause that kind of thing.  Unless I'm missing
> something, it's not C99 that results in the "more efficient"
> instructions, it's the behavior of the compiler in C99 mode.
> It could as easily have been the other way around.
> 
> > For pace makers the GNU GCC implementation was used and for the
> > smart prosthetic the CLANG implementation was used. GCC was using
> > C90 and CLANG was using C89 (ANSI).  
> 
> Note that C89 and C90 are exactly the same language.  The 1990 ISO C
> standard is identical to the C89 standard, except for some
> introductory sections introduced by ISO.  (I've heard vague rumors of
> some other differences, but as far as I know there's nothing
> significant.)
> 
> > Although above I couldn't provide a specific example (again sorry
> > about that) I do have the result report from back when I was testing
> > out pace makers with C99 over C90 (2007) and the process found that
> > with C99 the processor would be behind by around 500 cycles within
> > 19h 41m 19s from program start. This had a +/- of 12 cycles
> > differential with repeat testing. That would mean the heart would
> > miss a beat ever 17 days.  
> 

The most likely difference is mentioned by David Brown in the post
above.

int div8(int x) { return x/8; }

C90 compiler can turn a division into arithmetic right shift. C99
compiler can not do it. If compiler wants to avoid division, it will
have to generate more elaborate sequence.

In case of gcc, it does not apply because gcc follows c99 rules
regardless of requested language standard. But it can be the case for
other compilers.