[fpc-devel] Possible error in generated code for arm?

[Alexander Grotewohl]

Can you run gdb on there? When you break inside memset does the pxBuffer pointer make sense (not 0x0)? Do the other two variables come in correctly?

Do you call memset or does an api in the OS call it? Perhaps it's a pointer to a pointer on accident?

If you are required to provide memset are you also providing other memory functions, for example to allocate? Is it passing a valid pointer back (one that eventually gets to memset)?

Just a bit of a brainstorm.. sorry if I've oversimplified or missed the mark entirely :)

--
Alexander Grotewohl
https://dcclost.com
________________________________
From: fpc-devel <fpc-devel-bounces at lists.freepascal.org> on behalf of Michael Ring via fpc-devel <fpc-devel at lists.freepascal.org>
Sent: Tuesday, April 21, 2020 6:09:57 PM
To: fpc-devel at lists.freepascal.org <fpc-devel at lists.freepascal.org>
Cc: Michael Ring <mail at michael-ring.org>
Subject: [fpc-devel] Possible error in generated code for arm?


I have the following code in a unit (I need to provide a memset function to be able to link to freertos):

function memset(pxBuffer:pointer; value : byte; count : Tsize):pointer; cdecl;
begin
  FillChar(pxBuffer,count,value);
  Result := pxBuffer;
end;


When I look at the assembler code generated by latest Trunk fpc something is very odd @08000970, I'd expect to see

LDR           R0, [R11, #-0x30]

but in fact I see:

 08000970   SUB.W          R0, R11, #0x30

which makes no sense to me and later the code crashes inside of the FillChar routine.

Compiler Bug? Or me overlooking something? I tried to compile with -O- and -O1, with -O2 the generated code is a little different but there the SP is loaded to R0 which I do not understand, I'd expect R0 to be set to address of pxBuffer. (this is for armv7em, for armv6 also looks odd.


Thank you for your help,

Michael

FREERTOS_$$_MEMSET$POINTER$BYTE$LONGWORD$$POINTER
DEBUGSTART_$FREERTOS
memset
$Thumb
begin
 08000958   MOV            R12, SP
 0800095A   PUSH.W         {R11, LR}
 0800095E   SUB.W          R11, R12, #4
 08000962   SUB            SP, SP, #0x48
 08000964   STR            R0, [R11, #-0x30]
 08000968   STRB           R1, [R11, #-0x34]
 0800096C   STR            R2, [R11, #-0x38]
FillChar(pxBuffer,count,value);
 08000970   SUB.W          R0, R11, #0x30
 08000974   LDRB           R2, [R11, #-0x34]
 08000978   LDR            R1, [R11, #-0x38]
 0800097C   BL             SYSTEM_$$_FILLCHAR$formal$LONGINT$BYTE  ; 0x080002
Result := pxBuffer;
 08000980   LDR            R0, [R11, #-0x30]
 08000984   STR            R0, [R11, #-0x3C]

Am 21.04.20 um 23:07 schrieb Joao Schuler:
just as point for consideration, I'm not sure if data alignment will improve speed on future processors:
https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/

Food for thought: imagine if we had single (32 bits floating point) values dynamic arrays with 1 million values each: a b and c. I would love to have something like this:
a := b + c;



_______________________________________________
fpc-devel maillist  -  fpc-devel at lists.freepascal.org<mailto:fpc-devel at lists.freepascal.org>
https://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/20200421/c658ceb8/attachment.html>