Re: What is wrong with malloc? (Was: So You Think You Can Const?)

On 08/01/2025 17:45, Phillip wrote:

On 1/8/25 11:18 AM, David Brown wrote:

For people using 8051, COP8, 68HC05, PIC16 or other long outdated brain- dead microcontrollers, you don't get standard C support at all. You program these in a device-specific variant of C full of extensions and extra restrictions - and the support is as close to the subset of C99 that I described as it is to standard C90.

 Just a point of reference, there are still several "brain-dead" systems in modern use today that aren't old, some being invested as late as 2019.

There are very few new versions of 8-bit CISC microcontrollers being developed - the rate has been dropping steadily since the Cortex M family rose to dominance.  The decay is probably approximately exponential, in terms of development of new devices, production and sale of existing devices, and development of new products using these devices.  They are not /all/ gone - but you need /very/ good reason for considering them for anything new, whether it is software or hardware.
The only 8-bit core that can be viewed as "alive and well", is the AVR. It is a RISC design and a good deal more C and general software friendly than these other devices.  The most common toolchain for the AVR is gcc, and you can use normal standard C with it.  You do have to consider some of its idiosyncrasies if you want efficient results, but you /can/ write normal C code for it.

That being said, your comment isn't completely accurate in that, there are some modern uses of things like the 6502 that can use standards-based C. In fact, you can use ANSI C89 and C90 with the 6502.

The 6502 is one of the better 8-bit cpu cores - you can get reasonable code with mostly standard C (C99 if you like) using a compiler like SDCC.  You don't /need/ as many extra target-specific keywords and extensions to deal with multiple memory banks, independent address spaces for ram and constant data, long and short pointers, non-recursive functions, and so on, as you need for useable results on an 8051 or PIC.   But you probably still use some of these to get efficient results, such as choosing which variables go in the fast zero page area.
Also note that there is a huge difference between being able to write significant parts of the code for a microcontroller using only standard C, and being able to use a significant fraction of the standard C language and library (at least the "freestanding" part) in your code. For example, I've used a compiler for the PIC16 that supported structs and arrays, but not arrays of structs or structs containing arrays.  If the code does not use these features, you can write it in standard C - but plenty of perfectly ordinary standard C code would not work with that compiler.
There is also a huge difference between being /able/ to write the code in only standard C, and pure standard C being an appropriate way to write the code for the microcontroller.  Using the target-specific features of these kinds of devices and their tools makes a massive difference to code efficiency.  Basically, if you are trying to stick to pure standard C for an 8051 or 68HC05, you are doing it wrong.

I've done this for several modern pace makers as well as a smart prosthetic. So your statement is correct in 90% of cases but not all cases.

I believe that goes under the category of "niche" :-)  For some types of application, you stick to what you have tested - no one wants to have the first pacemaker with a new microcontroller!
Of course in this field there are always exceptions - no generalisation is going to be correct in absolutely all cases.  But I'd guess my statement was accurate in 99.9% or more cases.

 (Also most car manufacturer's use the 6502 and other variants for their digital input analog gauges and warning light controls on their dashboards.)

Have you a reference for that claim?  I am very confident that it is not the case.  The 6502 was primarily developed as a microprocessor core, not a microcontroller core - it was found in early microcomputers and games consoles.  It was also used in early embedded systems, but once microcontrollers became common, they dominated quickly in numbers. (Microprocessors were used for high-end embedded systems, like embedded PC's with x86 cpus and network equipment with m68k processors.)  I don't know that the 6502 was ever common in the automotive industry - but I can't believe it was ever used by "most" car manufacturers.

 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.
 

My point is that almost no general-purpose software written now will ever be used on 8-bit devices, especially not 8-bit CISC cores.  For most software written on these cores, standard C is not a practical option anyway.  And the cores are used in very conservative situations, such as when there is a lot of legacy code or when many years or decades of field testing is important - new external software will not be used by such developers.  So it makes no sense to me to restrict the code to an old standard because of the /tiny/ chance that there is someone who might want to use it on such devices.
I also disagree completely that C90 is somehow a better fit for 8-bit devices than C99.  It is not.  C has /always/ expected at least 16-bit - it's not something new in C99.  Apart from VLA's, there is nothing in C99 that would result in code generation that is a poorer fit for these devices than C90.  There are some sort-of-C compilers for 8-bit microcontrollers that have 8-bit ints or do not follow the C rules for integer promotions - these are, of course, no more standard C90 compilers than they are standard C99 compilers.

But this is all based on the OP's specific use case for their application. I just wanted to chime in since I do primarily work on modern embedded systems that don't use "modern" microcontrollers and CPU's since they are still used in a wide range of modern devices that people don't even realize.