Re: What is wrong with malloc?

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