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 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: References: <8734htrrbe.fsf@nosuchdomain.example.com> <87ldvlq8yw.fsf@nosuchdomain.example.com> <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 wrote: > >> Phillip writes: >>> On 1/8/25 4:41 PM, Keith Thompson wrote: >>>> Phillip writes: >>>>> On 1/8/25 3:20 PM, Keith Thompson wrote: >>>>>> Phillip 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. ----------