Re: Ada Implementation of functions and produce C for exotic architectures (Expressif)

["Dan'l Miller" <optikos@verizon.net>]

On Wednesday, April 11, 2018 at 2:41:49 PM UTC-5, Paul Rubin wrote:
> "Dan'l Miller" writes:
> > C is not a backend target of the GNAT compiler, despite C being a
> > syntactic/semantic near-isomorph of PDP-11 assembly language
> 
> People erroneously believe that and then freak out when they find it
> isn't true.  Consider signed arithmetic overflow being twos-complement
> arithmetic in PDP-11 assembly language, vs being undefined behavior in
> C.  In Ada it's supposed to signal a constraint error iiuc.
> 
> So C wouldn't really be a natural target for an Ada compiler.  C is not
> a "portable assembler" despite the wishes or dreams of some of its
> users.

Allow me to amend in overt words what was previously implied in unstated language:
C is syntactic/semantic •near•-isomorph of PDP-11 assembly language [on processors whose behavior sufficiently resemble PDP-11's behavior.  The more the processor's behavior diverges from PDP-11's behavior, the more the undefined behavior does something different than what C on PDP-11 did.  C usually doesn't rectify divergent-from-PDP-11 behavior; C usually either
a) simply washes their standardization hands of it by declaring it undefined behavior (to which the standard will speakest no more of the topic)
or
b) provides some rudimentary information for the programmer's optional usage to discover the limits of how much this processor resembles versus extrapolates PDP-11 (e.g., MAX_INT).]

Not all undefined behavior is created equal though.  Relying on undefined behavior regarding pointers is usually fatal eventually, perhaps even on the original processor, not even when porting yet; pointer-related undefined behavior is pure-evil mortal sin that usually results in the capital punishment of a crash.

But then there are categories of C's undefined behavior that are more like a white-lie fib in most cases, rather than capital-punishment crimes:  Relying numerous times on undefined behavior regarding integers is commonplace in C and C++, especially regarding char, short, int, long, long long instead of int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t, as well as various dubious typecasts, as long as one is not porting to one of the astronomically weird processors:
1) Prime 50 series (e.g., no 8-bit byte addresses other than via seldom-utilized bit-pointers; ASCII characters are in the range 128 to 255; schizophrenia of sorts between 16-bit char holding one character or two packed 8-bit characters)
2) the GE and Honeywell processors that Multics ran on (e.g., 9-bit bytes; 36-bit integers)
3) various modern-era FPGAs with parity turned off (e.g., 9-bit bytes)
4) various modern-era DSPs (e.g., 32-bit bytes)

Fortunately for the cavalier C community, IA32, IA64, MIPS, ARM, POWER/PowerPC, AMD64, 2900, 6800, 68000, 6502, 88000, Z80, 8085, 16016, 32032, DEC VAX, Alpha, and so forth processors & microprocessors & embedded controllers since the 1970s have an ISA behavior that sufficiently resembled PDP-11 (likely intentionally) enough that various integer-related undefined behavior causes noticeable bugs at a manageably-infrequent rate (e.g., once per change to different processor by management or at Apple once a decade or so).