Re: What is wrong with malloc?

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.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */