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:ad4:58f4:: with SMTP id di20mr2569479qvb.90.1579869532540; Fri, 24 Jan 2020 04:38:52 -0800 (PST) X-Received: by 2002:a9d:24ea:: with SMTP id z97mr2462140ota.345.1579869532163; Fri, 24 Jan 2020 04:38:52 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!g89no5998044qtd.0!news-out.google.com!o19ni801qtr.1!nntp.google.com!g89no5998033qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 24 Jan 2020 04:38:51 -0800 (PST) In-Reply-To: <4878f44b-9f82-45d0-86eb-a63894a2c5bf@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=47.185.239.228; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.239.228 References: <4878f44b-9f82-45d0-86eb-a63894a2c5bf@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <3eddd281-9d67-48c2-9cd4-5ad220444c0c@googlegroups.com> Subject: Re: Creating several types from a base type and conversion From: Optikos Injection-Date: Fri, 24 Jan 2020 12:38:52 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:57933 Date: 2020-01-24T04:38:51-08:00 List-Id: On Friday, January 24, 2020 at 3:35:04 AM UTC-6, Ken Roberts wrote: > On Thursday, January 23, 2020 at 1:39:13 PM UTC-8, Optikos wrote: >=20 > >=20 > > Instead of depending on a big-language solution of a very-feature-rich = compiler, there is a common industrial practice in both Ada and other langu= ages that I mentioned in my 2 replies: use 2 different packages with same-= named identifiers (especially functions or procedures) to link in either th= e little-endian implementation or big-endian implementation (or any other n= onportability that is peculiar to a target ISA or target OS). This solutio= n is at the heart of VIPER and MVVM software architectures for taming the p= ortability beast quite well (going so far as to tame even radical philosoph= ical departures among the very divergent GUIs/window-managers: Gnome/GTK, = Windows UWP, Win32, KDE/Qt, Tizen). >=20 > >=20 > It was my understanding that big/little-endian representations were mainl= y how data was accessed from memory that used 8-bit bytes for physical memo= ry layout. >=20 > Using a 16-bit register as an example: >=20 > register: [first byte][second byte] >=20 > In big-endian format the memory usage would be: >=20 > adx 0: [first byte] > adx 1: [second byte] > adx 2: [first byte] > adx 3: [second byte] >=20 > In little-endian format the memory usage would be: >=20 > adx 0: [second byte] > adx 1: [first byte] > adx 2: [second byte] > adx 3: [first byte] >=20 > Is my understanding off? Yes, you are correct sort of, depending on how you define =E2=80=9Cfirst=E2= =80=9D and =E2=80=9Csecond=E2=80=9D. If first is low-valued powers of 2 in= creasing ascendingly up to 16 (or 32), then you have it backwards. If firs= t is high-valued powers of 2 decreasing descendingly down to 0, then you ha= ve it correct. As AdaMagica also nudged in the better-thinking direction, = the terms most-significant byte and least-significant byte and most-signifi= cant (16-bit-)word and least-significant word are clearer thinking because = they overtly refer to the powers of 2 mathematically. Ada's bit_order refe= rs to whether the ISA refers to the bits (independent of the bytes and word= s) in power-of-2 order mathematically where 2=E2=81=B0 is the origin and us= ually called bit zero (instead of bit one) or opposite of power-of-2 order = anti-mathematically/lexicaly where 2=C2=B9=E2=81=B6 is the origin often cal= led bit one (or more rarely bit zero) in 16-bit words and where 2=C2=B3=C2= =B2 is the origin often called bit one (or more rarely bit zero) in 32-bit = words. But I am focusing on a different debate. Should a) an all-knowing omniscie= nt compiler feature be the basis of your portability, deferring the respons= ibility to the language, or b) overt source code that you write in a struct= ured way be the basis of your portability, taking the responsibility on you= rself? The omnsiscent compiler feature needs to present in all compilers a= cross all targets and nonbuggy (or bug-for-bug compatibility) across all ta= rgets, whereas the overt source code architecture depends only on having a = way to substitute one Ada package for another with same-named identifiers o= n this target versus that target. In the overt source-code architecture th= ere are little-endian versions of certain functions (or procedures) and big= -endian versions of those same-named functions (or procedures). Indeed, th= e this versus that package switcheroo at build-time can be utilized for mor= e portability challenges than mere endianness, but also for this OS versus = that OS (e.g., POSIX versus Windows) and this GUI framework versus that GUI= framework (e.g., Gnome/Gtk versus Windows UWP versus Win32 versus Carbon v= ersus Cocoa versus CocoaTouch versus Tizen) all of which is far far far bey= ond the capabilities of any omniscient compiler to hide. VIPER takes this = build-time switcheroo to the Nth degree (but you might not need all of VIPE= R); MVVM less so than VIPER, but both as a valid stern criticism of MVC's e= xcessive interconnectedness that causes MVC to ruin this degree of portabil= ity. All 3 of VIPER, MVVM, and MVC is a criticism of the omniscient compil= er feature trying to accomplish the portability for you intrinsically behin= d the scenes.