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 2002:a24:1458:: with SMTP id 85-v6mr578583itg.55.1525999829507; Thu, 10 May 2018 17:50:29 -0700 (PDT) X-Received: by 2002:a9d:620d:: with SMTP id g13-v6mr170138otj.3.1525999829370; Thu, 10 May 2018 17:50:29 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!newsreader5.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.am4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!v8-v6no56337itc.0!news-out.google.com!f20-v6ni1itd.0!nntp.google.com!u74-v6no63195itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 10 May 2018 17:50:29 -0700 (PDT) In-Reply-To: <87603vyqxc.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: <9af47760-e731-4cb5-a1a0-d63e31019ce5@googlegroups.com> <877eob1cc6.fsf@nightsong.com> <87po23yusb.fsf@nightsong.com> <87603vyqxc.fsf@nightsong.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <38ef3024-cc04-43bf-991f-7569eae82f45@googlegroups.com> Subject: Re: AI12-0218: What is the portable representation clause for processing IETF packets on little-endian machines? From: "Dan'l Miller" Injection-Date: Fri, 11 May 2018 00:50:29 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 3192 X-Received-Body-CRC: 1595205103 Xref: reader02.eternal-september.org comp.lang.ada:52236 Date: 2018-05-10T17:50:29-07:00 List-Id: On Thursday, May 10, 2018 at 7:30:43 PM UTC-5, Paul Rubin wrote: > =E2=80=A6 it's intended to specify actual memory layout. vis a vis > That is a poor way to handle network byte order =E2=80=A6 How does specifying =E2=80=9Cactual memory layout=E2=80=9C not include the = topic of byte order? Endianness is quite honestly the ultimate very first = topic in an ISA's definition of =E2=80=9Cactual memory layout=E2=80=9D, eit= her at processor engineering-time or (in bi-endian processors) at PCB engin= eering-time of pulling a pin high or low. Endianness even predates word si= ze: even before software choses to write or read a 16- or 32- or 64-bit in= teger, its endianness in predetermined beforehand (months or years or decad= es prior to software's johnny-come-lately decision of word size on which to= operate). Btw, what is nonactual memory layout or actual nonmemory layout or actual m= emory nonlayout? I have no idea what the word actual is meaning there or w= hat actual=E2=80=99s presence/absence means. It would seem that =E2=80=9Cm= emory layout=E2=80=9D and =E2=80=9Cactual memory layout=E2=80=9D mean exact= ly the same thing. And the layout of words and bytes in memory includes th= eir endian order. (And to Randy's concerns about front-end implementation = forcing layout of memory instead of intra-processor registers, there is no = such thing as layout of nonmemory (i.e., registers within a processor) beca= use registers do not have addresses, and hence lack endianness of which byt= e is at the lower-valued address).