help / color / mirror / Atom feed
From: "Randy Brukardt" <>
Subject: Re: Valid attribute and input operations
Date: Wed, 27 Sep 2023 22:27:41 -0500	[thread overview]
Message-ID: <uf2rql$3h3dr$> (raw)

No, the specified representation is always used when storing to memory (with 
the single exception of loop parameters, which cannot have address clauses 
or other representation specifications). I think even enum parameters are 
written in the representation. However, any time an enumeration value is 
read into a register it is converted to a position number. Usually, such 
values are used in indexing, comparing, or an attribute like 'Pos or 'Succ, 
all of which are defined to work on position numbers. But if you simply 
assign the value out again, it will get converted both ways. We do have an 
optimization to remove pairs of TOREP/DEREP, but not the reverse since 
Program_Error is a possibility from DEREP. (Well, unless unsafe 
optimizations are on, but I don't recommend using those for the obvious 


"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> On 2023-09-26 9:13, Randy Brukardt wrote:
>> ... for Janus/Ada, enumeration types with specified representations
>> operate internally on the position numbers
> Hm, that's interesting. Is that also the representation for record 
> components of such an enumerated type?
> For example, if I have:
>    type Command is (Off, On) with Size => 4;
>    for Command use (Off => 2, On => 5);
>    type Two_Commands is record
>       C1, C2: Command;
>    end record
>    with Pack, Size => 8;
>    TwoC : Two_Commands := (C1 => On, C2 => Off);
> will the record components (in memory) have the values C1 = 1 and C2 = 0 
> (position numbers) or C1 = 5, C2 = 2 (specified representation)?
> If they are represented by position numbers in the record, many if not 
> most of my embedded Ada programs would fail if compiled with Janus/Ada, 
> because the record values stored in I/O control registers or accessed via 
> DMA would be wrong.
> Damn, I thought those programs were not so compiler-dependent :-(

      reply	other threads:[~2023-09-28  3:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-23 20:22 Valid attribute and input operations Maciej Sobczak
2023-09-23 21:48 ` Jeffrey R.Carter
2023-09-26  6:13   ` Randy Brukardt
2023-09-26  7:22     ` Niklas Holsti
2023-09-28  3:27       ` Randy Brukardt [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox