Re: Help porting newlib to a new CPU architecture (sorta)

["Hans-Bernhard Bröker" <HBBroeker@t-online.de>]

Am 06.07.2021 um 22:46 schrieb Orlando Arias:

 > Consider the AVR architecture, where program and data spaces have
 > distinct address spaces. We have a pointer to a string literal that
 > resides in program memory.

You're already mixing stuff up again.  The memory C string literals are 
in is, by definition, _not_ program memory.  It's read-only data memory. 
  That distinction is crucial.

Small-ish embedded CPUs do not usually implement the strict Harvard 
architecture principle, precisely because that does not support constant 
data.  A strict Harvard would have all data, including the 
const-qualified parts, in RAM, and initialize it all by running a very 
boring piece of program that just writes it all using immediate 
operands.  const data would thus consume normal RAM, without any 
write-protection by the hardware at all.

Micro controller designers have pulled different kinds of tricks to get 
around the need to have constants directly in ROM, ranging from the 
simple loop-hole instruction that does read from program memory anyway 
(like the 8051's MOVC), to various kinds of mirroring schemes that just 
map ROM into data space, essentially breaking the Harvard architecture 
rather fundamentally.

But that's ultimately a problem for the implementer of the C compiler 
and run-time library to address, if they decide to try doing that on 
such small architectures.

 > The problem with this code is that we are treating a as a pointer in
 > data memory. Declaring a to be PROGMEM does not help. We actually need
 > to rewrite the code to force the compiler to use the proper instruction:
That's what you get for throwing Standard C compatibility out the window 
by declaring that string constant using a compiler extension like PROGMEM.

Generally the compiler would be required by the Standard to implement 
"generic pointers" that can reach _all_ kinds of data defined without 
use of non-standard means.  If it doesn't do that, it is by definition 
not a C compiler.  Which can be fine, e.g. if the architecture just 
cannot have a correct C implementation otherwise, or only a horribly 
inefficient one.

But porting a generic standard C library like newlib or glibc onto a 
platform that needs non-standard compiler extensions just to emulate 
strcmp() may quickly turn into a lost cause.

 > Now, I believe that doing something like (char*)fn_ptr
 > in C is either undefined behavior

It quite explicitly is.