Effect of additionnal save/restore instructions
Gedare Bloom
gedare at rtems.org
Tue Apr 23 13:00:19 UTC 2013
I agree with Claudio's assessment. I also would suspect if you look at the
disassembly that the function is leaf-optimized (uses retl instead of ret),
which having this extra save/restore might correct for, but if you remove
that then touching registers that are not in the %o (output) or %g (global)
register families could cause some bad problems.
I would actually change the %17 to a register that is safe to use. This fix
should also permit gcc to leaf-optimize the function still, since it can
use an output register safely in that context.
Something like:
__asm__ __volatile__ (" \
set " XSTR(NB_ITER_60US) ", %%o0; \
StartLoop1us: \
dec 1, %%o0; \
cmp %%o0, 0; \
bne StartLoop1us; \
nop; \
" : : "o0" );
or
int count = XSTR(NB_ITER_60US);
__asm__ volatile (" \
StartLoop1us: \
dec 1, %0; \
cmp %0, 0; \
bne StartLoop1us; \
nop; \
" : "=r" (count));
And check the output of compiling by disassembling or compile with -S to
see what assembly gcc creates when making this function.
On Tue, Apr 23, 2013 at 5:27 AM, Cláudio Silva <claudiodcsilva at gmail.com>wrote:
> Hello Leonard,
>
> I would add a volatile after the __asm__ otherwize gcc can optimize away
> some of your code.
> The windows underflow and overflow traps will occur during normal
> execution. It is expected behavior when you do a restore and the previous
> register window is invalid (marked as 1 in the $wim register).
> Regarding your code, without the save and restore instruction you are
> changing the current window %l7 register and gcc might be not expecting it.
> To solve this you will need to clobber the register as Chris described in
> the previous email.
> The save and restore instruction are not a good addition to that code,
> because they may trigger an underflow/overflow trap therefore increasing
> the execution time of that function.
>
> The random behavior you are seeing might be due to stack corruption
> originating from the %sp register of the new window (after the save) being
> set to an old value (from an older register window). "save" should be
> "save %sp, -96 (?), %sp". Nevertheless this is just my quick guess ;)
>
> Regards,
> Cláudio
>
>
> On Tue, Apr 23, 2013 at 10:02 AM, Leonard Bise <leonard.bise at syderal.ch>wrote:
>
>> Hello all,
>>
>> I'm having a problem regarding the processor window registers that I
>> cannot explain easily mostly because I'm not super familiar with this
>> subject.
>>
>> First, I'm using a LEON2 Sparc v8 processor and RTEMS 4.8 version which
>> is required by our project.
>>
>> We have a function using inline assembly to perform a flat delay, here is
>> the code it use.
>>
>> void SCET_wait_2us(void) {
>>
>> {
>>
>> /*#[ operation SCET_wait_2us() */
>>
>> /* Performs a 60us delay using an ASM loop, this piece of code
>> has been
>>
>> * measured on HW to validate the duration is correct */
>>
>> __asm__(" \
>>
>> save; \
>>
>> set " XSTR(NB_ITER_60US) ", %l7; \
>>
>> StartLoop1us: \
>>
>> dec 1, %l7; \
>>
>> cmp %l7, 0; \
>>
>> bne StartLoop1us; \
>>
>> nop; \
>>
>> restore; \
>>
>> ");
>>
>> /*#]*/
>>
>> }
>>
>> }
>>
>> Originally this code didn't have the save and restore instruction but our
>> sub contractor added them because they had problems compiling. I find it an
>> odd solution but whatever.
>>
>> Once this code was implemented we started seeing random processor
>> reset occurring in various contexts.
>>
>> I tested this code while being in the Eclipse debugger and once the crash
>> happened I noticed I had a segmentation fault in Eclipse. I used GRMON to
>> check the processor register and noticed that the last trap that occurred
>> was a window underflow trap 0x06.
>>
>> I found in the RTEMS sources the code for this handler, and while I
>> haven't understood everything I took out that the code was trying to
>> recover from this error, is this correct?
>> I copied the trap handler code below.
>>
>> RTEMS 4.8 branch
>> file : rtems / c / src / lib / libcpu / sparc / reg_win / window.S
>> *
>> *
>> SYM(window_underflow_trap_handler):
>>
>> /*
>> * Calculate new WIM by "rotating" the valid bits in the WIM left
>> * by one position. The following shows how the bits move for a
>> SPARC
>> * cpu implementation where SPARC_NUMBER_OF_REGISTER_WINDOWS is 8.
>> *
>> * OLD WIM = 76543210
>> * NEW WIM = 07654321
>> *
>> * NOTE: New WIM must be stored in a global register since the
>> * "save" instruction just prior to the load of the wim
>> * register will result in the local register set changing.
>> */
>>
>> mov %wim, %l3 ! Calculate new WIM
>> sll %l3, 1, %l4 ! l4 = WIM << 1
>> srl %l3, SPARC_NUMBER_OF_REGISTER_WINDOWS-1, %l5
>> ! l5 = WIM >> (Number Windows-1)
>> or %l5, %l4, %l5 ! l5 = (WIM << 1) |
>> ! (WIM >> (Number Windows-1))
>> mov %l5, %wim ! load the new WIM
>> nop; nop; nop
>> restore ! Two restores to get into the
>> restore ! window to restore
>> ldd [%sp + 0x00], %l0 ! First the local register set
>> ldd [%sp + 0x08], %l2
>> ldd [%sp + 0x10], %l4
>> ldd [%sp + 0x18], %l6
>> ldd [%sp + 0x20], %i0 ! Then the input registers
>> ldd [%sp + 0x28], %i2
>> ldd [%sp + 0x30], %i4
>> ldd [%sp + 0x38], %i6
>> save ! Get back to the trap window.
>> save
>> jmp %l1 ! Re-execute restore.
>> rett %l2
>>
>> From my understanding this code should not ever fail, is that correct?
>> What I'm not sure is that if this type of trap can be a
>> common occurrence or if that means something went bad in the software.
>>
>> Basically now I removed the save/restore and it seems to be working fine
>> but I'll have to explain exactly what was happening before.
>> Is the compiler not expecting the user to add save/restore and could that
>> lead to the behavior we see sometimes (processor reset). What are the usual
>> way to handle this type of inline assembly? Never use save/restore?
>>
>> Also our customer gave us a sequence of command to send to the software
>> that would produce this reset systematically however when we got the
>> equipment over here, I tried with the same code the sequence and it is not
>> happening as often as they say. There seem to be a lot of randomness to
>> this problem.
>>
>> I really hope someone can provide some knowledge on this type of issue.
>> --
>> *
>> *
>> *Léonard Bise*
>> Software Design Engineer
>> Direct Line +41 (0)32 338 9902
>>
>> *SYDERAL SA*
>> Neuenburgstrasse 7
>> CH-3238 Gals (Switzerland)
>> Desk Line +41 (0)32 338 9800
>> Web Site http://www.syderal.ch
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130423/0f78d00c/attachment-0001.html>
More information about the users
mailing list