From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.107.11.227 with SMTP id 96mr3019991iol.129.1523478703000; Wed, 11 Apr 2018 13:31:43 -0700 (PDT) X-Received: by 2002:a9d:bc8:: with SMTP id 66-v6mr375381oth.10.1523478702582; Wed, 11 Apr 2018 13:31:42 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!peer02.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!k65-v6no129306ita.0!news-out.google.com!u64-v6ni147itb.0!nntp.google.com!k65-v6no129300ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 11 Apr 2018 13:31:42 -0700 (PDT) In-Reply-To: <87in8xwmx0.fsf@nightsong.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <552a0627-2a6f-4b51-a1a0-fdc70cc210a7@googlegroups.com> <87in8xwmx0.fsf@nightsong.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6975300f-6280-4a45-90fe-75edb881ba26@googlegroups.com> Subject: Re: Ada Implementation of functions and produce C for exotic architectures (Expressif) From: "Dan'l Miller" Injection-Date: Wed, 11 Apr 2018 20:31:42 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4776 X-Received-Body-CRC: 1645644835 Xref: reader02.eternal-september.org comp.lang.ada:51449 Date: 2018-04-11T13:31:42-07:00 List-Id: 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 >=20 > 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. >=20 > 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 la= nguage: C is syntactic/semantic =E2=80=A2near=E2=80=A2-isomorph of PDP-11 assembly = language [on processors whose behavior sufficiently resemble PDP-11's behav= ior. The more the processor's behavior diverges from PDP-11's behavior, th= e more the undefined behavior does something different than what C on PDP-1= 1 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 undefine= d behavior (to which the standard will speakest no more of the topic) or b) provides some rudimentary information for the programmer's optional usag= e to discover the limits of how much this processor resembles versus extrap= olates PDP-11 (e.g., MAX_INT).] Not all undefined behavior is created equal though. Relying on undefined b= ehavior regarding pointers is usually fatal eventually, perhaps even on the= original processor, not even when porting yet; pointer-related undefined b= ehavior is pure-evil mortal sin that usually results in the capital punishm= ent 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: Rely= ing numerous times on undefined behavior regarding integers is commonplace = in C and C++, especially regarding char, short, int, long, long long instea= d 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-uti= lized bit-pointers; ASCII characters are in the range 128 to 255; schizophr= enia 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/Powe= rPC, AMD64, 2900, 6800, 68000, 6502, 88000, Z80, 8085, 16016, 32032, DEC VA= X, Alpha, and so forth processors & microprocessors & embedded controllers = since the 1970s have an ISA behavior that sufficiently resembled PDP-11 (li= kely intentionally) enough that various integer-related undefined behavior = causes noticeable bugs at a manageably-infrequent rate (e.g., once per chan= ge to different processor by management or at Apple once a decade or so).