<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>The information you see is coming straight out of the debugger
(Segger Ozone), <br>
</p>
<p>and perhaps I should have said this in the first post, <br>
</p>
<p>the pointer that is fed in the Fillchar procedure is complete
nonsense, it points into the stack area which means im my case
that fillchar overwrites the stack and at some point writes into
non-RAM which crashes the cpu.</p>
<p>Value of R0 inside of Fillchar: 20017ef4 (Stack Area at the end
of RAM)<br>
</p>
<p>Value of R0 on entry: 200000f8 which looks OK as it is close to
the start of RAM where it got statically allocated:</p>
<p>implementation<br>
var<br>
xIdleTaskTCB : TStaticTask;<br>
uxIdleTaskStack : array[0..configMINIMAL_STACK_SIZE-1] of
TStackType;<br>
xTimerTaskTCB : TStaticTask;<br>
uxTimerTaskStack : array[0..configTIMER_TASK_STACK_DEPTH-1] of
TStackType;</p>
<p><br>
</p>
<p>The only other thing than a compiler bug could be that my
Implementation of the memset wrapper is wrong, the prototype is:</p>
<pre>void * memset ( void * ptr, int value, size_t num );
and both h2pas and me came to the same implementation:
function memset(pxBuffer:pointer; value : uint32; count : Tsize):pointer; cdecl;
</pre>
<p>You can ignore the fact that I get an uint32 passed in and
Fillchar uses a byte, only the byte part is relevant:</p>
<div class="C_prototype">
<pre>From C Documentation of memset:
void * memset ( void * ptr, int value, size_t num );</pre>
</div>
<div id="I_description"> Fill block of memory</div>
<section id="description">
Sets the first <i>num</i> bytes of the block of memory
pointed by <i>ptr</i> to the specified <i>value</i> (interpreted
as an <tt>unsigned char</tt>).<br>
<br>
I have also hacked the code of my memset function in a way that I
think that it should work:<br>
<br>
begin<br>
asm<br>
LDR R0, [R11, #-0x30]<br>
LDRB R2, [R11, #-0x34]<br>
LDR R1, [R11, #-0x38]<br>
bl fillchar<br>
end;<br>
Result := pxBuffer;<br>
end;<br>
<br>
Implemented this way the function works as expected.<br>
</section>
<p>Michael<br>
</p>
<div class="moz-cite-prefix">Am 22.04.20 um 01:10 schrieb Alexander
Grotewohl:<br>
</div>
<blockquote type="cite"
cite="mid:MN2PR03MB5296055C1927697E17E0D870C5D50@MN2PR03MB5296.namprd03.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
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?</div>
<div style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
<br>
</div>
<div style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
Do you call memset or does an api in the OS call it? Perhaps
it's a pointer to a pointer on accident?</div>
<div style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
<br>
</div>
<div style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
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)?</div>
<div style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
<br>
</div>
<div style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
Just a bit of a brainstorm.. sorry if I've oversimplified or
missed the mark entirely :)</div>
<div id="ms-outlook-mobile-signature">
<div><br>
</div>
--<br>
Alexander Grotewohl<br>
<a href="https://dcclost.com" target="_blank"
moz-do-not-send="true">https://dcclost.com</a></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
fpc-devel <a class="moz-txt-link-rfc2396E" href="mailto:fpc-devel-bounces@lists.freepascal.org"><fpc-devel-bounces@lists.freepascal.org></a> on
behalf of Michael Ring via fpc-devel
<a class="moz-txt-link-rfc2396E" href="mailto:fpc-devel@lists.freepascal.org"><fpc-devel@lists.freepascal.org></a><br>
<b>Sent:</b> Tuesday, April 21, 2020 6:09:57 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:fpc-devel@lists.freepascal.org"><fpc-devel@lists.freepascal.org></a><br>
<b>Cc:</b> Michael Ring <a class="moz-txt-link-rfc2396E" href="mailto:mail@michael-ring.org"><mail@michael-ring.org></a><br>
<b>Subject:</b> [fpc-devel] Possible error in generated code
for arm?</font>
<div> </div>
</div>
<div>
<p>I have the following code in a unit (I need to provide a
memset function to be able to link to freertos):<br>
</p>
<p>function memset(pxBuffer:pointer; value : byte; count :
Tsize):pointer; cdecl;<br>
begin<br>
FillChar(pxBuffer,count,value);<br>
Result := pxBuffer;<br>
end;<br>
</p>
<p><br>
</p>
<p>When I look at the assembler code generated by latest Trunk
fpc something is very odd @08000970, I'd expect to see
<br>
</p>
<p>LDR R0, [R11, #-0x30]</p>
<p>but in fact I see:</p>
<p> 08000970 SUB.W R0, R11, #0x30</p>
<p>which makes no sense to me and later the code crashes inside
of the FillChar routine.</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>Thank you for your help,</p>
<p>Michael<br>
</p>
<p>FREERTOS_$$_MEMSET$POINTER$BYTE$LONGWORD$$POINTER<br>
DEBUGSTART_$FREERTOS<br>
memset<br>
$Thumb<br>
begin<br>
08000958 MOV R12, SP<br>
0800095A PUSH.W {R11, LR}<br>
0800095E SUB.W R11, R12, #4<br>
08000962 SUB SP, SP, #0x48<br>
08000964 STR R0, [R11, #-0x30]<br>
08000968 STRB R1, [R11, #-0x34]<br>
0800096C STR R2, [R11, #-0x38]<br>
FillChar(pxBuffer,count,value);<br>
08000970 SUB.W R0, R11, #0x30<br>
08000974 LDRB R2, [R11, #-0x34]<br>
08000978 LDR R1, [R11, #-0x38]<br>
0800097C BL
SYSTEM_$$_FILLCHAR$formal$LONGINT$BYTE ; 0x080002<br>
Result := pxBuffer;<br>
08000980 LDR R0, [R11, #-0x30]<br>
08000984 STR R0, [R11, #-0x3C]<br>
</p>
<div class="x_moz-cite-prefix">Am 21.04.20 um 23:07 schrieb Joao
Schuler:<br>
</div>
<blockquote type="cite">
<div dir="ltr">just as point for consideration, I'm not sure
if data alignment will improve speed on future processors:
<div><a
href="https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/"
moz-do-not-send="true">https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/</a> </div>
<div><br>
</div>
<div>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:</div>
<div>a := b + c;</div>
</div>
<br>
<fieldset class="x_mimeAttachmentHeader"></fieldset>
<pre class="x_moz-quote-pre">_______________________________________________
fpc-devel maillist - <a class="x_moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org" moz-do-not-send="true">fpc-devel@lists.freepascal.org</a>
<a class="x_moz-txt-link-freetext" href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" moz-do-not-send="true">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
</pre>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
fpc-devel maillist - <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
</pre>
</blockquote>
</body>
</html>