PS. Magic thing is `pragma Volatile_Full_Access`, it requires to use read-modify-store sequence as 32bit value without any optimizations.
---
### Author:  [@sidisyom](https://forum.ada-lang.io/u/sidisyom)
#### Post date: [February 17, 2025, 11:04pm UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/5 "2025-02-17T23:04:26Z")
Thanks very much @Irvise for your suggestions!
Interesting about `aliased` and how it can be used as a hint to the compiler for stack-allocated objects.
> [@Irvise](#):
>
> Secondly, if you think there is some endianess issues… Tell the compiler to follow the convention you want!
Thanks, sounds useful, will go through that. (did try to specify the bit order but that didn’t make any difference)
> [@Irvise](#):
>
> I would add the `Pack` attribute or even the `Size` too, just for good measure.
As @JeremyGrosser mentioned, I was too under the impression that this is just a hint to the compiler i.e. a confirmation that the compiler can lay the record out in at least that many bits (_maybe_ fewer and certainly more) but the deterministic aspects are the `*_Size` ones.
> [@Irvise](#):
>
> If you sourced the Community package from 2021, you are not just using an older GPRbuild, but an entirely different toolchain too! I believe Alire already has the newer GPRbuild v24, so you should be able to update to it using the `toolchain` system of Alire. Additionally, what happens if you build your code in release mode in Alire? What happens if you do an assembly comparison between the different generated binaries from the different toolchains?
Hmm, I see…with my current Alire setup, I am using the latest versions of `gnat_native` and `gprbuild` that are shown when I run an `alr toolchain --select` but what about the cross-compiler? Where’s that coming from? 🤔
For some assembly dumps, please see below in my main answer.
---
### Author:  [@sidisyom](https://forum.ada-lang.io/u/sidisyom)
#### Post date: [February 17, 2025, 11:15pm UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/6 "2025-02-17T23:15:17Z")
Oh, right, I see! So, if I get this right, with byte accesses say, the APB will effectively load the first byte and if that’s zero will wipe-out the entire word…Interesting, thanks for sharing!
Did give your suggestion a try but the compiler complains with:
`atomic access to component of EXTICR_Array cannot be guaranteed`. I wonder if that means the compiler is trying to view access to the _entire_ array as atomic? I did try a variation of that (to be posted below) but that didn’t work either.
Out of curiosity @JeremyGrosser, what is the purpose of the `Import` on the mapped variable? (i.e. I know the semantics of the aspect in general, I’m just wondering what effect that has on the compiler regarding memory accesses. I.e. isn’t `Volatile` sufficient?)
---
### Author:  [@sidisyom](https://forum.ada-lang.io/u/sidisyom)
#### Post date: [February 17, 2025, 11:29pm UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/7 "2025-02-17T23:29:38Z")
So, I tried the following changes:
```ada
type SYSCFG_EXTICR_Register is
record
EXTIO : EXTI_Port;
EXTI1 : EXTI_Port;
EXTI2 : EXTI_Port;
EXTI3 : EXTI_Port;
Unmapped : Common_Types.Arbitrary_Unmapped_Space (1 .. 15);
end record with
Volatile,
Object_Size => 32,
Bit_Order => System.Low_Order_First,
Volatile_Full_Access;
for SYSCFG_EXTICR_Register use
record
EXTIO at 0 range 0 .. 3;
EXTI1 at 0 range 4 .. 7;
EXTI2 at 0 range 8 .. 11;
EXTI3 at 0 range 12 .. 15;
Unmapped at 0 range 16 .. 31;
end record;
type SYSCFG_EXTICR_Bank is array (1 .. 4) of SYSCFG_EXTICR_Register with Volatile, Component_Size => 32;
SYSCFG_EXTICR1_Reg : aliased SYSCFG_EXTICR_Register with Address => System'To_Address (Base_Address + EXTICR_Offset);
SYSCFG_EXTICR_Regs : aliased SYSCFG_EXTICR_Bank with Address => System'To_Address (Base_Address + EXTICR_Offset);
```
but that didn’t have any effect i.e. executing this line:
`SYSCFG.SYSCFG_EXTICR1_Reg.EXTI1 := SYSCFG.PB;`
or this:
`SYSCFG.SYSCFG_EXTICR_Regs (2).EXTI1 := SYSCFG.PB;`
refuses to change the `EXTI1` to `PB`.
However, dumping some disassembled code confirms the suggestions regarding the size accesses.
When no `Volatile_Full_Access` is specified then the compiler produces:
```ada
(gdb) disas 0x8000026, 0x8000032
Dump of assembler code from 0x8000026 to 0x8000032:
=> 0x08000026 <_ada_main+18>: ldr r2, [pc, #40] ; (0x8000050 <_ada_main+60>)
0x08000028 <_ada_main+20>: ldrb r3, [r2, #8]
0x0800002a <_ada_main+22>: movs r1, #1
0x0800002c <_ada_main+24>: bfi r3, r1, #4, #4
0x08000030 <_ada_main+28>: strb r3, [r2, #8]
End of assembler dump.
```
which shows that the loads (`0x08000028`) and stores (`0x08000030`) are done in bytes indeed. (not sure what the `bfi` instruction does).
When `Volatile_Full_Access` _is_ specified, then accesses are in words:
```ada
(gdb) disas 0x8000026, 0x8000036
Dump of assembler code from 0x8000026 to 0x8000036:
0x08000026 <_ada_main+18>: ldr r2, [pc, #44] ; (0x8000054 <_ada_main+64>)
0x08000028 <_ada_main+20>: ldr.w r3, [r2, #2056] ; 0x808
0x0800002c <_ada_main+24>: movs r1, #1
0x0800002e <_ada_main+26>: bfi r3, r1, #4, #4
0x08000032 <_ada_main+30>: str.w r3, [r2, #2056] ; 0x808
End of assembler dump.
```
This seems to be the case when all registers are bundled together in one array too (i.e. when using the variable `SYSCFG_EXTICR_Regs` above)
```ada
(gdb) disas 0x8000026, 0x8000032
Dump of assembler code from 0x8000026 to 0x8000032:
0x08000026 <_ada_main+18>: ldr r2, [pc, #52] ; (0x800005c <_ada_main+72>)
0x08000028 <_ada_main+20>: ldr r3, [r2, #0]
0x0800002a <_ada_main+22>: movs r1, #1
0x0800002c <_ada_main+24>: bfi r3, r1, #4, #4
0x08000030 <_ada_main+28>: str r3, [r2, #0]
End of assembler dump.
```
(I believe the unqualified `ldr` translates to word?)
But again, this doesn’t seem to work.
---
### Author:  [@sidisyom](https://forum.ada-lang.io/u/sidisyom)
#### Post date: [February 17, 2025, 11:41pm UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/8 "2025-02-17T23:41:29Z")
Thanks, will take a look at the svd-generated code. Interesting how a variant record is generated even though `As_Array => False` is used for all register declarations (didn’t fully go through that, tbh). I’ll try to mimic this approach and see if that makes any difference.
> [@godunko](#):
>
> You need to provide much more information to compiler, like to disable some optimizations, use access of appropriate width (byte/half/word).
Would you be able to share any specific examples?
Thanks!
---
### Author:  [@JeremyGrosser](https://forum.ada-lang.io/u/JeremyGrosser)
#### Post date: [February 17, 2025, 11:57pm UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/9 "2025-02-17T23:57:08Z")
> The declaration of an imported object shall not include an explicit initialization expression. Default initializations are not performed.
> – [ARM B.1.24](https://ada-lang.io/docs/arm/AA-B/AA-B.1#p24)
`Import` ensures that the compiler doesn’t try to zero the memory during elaboration.
---
### Author:  [@godunko](https://forum.ada-lang.io/u/godunko)
#### Post date: [February 18, 2025, 3:18pm UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/10 "2025-02-18T15:18:25Z")
I suppose you don’t need more examples, you have find why it doesn’t work.
Pragma/aspect `Volatile_Full_Access` is actually combination of `Volatile` and `Full_Access_Only`.
`Volatile` means that value can be changed at any time, thus disable some optimizations.
`Full_Access_Only` means that all components of the object should be read/written by single operation, object doesn’t allow byte/half word access.
Array of the elements is a bit orthogonal. You can try to declare register type to be `Volatile_Full_Access`, or use `Volatile_Component`. You can find more information in RM
[https://docs.adacore.com/live/wave/arm22/html/arm22/arm22-C-6.html](https://docs.adacore.com/live/wave/arm22/html/arm22/arm22-C-6.html)
---
### Author:  [@sidisyom](https://forum.ada-lang.io/u/sidisyom)
#### Post date: [February 19, 2025, 9:17am UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/11 "2025-02-19T09:17:19Z")
Just a note to add some further findings.
I read the behaviour of the APB bus a bit more carefully and I started to think that zeroing-out of all bits shouldn’t actually be happening. If anything, more bits should be set!
Indeed, that is what is happening (well, _nearly_ that) when I build the project using plain gprbuild which is using the configured cross-compiler for the given `Target`.
Given this:
```ada
type SYSCFG_EXTICR_Register is
record
EXTIO: EXTI;
EXTI1: EXTI;
EXTI2: EXTI;
EXTI3: EXTI;
Unmapped: Arbitrary_Unmapped_Space(1 .. 15);
end record with Volatile, Object_Size => 32;
for SYSCFG_EXTICR_Register use
record
EXTIO at 0 range 0 .. 3;
EXTI1 at 0 range 4 .. 7;
EXTI2 at 0 range 8 .. 11;
EXTI3 at 0 range 12 .. 15;
Unmapped at 0 range 16 .. 31;
end record;
type SYSCFG_EXTICR_Arr is array (1 .. 4) of SYSCFG_EXTICR_Register with Component_Size => 32;
SYSCFG_EXTICR_Reg : aliased SYSCFG_EXTICR_Arr with Import, Address => System'To_Address (Base_Address); -- Base address includes offset here
```
and executing that:
`SYSCFG_EXTICR_Reg(2).EXTIO := PB;`
the assembly is:
```ada
Dump of assembler code from 0x8000256 to 0x8000262:
=> 0x08000256 : ldr r2, [pc, #56] ; (0x8000290 )
0x08000258 : ldrb r3, [r2, #4]
0x0800025a : movs r1, #1
0x0800025c : bfi r3, r1, #0, #4
0x08000260 : strb r3, [r2, #4]
End of assembler dump.
```
(so, byte accesses are issued) and dumping the memory gives:
```ada
(gdb) x/8tb SYSCFG_EXTICR_Reg'Address
0x40013808: 00000000 00000000 00000000 00000000 00000001 00000001 00000000 00000000
```
so the “1” from the actual changing byte has been duplicated onto the second byte only, which I think is kinda half-consistent with the RM i.e. I’d expect that duplication to take place across all bytes of the word and result in:
`00000001 00000001 00000001 00000001`
but perhaps a separate issue.
Now, setting `Volatile_Full_Access` on the record results in the following assembly:
```ada
Dump of assembler code from 0x8000256 to 0x8000268:
0x08000256 : ldr r3, [pc, #64] ; (0x8000298 )
0x08000258 : adds r3, #4
0x0800025a : ldr r3, [r3, #0]
0x0800025c : movs r2, #1
0x0800025e : bfi r3, r2, #0, #4
0x08000262 : ldr r2, [pc, #52] ; (0x8000298 )
0x08000264 : adds r2, #4
0x08000266 : str r3, [r2, #0]
```
so, word accesses are issued (aka unqualified instructions) and dumping the memory gives:
```ada
(gdb) x/8tb SYSCFG_EXTICR_Reg'Address
0x40013808: 00000000 00000000 00000000 00000000 00000001 00000000 00000000 00000000
```
and all is good here.
None of that is happening in the Alire project. I tried using the exact same compiler flags as the gprbuild project and although the assembly is now identical there’s no change in the behaviour.
What’s more interesting is that the same happens if I use a single scalar for the entire register, i.e. given this:
```ada
SYSCFG_EXTICR1_Reg : aliased Interfaces.Unsigned_32 with
Import,
Volatile_Full_Access,
Address => System'To_Address (Base_Address + EXTICR_Offset);
```
and executing:
`SYSCFG.SYSCFG_EXTICR1_Reg := 1;`
the assembly is:
```ada
(gdb) disas 0x8000022, 0x8000028
Dump of assembler code from 0x8000022 to 0x8000028:
0x08000022 <_ada_main+14>: ldr r3, [pc, #36] ; (0x8000048 <_ada_main+52>)
0x08000024 <_ada_main+16>: str.w r2, [r3, #2056] ; 0x808
End of assembler dump.
```
so, just plain word loads and stores (didn’t check but I assume `r2` is set to “1” a bit further up) but yet `SYSCFG.SYSCFG_EXTICR1_Reg` remains stubbornly stuck to “0” as if that instruction were a nop.
So, it looks like something is wrong with my Alire setup.
Perhaps someone with more in-depth knowledge of all the components involved might be able to shed some light. I’m going to revert back to gprbuild for now and continue to investigate.
Thanks everyone for all the helpful comments.
---
### Author:  [@OneWingedShark](https://forum.ada-lang.io/u/OneWingedShark)
#### Post date: [February 21, 2025, 3:42am UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/12 "2025-02-21T03:42:10Z")
> [@sidisyom](#):
>
> ```ada
> type SYSCFG_EXTICR_Register is record
> EXTIO, EXTI1, EXTI2, EXTI3: EXTI;
> Unmapped : Arbitrary_Unmapped_Space(1 .. 15);
> end record
> with Volatile, Object_Size => 32;
>
> for SYSCFG_EXTICR_Register use record
> EXTIO at 0 range 0 .. 3;
> EXTI1 at 0 range 4 .. 7;
> EXTI2 at 0 range 8 .. 11;
> EXTI3 at 0 range 12 .. 15;
> Unmapped at 0 range 16 .. 31;
> end record;
>
> ```
Let me fix that for you.
---
### Author:  [@sidisyom](https://forum.ada-lang.io/u/sidisyom)
#### Post date: [February 25, 2025, 10:38am UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/13 "2025-02-25T10:38:47Z")
A quick update on this, fwiw.
As it is so often the case, this was down to user error. After banging my self hard in the head with the STM32F42 Reference Manual over the past couple of days, it finally hit me (apologies for the terrible pun).
If the system configuration controller clock isn’t enabled then interacting with any register under that memory range is effectively a nop. The reason it works in my other gprbuild project is naturally because the controller clock _is_ turned-on in some other part of the flow. So, no issues with my Alire setup.
What I’m keeping from this is that `Volatile_Full_Access` is crucial when interacting with this board as the behaviour will most likely be non-deterministic (i.e. setting random bits _may_ or may not have any program side-effects).
The downside, as previously mentioned, is that it some implementation details from the register mapping, do leak into the client (i.e. offset calculation etc). Maybe, a small mapping function will add an extra layer of encapsulation (albeit the register array still exposes it’s index structure):
```ada
subtype Exti_Range is Natural range 0 .. 15;
function Exti_To_Offset (Exti : Exti_Range) return Natural is (Exti / 4);
```
I’m sure other solutions can be applied (i.e. private types etc) but that might be taking it a bit too far.
Thanks all for looking into it and apologies for the confusion.
---
### Author:  [@OneWingedShark](https://forum.ada-lang.io/u/OneWingedShark)
#### Post date: [February 25, 2025, 8:31pm UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/14 "2025-02-25T20:31:04Z")
> [@sidisyom](#):
>
> I’m sure other solutions can be applied (i.e. private types etc) but that might be taking it a bit too far.
Private types are not “too far”.
Private types are perfectly appropriate for many things, but particularly for separating implementation from interface. One feature that, in recent years, has been neglected, is the `Separate` body.
You can use `Separate` to take a large subprogram and isolate it, like say the parser for reading a file (esp if you’re doing multi-format, auto-detect reads), but you can _also_ use them for isolating/implementing system dependency. (Now, to be fair, this latter usage is often tied to your build-system and is not exclusively a language issue.)
```ada
Package Paths is
Type Path(<>) is limited private;
Function To_Path( Object : String ) return Path;
Function To_String( Object : Path ) return String;
-- Other functions.
Private
Package Path_Vector is Ada.Containers.Indefinite_Vector
(Index => Positive, Element => String, "=" => Ada.Strings.Case_Insensitive_Equals);
Type Path is new Path_Vector.Vector with null record;
-- This is used to set the character used for path separation.
Function Separator return Character is Separate;
End Paths;
```
| Windows | Unix |
| --- | --- |
| src\win\paths.separator.adb | src/unix/paths.separator.adb |
| `Separate(Paths) Function Separator return Character renames '\';` | `Separate(Paths) Function Separator return Character renames '/';` |
Thus, whether you include `src\win` or `src/unix` in your build process, determines how your to-path parses a given string, while keeping that completely from anyone using the package, as the implementation is completely hidden. (Granted, it’s a trivial and stupid little example, but shows how you can leverage the feature to isolate system/architecture dependencies from leaking through your interface.) – Ada is robust enough that very often it is beneficial to sit down, describe your problem in the type-system, write out how you want the interface to be, and _then_ implement.
Don’t be afraid to completely isolate _ **all** _ implementation details into the `BODY` or `PRIVATE` parts. I’ve had times where I’ve completely changed the implementation of a type and only had to recompile that package (and its children).
---
### Author:  [@Nordic\_Dogsledding](https://forum.ada-lang.io/u/Nordic_Dogsledding)
#### Post date: [February 26, 2025, 12:54pm UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/15 "2025-02-26T12:54:01Z")
> [@OneWingedShark](#):
>
> ```ada
> Package Paths is
> Private
> -- This is used to set the character used for path separation.
> Function Separator return Character is Separate; <== illegal
> End Paths;
>
> ```
This body stub is illegal in the spec, put it into the body.
---
### Author:  [@OneWingedShark](https://forum.ada-lang.io/u/OneWingedShark)
#### Post date: [February 26, 2025, 9:47pm UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/16 "2025-02-26T21:47:18Z")
Ah, I had forgotten that, typing it out on-the-fly.
Thank you.