Re: Creating several types from a base type and conversion

[Optikos <ZUERCHER_Andreas@outlook.com>]

On Saturday, January 18, 2020 at 1:32:54 AM UTC-6, Ken Roberts wrote:
> New to ada with a question about types.
> 
> The theory is creating an old computer emulator. Memory is an array of BaseWord's (Older computer had
> 32K of memory, so making an array on a modern computer is peanuts).
> 
> Creating a base type that is stored into the memory array
> 
> <code>
> 
>     type BaseWord is array (00 .. 29) of Boolean;
>     pragma pack (BaseWord);
> 
> </code>
> 
> Creating derived type(s) that can be returned from the memory section
> 
> <code>
> 
>     type DataWord is new BaseWord with record
>         Upper : array 00 .. 8#77777# of Boolean;
>         Lower : array 00 .. 8#77777# of Boolean;
>     end record;
> 
>     for DataWord use record
>         for Upper use 15 .. 29;
>         for Lower use 00 .. 14;
>     end record;
>     pragma pack (DataWord);
> 
>     type InstructionWord is new BaseWord with record;
>         (define field parameters)
>     end record;
>     for InstructionWord use record
>         (define BaseWord fields bit locations)
>     end record;
> 
> </code>
> 
> Defining how characters for display are packed into memory
> 
> <code>
>     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;
> 
> </code>
> 
> So the next question is how to convert between CharWord/BaseWord?
> 
> For most stuff, memory will be returning either DataWord or InstructionWord for each memory access,
> but I'm also looking at an easier way to manage characters for text display on the emulated monitors.

Many replies to this posting focused on details of using standard Ada itself or GNAT-specific extensions of Ada itself as the total solution to portability, such as via record-representation clauses (which aren't always portable to Janus/Ada) and/or Scalar_Storage_Order (which is GNAT-only, absent in all other Ada compilers).

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 languages that I mentioned in my 2 replies:  use 2 different packages with same-named identifiers (especially functions or procedures) to link in either the little-endian implementation or big-endian implementation (or any other nonportability 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 portability beast quite well (going so far as to tame even radical philosophical departures among the very divergent GUIs/window-managers:  Gnome/GTK, Windows UWP, Win32, KDE/Qt, Tizen).

The key idea is to utilize the build system on a per-target basis, especially the same build system for all targets (instead of the easier case of a different build system per target OS/ISA/GUI/whatever).  The Project Extension 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 same-named identifiers (or overcoming any other seemingly troublesome lack of portability within the Ada language itself or of your own ossified source code that oops inadvertently/short-sightedly got modeled in the past for only one of the now-needed targets-of-portability).  Find a layer of identifiers (especially functions or procedures) that can now be a facade of sorts behind/within which you swap in this versus that nonportable implementation 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:
“… Another use case is a large software system with multiple implementations of a common interface; in Ada terms, multiple versions of a package body for the same spec, or perhaps different versions of a package spec that have the same visible part but different private parts. For example, one package might be safe for use in tasking programs, while another might be used only in sequential applications. …”

https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/gnat_project_manager.html#project-extension