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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada Implementation of functions and produce C for exotic architectures (Expressif) Date: Wed, 11 Apr 2018 17:30:05 -0500 Organization: JSA Research & Innovation Message-ID: References: <552a0627-2a6f-4b51-a1a0-fdc70cc210a7@googlegroups.com> <87in8xwmx0.fsf@nightsong.com> <6975300f-6280-4a45-90fe-75edb881ba26@googlegroups.com> Injection-Date: Wed, 11 Apr 2018 22:30:06 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="11315"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:51454 Date: 2018-04-11T17:30:05-05:00 List-Id: "Dan'l Miller" wrote in message news:6975300f-6280-4a45-90fe-75edb881ba26@googlegroups.com... ... >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) You forgot :-) the Unisys U1100/2200 series, also 9-bit bytes; 36-bit integers. We built a version of Janus/Ada for that processor targetting their C compiler code generator. It was an *interesting* project. The front-end of Janus/Ada is able to target virtually any processor after all of the abstraction work that had to be done for that project. I'm not sure I should say much more, I presume the NDAs are still active. Randy. 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).