Re: Creating several types from a base type and conversion

[Optikos <ZUERCHER_Andreas@outlook.com>]

On Saturday, January 18, 2020 at 6:16:20 AM UTC-6, Simon Wright wrote:
> Ken Roberts writes:
> 
> > So the next question is how to convert between CharWord/BaseWord?
> 
> Possibly using Ada.Unchecked_Conversion. Hidden inside a function with a
> helpful-in-six-months name.
> 
> It takes very little time to compile code nowadays, I'd strongly suggest
> you start with the basics (e.g. BaseWord) and build up from there,
> checking as you go (there are a _lot_ of syntax errors in your example
> code).
> 
> You can't say
> 
>     type DataWord is new BaseWord with record
>         Upper : array 00 .. 8#77777# of Boolean;
>         Lower : array 00 .. 8#77777# of Boolean;
>     end record;
> 
> because BaseWord isn't a tagged type, and even if it was you don't want
> to add extra information, you're looking for an alternative view.
> And that's not the syntax for an array declaration.
> And you can't declare an anonymous array in a record.
> And that's two large arrays (I think you're aiming for representations).
> 
> ----------
> 
> I was wondering whether an Unchecked Union (ARM B.3.3[1]) might serve,
> but (30) says "The use of an unchecked union to obtain the effect of an
> unchecked conversion results in erroneous execution".
> 
> [1] http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-B-3-3.html

The Unchecked_ series are better focused on the situation that BaseWord, DataWord, InstructionWord, and CharWord are originating in another language, say, C, but that is ostensibly not the case here.

More proper in Ada, would be to have multiple conversion functions that take the already-extant FooWord as a parameter and return an extracted/converted BarWord as return value (or a procedure that takes the already-extant FooWord as an in parameter and the to-be-extracted/to-be-converted BarWord as an out parameter).  Then that conversion/extraction subroutine is merely performing garden-variety safe/not-unchecked reading of FooWord and is merely performing garden-variety safe/not-unchecked writing of BarWord.

You would have a plethora of such FooWord to BarWord conversion/extraction subroutines—one for each origin-to-destination pairing in your app-domain, such as {ExtractCharWordFromDataWord, EmbedCharWordIntoDataWord, ExtractDataWordFromInstructionWordOpcode, EmbedDataWordIntoInstructionWordOpcode, ExtractDataWordFromInstructionWordImmediate, EmbedDataWordIntoInstructionWordImmediate, …} (assuming that immediates in the machine code are located at the same offset-from-beginning-of-instruction in all machine instructions, otherwise ExtractDataWordFromImmediateForSuchandsuchOpcode and EmbedDataWordIntoImmediateForSuchandsuchOpcode for each different format of suchandsuch opcodes in the instruction-set) and so forth.

In modern Ada, for efficiency and perhaps succinct/readable beauty, you might want to consider the extended return statement if choosing the design above that is based on functions (instead of the out parameter to a procedure, which is available in all eras of Ada, but perhaps naturally leading to slightly more verbose/less-lucid invocations at points of usage, due to being statements instead of expressions).

https://www.adaic.org/resources/add_content/standards/05rm/html/RM-6-5.html#S0170