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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:ac8:6c5:: with SMTP id j5mr1247333qth.284.1579858503285; Fri, 24 Jan 2020 01:35:03 -0800 (PST) X-Received: by 2002:a05:6808:b1c:: with SMTP id s28mr1432896oij.2.1579858502745; Fri, 24 Jan 2020 01:35:02 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!peer02.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!g89no5574501qtd.0!news-out.google.com!w29ni223qtc.0!nntp.google.com!g89no5574490qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 24 Jan 2020 01:35:02 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=47.136.24.151; posting-account=o_Y23woAAACPYGlDsFV1OivhygPNSoRn NNTP-Posting-Host: 47.136.24.151 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <4878f44b-9f82-45d0-86eb-a63894a2c5bf@googlegroups.com> Subject: Re: Creating several types from a base type and conversion From: Ken Roberts Injection-Date: Fri, 24 Jan 2020 09:35:03 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 2737 X-Received-Body-CRC: 3291522078 Xref: reader01.eternal-september.org comp.lang.ada:57930 Date: 2020-01-24T01:35:02-08:00 List-Id: On Thursday, January 23, 2020 at 1:39:13 PM UTC-8, Optikos wrote: > Instead of depending on a big-language solution of a very-feature-rich co= mpiler, there is a common industrial practice in both Ada and other languag= es that I mentioned in my 2 replies: use 2 different packages with same-na= med identifiers (especially functions or procedures) to link in either the = little-endian implementation or big-endian implementation (or any other non= portability that is peculiar to a target ISA or target OS). This solution = is at the heart of VIPER and MVVM software architectures for taming the por= tability beast quite well (going so far as to tame even radical philosophic= al departures among the very divergent GUIs/window-managers: Gnome/GTK, Wi= ndows UWP, Win32, KDE/Qt, Tizen). It was my understanding that big/little-endian representations were mainly = how data was accessed from memory that used 8-bit bytes for physical memory= layout. Using a 16-bit register as an example: register: [first byte][second byte] In big-endian format the memory usage would be: adx 0: [first byte] adx 1: [second byte] adx 2: [first byte] adx 3: [second byte] In little-endian format the memory usage would be: adx 0: [second byte] adx 1: [first byte] adx 2: [second byte] adx 3: [first byte] Is my understanding off?