[fpc-devel] Problem with bitpacked records and STM32F107 Controller

[Michael Ring]

Could you give me a hint on where this is handled in code-generator? (I 
never wanted to touch this beast so I do not know which files are relevant)

Could it be acceptable to change behaviour of the Code-Generator when 
compiling for arm-embedded? (or by implementing {$bitaccesssize 4}, 
which looks like a nice syntax for this to me)?

What I have in Mind is that arm seems to support unaligned access, so it 
might for a first step be good enough to replace the byte load/store 
with 32bit load/store (yes, when crossing a boundary on 32bit access 
there's a performance hit, but this should get evened out by not doing 
the 'and $ff' in generated code.). It would of course be better to 
always do aligned access but to be able to do this I would first need to 
understand how the whole mechanism works in general in the code 
generator, for example for cornercases where a huge number of bits (>8) 
gets modified at the same time)

What do you think?


Michael

Am 11.12.13 10:34, schrieb Jonas Maebe:
> On 11 Dec 2013, at 08:43, Michael Ring wrote:
>
>> The strb command seems to be the problem, documentation from STM states:
>>
>> Each I/O port bit is freely programmable, however the I/O port registers have to be accessed as 32-bit words (half-word or byte accesses are not allowed).
>>
>> So, is there some way to make the bitset operations word-aligned?
> No. In C, you can control the access size by using "int ODR0:1;" instead of "char ODR0:1;", but there is no equivalent in Pascal. This functionality was not introduced with direct hardware access in mind, but for compatibility with the way it's implemented in Mac Pascal compilers and GPC/GCC (the last one with "__attribute__((__packed__))", which is what GPC implicitly uses).
>
>> Are there any good reasons for not doing so?
> Bitpacked records are considered to be byte-aligned by the compiler. That means that if we would use 16bit or 32bit loads stores, they would actually be split up in multiple byte stores on ARM, which is definitely not what you would want here. The alignment of such records could change if we did have a way to specify the access size of individual elements, but in past discussions nobody ever came up with a nice syntax for this. I'm personally also not interested in working on this.
>
>
> Jonas_______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>