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@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
