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-boun...@lists.freepascal.org> on behalf of Michael Ring via fpc-devel <fpc-devel@lists.freepascal.org> Sent: Tuesday, April 21, 2020 6:09:57 PM To: fpc-devel@lists.freepascal.org <fpc-devel@lists.freepascal.org> Cc: Michael Ring <m...@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@lists.freepascal.org<mailto:fpc-devel@lists.freepascal.org> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
