Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Phillip <nntp@fulltermprivacy.com>
Newsgroups: comp.lang.c
Subject: Re: What is wrong with malloc?
Date: Thu, 9 Jan 2025 12:40:46 -0500
Organization: A noiseless patient Spider
Lines: 103
Message-ID: <vlp1mu$3fbqf$1@dont-email.me>
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>
 <20250109181244.00001ef4@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 09 Jan 2025 18:40:47 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1cf704d4f015a397c8db2e3a3fdf9b7b";
	logging-data="3649359"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Y3dianzF6HaFQS6BCuGRiydKQdHryWts="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:v+CFxUBsm688oTE4EE4uwn2NCa4=
Content-Language: en-US
In-Reply-To: <20250109181244.00001ef4@yahoo.com>
Bytes: 6170

On 1/9/25 11:12 AM, Michael S wrote:
> 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.
> 
> 
> 
> 

I'd have to go back and look. There isn't that much division in pace 
makers but there is some nuance there that is likely the case for more 
then just division.

-- 
Phillip Frabott
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------