Path: ...!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 00:09:31 -0500
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <vlnlmb$37dk6$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 09 Jan 2025 06:09:32 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1cf704d4f015a397c8db2e3a3fdf9b7b";
	logging-data="3389062"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+/1rJpM/TKvCkLcsWKlf3BHYh+gCzu4+s="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:iU4PDTnWg+QQ/NPCH8Yeu4M0GPA=
Content-Language: en-US
In-Reply-To: <87ldvlq8yw.fsf@nosuchdomain.example.com>
Bytes: 4178

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.

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).

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.

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