[fpc-devel] Where to set proper alignment default of const strings?

[Michael Ring]

After a little more fun in the debugger I came up with the following patch:

Index: generic.inc
===================================================================
--- generic.inc    (revision 40381)
+++ generic.inc    (working copy)
@@ -77,6 +77,8 @@
          begin
            { Align on native pointer size }
            aligncount:=(PtrUInt(pdest) and (sizeof(PtrUInt)-1));
+          if aligncount > 0 then
+            aligncount := sizeof(PtrUInt)-aligncount;
            dec(count,aligncount);
            pend:=psrc+aligncount;
            while psrc<pend do


from my point of view the routine is wrongly calculating the numbers of 
bytes that need to be read byte aligned before a pointer-sized copy can 
be done

Michael


Am 28.11.18 um 19:51 schrieb Michael Ring:
>
> The more I dig the more I ask myself if not the rtl routine is to 
> blame for the issue in the first place because it only takes alignment 
> of the destination into account when doing it's job.
>
> Aligncount is calculated base on destination (which is RAM), for this 
> reason the last line always crashes because psrc can be unaligned.
>
> I most likely completely misunderstand the meaning of 
> FPC_REQUIRES_PROPER_ALIGNMENT but usually ram can be written byte 
> aligned but flash has often limitations on read access so alignment 
> should look for psrc as this can come from flash.
>
> Unless of course FPC_REQUIRES_PROPER_ALIGNMENT is  primarily meant for 
> speed improovement only, then it would make sense to look at pdest to 
> try to optimize write performance by having as much aligned access as 
> possible.I only found an old discussion in lazarus list from 2011 on 
> this topic, where it looks like structs were manually aligned in 
> lazarus, but I did not look too deep into the patches.
>
> procedure Move(const source;var dest;count:SizeInt);[public, alias: 
> 'FPC_MOVE']; from generic.inc line77:
>
>         begin
>           { Align on native pointer size }
> --> *aligncount:=(PtrUInt(pdest) and (sizeof(PtrUInt)-1));*
>           dec(count,aligncount);
>           pend:=psrc+aligncount;
>           while psrc<pend do
>             begin
>               pdest^:=psrc^;
>               inc(pdest);
>               inc(psrc);
>             end;
>           { use sizeuint typecast to force shr optimization }
>           pptruint(pend):=pptruint(psrc)+(sizeuint(count) div 
> sizeof(ptruint));
>           while psrc<pend do
>             begin
>               pptruint(pdest)^:=pptruint(psrc)^;
>
> Am 28.11.18 um 17:49 schrieb Michael Ring:
>> Hi,
>>
>> I am debugging an issue that I see on mipsel embedded target (and 
>> perhaps also on arm-embedded for corteX-m0, I had crashes in the same 
>> rtl routine a while ago)
>>
>> because RAM is small on embedded devices I use:
>>
>> {$WRITEABLECONST OFF}
>>
>> which means that const are read from flash and not from ram.
>>
>> problem is now that const strings are sometimes not 32-bit aligned 
>> and this causes an unaligned access exception on pic32mx because date 
>> from flash must be read 32-bit aligned.
>>
>> I thought that I had seen the correct place to configure this 
>> alignment in the past but my google/grep foo is weak at the moment, I 
>> cannot find something in the fpc sourcecode that rings a bell.
>>
>> {$CODEALIGN CONSTMIN=4}
>>
>> also does not work, I recompiled and in my case the const is still 
>> improperly alligned.
>>
>>
>> Thanks in advance,
>>
>>
>> Michael
>>
>>
>>
>> _______________________________________________
>> fpc-devel maillist  - fpc-devel at lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20181128/b9b472e8/attachment.html>