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

[Michael Ring]

I see a fix in the bug description but I cannot see that it was 
implemented on trun:

current trunk:

{ Align on native pointer size }
79 	aligncount:=(PtrUInt(pdest) and (sizeof(PtrUInt)-1));
80 	dec(count,aligncount);
81 	


patch:

--- rtl/inc/generic.inc	(revision 38836)
+++ rtl/inc/generic.inc	(working copy)
@@ -59,7 +59,7 @@
          then
          begin
            { Align on native pointer size }
-          aligncount:=(PtrUInt(pdest) and (sizeof(PtrUInt)-1));
+          aligncount:=(sizeof(PtrUInt)-PtrInt(pdest)) and (sizeof(PtrUInt)-1);
            dec(count,aligncount);
            pend:=psrc+aligncount;
            while psrc<pend do


Am 28.11.18 um 20:38 schrieb Benito van der Zander:
> Hi Michael,
>
> there was a discussion in this issue 
> https://bugs.freepascal.org/view.php?id=33323
>
>
> Cheers,
> Benito
>
> 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/5324d3bc/attachment.html>