Re: Forcing GNAT to use 32-bit load/store instructions on ARM?

[MatthiasR <MatthiasR@invalid.invalid>]

Randy Brukardt wrote:

> [...]
> 
>> Unfortunately there seem to be no way to force a specific access width,
>> so this feature is not really useable (without the mentioned workaround
>> with the temporary variable) on architectures where the allowed access
>> width is not uniform over the whole address range.
> 
> No, you're looking at this the wrong way. If you write this in C, you read
> the entire register and then do some sort of bit-mask, and then write the
> thing back. You have to do that same thing in Ada, just using the record
> type instead of the bit mask. Ada replaces the bit masking operations by
> more readable record component accesses; it doesn't suddenly allow you to
> write something that you couldn't possibly write in C [a direct write of
> part of a register]. (Whether Ada *should* have allowed you do to that is
> a totally different question and relatively irrelevant at the moment
> because the language isn't likely to support anything new in the near
> future.)
> 
>                                                    Randy.

Ironically, there *is* another possibility, just in C. In principle, 
'Volatile Bitfields', mapped to the register via a pointer, can be used.

Bitfields are avoided by most C programmers because their layout is 
generally not well defined. Means to control the layout (like representation 
clauses in Ada) do not exist.

At least for the ARM platform, the situation is more convenient:
There are rules for the layout of bitfields given in the AAPCS (ABI 
specification for ARM, 'Procedure Call Standard for the ARM Architecture').
So, if the compiler is AAPCS-compliant, the layout of the bitfield records 
is exactly defined.

Additionaly, the AAPCS requires in chapter 7.1.7.5 
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf)
that all reads or writes from/to volatile bitfields must be done 'using the 
access width appropriate to the type of the container'.

The 'container' is not the record/struct as a whole, it is a type specifier 
given with each of the bitfields (this concept of a 'container type' is 
somewhat strange, I needed some time to get the idea of this...)

Example:

struct s 
{
  volatile int a:8;
  volatile char b:2
};

'int' and 'char' are the 'container types' of the bitfields 'a' and 'b'. A 
AAPCS-compliant compiler must read or write 's.a' using a 32-bit access 
(assuming 'int' is 32 bit wide). Accesses to 's.b' must be 8 bit wide.

So, if a C compiler is AAPCS-compliant, volatile bitfields should have the 
desired behaviour. Whether a compiler is *really* AAPCS-compliant, is 
another question. A well-known open source C compiler had bugs in this area 
in several releases. Last year, attempts were made to repair it. I don't 
know the current status.

Matthias