Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: What is wrong with malloc? (Was: So You Think You Can Const?)
Date: Thu, 9 Jan 2025 13:15:01 +0100
Organization: A noiseless patient Spider
Lines: 117
Message-ID: <vloek6$3bs33$1@dont-email.me>
References: <vljvh3$27msl$1@dont-email.me> <vlle1n$2n1b0$1@dont-email.me>
 <vlm2tg$2dkpd$3@dont-email.me> <vlm8gd$2rfbl$2@dont-email.me>
 <vlma2d$2qolo$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 09 Jan 2025 13:15:13 +0100 (CET)
Injection-Info: dont-email.me; posting-host="66dd8da1d51423fd8b5c2136ec2c7fdd";
	logging-data="3534947"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+T/UXkk3J1B8/pvEPCUC4xTZZd6xedtHw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:GVtXbV4khW3AzSAJaIK5kUb8E08=
In-Reply-To: <vlma2d$2qolo$1@dont-email.me>
Content-Language: en-GB
Bytes: 7576

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