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=0.5 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:2209:: with SMTP id i9-v6mr1150531ioi.138.1525974341362; Thu, 10 May 2018 10:45:41 -0700 (PDT) X-Received: by 2002:a9d:24a1:: with SMTP id z30-v6mr112038ota.4.1525974341182; Thu, 10 May 2018 10:45:41 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!border2.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!85.12.16.69.MISMATCH!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!v8-v6no564425itc.0!news-out.google.com!f20-v6ni729itd.0!nntp.google.com!u74-v6no570984itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 10 May 2018 10:45:40 -0700 (PDT) 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 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: AI12-0218: What is the portable representation clause for processing IETF packets on little-endian machines? From: "Dan'l Miller" Injection-Date: Thu, 10 May 2018 17:45:41 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 6198 X-Received-Body-CRC: 3125044148 Xref: reader02.eternal-september.org comp.lang.ada:52201 Date: 2018-05-10T10:45:40-07:00 List-Id: It seems that 2 major use-cases of AI12-0218 are getting short shrift. http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0218-1.txt?rev=3D1.3&= raw=3DN USE-CASE: network byte order: 1) Nearly all telecom protocols operate on big-endian octet ordering. Big-= endian octet ordering in all the Internet protocols' packet formats is so c= ommon that IETF calls it =E2=80=9Cnetwork byte ordering=E2=80=9D. Converse= ly, the 3 most widely deployed ISAs on the planet (i.e., IA-32, AMD64, ARM*= ) are all little-endian. This matters not for line-rate packets and frames= processed by ASICs or FPGAs or DSPs, but for the packets whose processing = is at software speed in general-purpose processors, byte-swapping is what m= akes the Internet work on the computer that you are using right this instan= t (unless you are using a PowerPC-, POWER, 68K-, MIPS, or mainframe-based c= omputer or an Alpha- or Itanium-based computer configured in the rare big-e= ndian configuration). So this is not a rare use-case at all! * Like many RISC processors, endianness is a choice at PCB engineering-time= . The vast vast majority of ARM-based designs choose little-endian. Instead of the use-case being rare, what is apparently rare is for Ada to b= e utilized to write such network-protocol software on Intel and ARM process= ors instead of C or C++. Most of the military uses PowerPC as their genera= l-purpose processors, and rarely ARM and even rarer Intel. USE-CASE: memory-mapped registers on peripheral ICs: 2) When writing device drivers for many ICs, the IC's register set often is= memory-mapped at a fixed address. This IC has either big-endian or little= -endian octet ordering. The general-purpose processor is either big-endian= or little-endian. Often ICs from big-endian manufacturers are utilized on= processors that are little-endian. Often ICs from little-endian manufactu= rers are utilized on processors that are big-endian. Sometimes endianness = is configurable in those ICs; often it is not. So in AI12-0218 when I see resistance of ARG members to standardizing a wid= espread use-case that was (in the 1970s-/1980s-/1990s-era Ada-is-the-future= mantra) supposed to be Ada's sweet-spot (i.e., writing device drivers port= ably), I can see one crucial reason that Ada was frowned upon in writing pa= cket-processing and device-driver software an Intel and ARM platforms, whic= h are the most popular by far of all ISAs. Little-endian platforms (who need byte-swapping for network byte order): all Apple iOS devices, all ARM-based Android devices, all Windows 10 comput= ers, all Windows 8.1 computers, all Windows 7 computers, all Windows Server= 2008, all Windows Server 2012, all Windows Server 2016, all Linux on IA-32= , all Linux on AMD64, all Linux on ARM Big-endian platforms (who don't need byte-swapping for network byte order): the other less-than-small-fraction-of-1% of all other computers on the plan= et. No hyperbole: far far less than 1% of extant computers throughout pla= net Earth. Good to know that (for =E2=89=A534 years!) Ada has been standardized for th= e less-than-small-fraction-of-1% of computers on the planet nowadays. This= isn't regarding the old arcane convert-COBOL-to-Ada featureset of Ada eith= er. This is regarding device drivers interacting with hardware ICs, which = is supposedly one of Ada's A#1 key must-do marketspaces. And the endian feature of AI12-0218 is not being embraced by the ARG. Wow!= It is not viewed by the ARG as a =E2=89=A534-year-old embarrassment that = might have actually caused unpopularity of Ada over the decades in its pote= ntial key advocates: realtime software engineers writing device drivers in= Ada's supposed key marketspace of reading & writing IC registers, meeting = realtime deadlines before packet-arrival over-run (or whatever mission the = IC is accomplishing in realtime). The Challenge: Without the proposed solution in AI12-0218, I challenge anyone to write an = Ada representation clause that is =E2=80=A2portable=E2=80=A2 to both little= -endian and big-endian processors for either of the following IETF packet f= ormats that must always be in big-endian network byte order: https://en.wikipedia.org/wiki/IPv4#Packet_structure https://en.wikipedia.org/wiki/IPv6_packet Hint #1: in C or C++, different definitions of preprocessor macros (contro= lled by #if conditional compilation directives)) would typically be utilize= d for portably cloaking lack-of-byte-swap-no-op on big-endian processors an= d byte-swapping on little-endian processors, but Ada lacks macros, so the = =E2=80=A2=E2=80=A2representation clause=E2=80=A2=E2=80=A2 in AI12-0218 (on = only GNAT for now) is the only game in Adatown, it would seem. And other t= han on GNAT in the past few years, the representation clause as standardize= d cannot accomplish the goal portably.