Re: What is wrong with malloc?

On Thu, 9 Jan 2025 14:53:56 +0100
David Brown <david.brown@hesbynett.no> wrote:

On 09/01/2025 06:09, Phillip wrote:

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.

 
I'm sorry, none of that makes /any/ sense at all to me.
 
Different compilers and different compiler versions may emit
different instructions with different timings - that is independent
of the C standard version.  There is almost no code you can write
that is valid C89/C90 (C89 so-called "ANSI C" and C90 ISO C are
identical apart from the numbering of the chapters) and also valid
C99, but that has different semantics.  There were changes in the
types of certain integer constants, and division in C99 with negative
values is defined to be "truncate towards zero", while in C90 an
implementation could alternatively choose "truncate towards negative
infinity".  However, it is highly unlikely that a single compiler
that supports both C90 and C99 modes would use different signed
integer algorithms in the different modes.
 
It sounds more likely that you are simply using different compilers -
and then it is not surprising that there are differences in the
generated instructions.  It's like comparing a green car with a red
bus and concluding that green things go faster than red things.
 
I also note that you earlier said you used a 6502 on these devices -
neither gcc nor clang have ever supported the 6502 as a target.
 
And if your pacemaker is relying on the timing of instructions
generated by a C compiler for the timing of heart beats, then you are
doing the whole thing /completely/ wrong.  It doesn't matter what
compiler and what language you are using, that's not how you handle
important timing in embedded systems.
 
Then you talk about missing a heart beat every 17 days.  I presume
you realise how absurd that is?  Just considering the timing alone,
that's a accuracy of about 0.7 ppm (parts per million) - about a
thousand times more accurate than common oscillators used with small
microcontrollers.

Off topic nitpick:
0.7 ppm * 1000 = 700ppm.
Last time I looked, 50-70 ppm crystal oscillators were cheaper than less
precise parts.
Alternatively for cheap crystal-less clock source the expected
precision is closer to 7000 ppm than 700.

It takes a fairly sophisticated and expensive
timing circuit to reach those levels (though in a pacemaker you have
the benefit of a stable environment temperature).  But this is not
just measuring time for the sake of it - you are talking about heart
beats.  If your system is running 0.7 ppm slower than before, the
heart will not skip beats - it will beat at a rate 0.7 ppm slower,
and that will make not the slightest difference.  I am not a doctor
(though I have worked on heart rate measurement devices), but I would
not expect any medically significant differences before you were at
least a few percent out on the timing. In a normal healthy heart,
beat-to-beat variation can be 10% while still considered "normal".
In fact, if it is /not/ varying by a few percent, it's an indication
of serious health problems.
 

I tried to use provided numbers to estimate a clock rate of Phillip's
processor. Got 10 KHz. I am aware of ultra-low-power CPUs that run at
32KHz, but never encountered anything slower than that.

 
But I don't expect anyone will want to use AVL trees in a pacemaker
anyway :-)
 

I like AVL trees. Not 100% sure how exactly I can apply them in pace
makers, but I'd certainly try my best.