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:a0c:a541:: with SMTP id y59mr17707941qvy.169.1579815552423; Thu, 23 Jan 2020 13:39:12 -0800 (PST) X-Received: by 2002:a9d:53cb:: with SMTP id i11mr364668oth.158.1579815552078; Thu, 23 Jan 2020 13:39:12 -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!g89no3942896qtd.0!news-out.google.com!w29ni121qtc.0!nntp.google.com!g89no3942884qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 23 Jan 2020 13:39:11 -0800 (PST) In-Reply-To: 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: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Creating several types from a base type and conversion From: Optikos Injection-Date: Thu, 23 Jan 2020 21:39:12 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 6049 X-Received-Body-CRC: 245891922 Xref: reader01.eternal-september.org comp.lang.ada:57929 Date: 2020-01-23T13:39:11-08:00 List-Id: On Saturday, January 18, 2020 at 1:32:54 AM UTC-6, Ken Roberts wrote: > New to ada with a question about types. >=20 > The theory is creating an old computer emulator. Memory is an array of Ba= seWord's (Older computer had > 32K of memory, so making an array on a modern computer is peanuts). >=20 > Creating a base type that is stored into the memory array >=20 > >=20 > type BaseWord is array (00 .. 29) of Boolean; > pragma pack (BaseWord); >=20 > >=20 > Creating derived type(s) that can be returned from the memory section >=20 > >=20 > type DataWord is new BaseWord with record > Upper : array 00 .. 8#77777# of Boolean; > Lower : array 00 .. 8#77777# of Boolean; > end record; >=20 > for DataWord use record > for Upper use 15 .. 29; > for Lower use 00 .. 14; > end record; > pragma pack (DataWord); >=20 > type InstructionWord is new BaseWord with record; > (define field parameters) > end record; > for InstructionWord use record > (define BaseWord fields bit locations) > end record; >=20 > >=20 > Defining how characters for display are packed into memory >=20 > > type CharByte is array (0 .. 5) of Boolean; -- Character define > type CharWord is record > CharArray : array (0 .. 4) of CharByte; > end record; > for CharWord use record > for CharArray (0) use 24 .. 29; > for CharArray (1) use 18 .. 23; > for CharArray (2) use 12 .. 17; > for CharArray (3) use 6 .. 11; > for CharArray (4) use 0 .. 5; > end record; >=20 > >=20 > So the next question is how to convert between CharWord/BaseWord? >=20 > For most stuff, memory will be returning either DataWord or InstructionWo= rd for each memory access, > but I'm also looking at an easier way to manage characters for text displ= ay on the emulated monitors. Many replies to this posting focused on details of using standard Ada itsel= f or GNAT-specific extensions of Ada itself as the total solution to portab= ility, such as via record-representation clauses (which aren't always porta= ble to Janus/Ada) and/or Scalar_Storage_Order (which is GNAT-only, absent i= n all other Ada compilers). Instead of depending on a big-language solution of a very-feature-rich comp= iler, there is a common industrial practice in both Ada and other languages= that I mentioned in my 2 replies: use 2 different packages with same-name= d identifiers (especially functions or procedures) to link in either the li= ttle-endian implementation or big-endian implementation (or any other nonpo= rtability 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 porta= bility beast quite well (going so far as to tame even radical philosophical= departures among the very divergent GUIs/window-managers: Gnome/GTK, Wind= ows UWP, Win32, KDE/Qt, Tizen). The key idea is to utilize the build system on a per-target basis, especial= ly the same build system for all targets (instead of the easier case of a d= ifferent build system per target OS/ISA/GUI/whatever). The Project Extensi= on portion of gprbuild is how FSF or AdaCore GNAT would link in the little-= endian package of same-named identifiers versus the big-endian package of s= ame-named identifiers (or overcoming any other seemingly troublesome lack o= f portability within the Ada language itself or of your own ossified source= code that oops inadvertently/short-sightedly got modeled in the past for o= nly one of the now-needed targets-of-portability). Find a layer of identif= iers (especially functions or procedures) that can now be a facade of sorts= behind/within which you swap in this versus that nonportable implementatio= n peculiar to each target at link-time (and perhaps just don't even compile= the other package that is not needed for the current target-of-interest). The kind of per-target switcheroo just described above is mentioned in the = webpage below: =E2=80=9C=E2=80=A6 Another use case is a large software system with multipl= e implementations of a common interface; in Ada terms, multiple versions of= a package body for the same spec, or perhaps different versions of a packa= ge spec that have the same visible part but different private parts. For ex= ample, one package might be safe for use in tasking programs, while another= might be used only in sequential applications. =E2=80=A6=E2=80=9D https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/gnat_project_manage= r.html#project-extension