Effect of additionnal save/restore instructions

Leonard Bise leonard.bise at syderal.ch
Wed Apr 24 13:31:48 UTC 2013


Thank you Gedare for the input.
There is also something not very clear for me.
Claudio earlier told me that using %l7 register was not safe but how come?
Since it is a local register I'd expect I can do whatever I want with it?


2013/4/24 Gedare Bloom <gedare at rtems.org>

> This is a lot better. As Joel said, there is still a problem if an
> interrupt can come. For that you should use a general timer if available.
> Also, I made one comment below.
>
>
> On Wed, Apr 24, 2013 at 5:54 AM, Leonard Bise <leonard.bise at syderal.ch>wrote:
>
>> Thanks a lot for your inputs guys. I realise now that I actually didn't
>> know exactly how to write inline assembly code properly.
>>
>> Joel: Yes the goal of this function is to have a known number of cycles.
>> Thank you for your precious input.
>>
>> Here is the final code version we settled on.
>>
>> void SCET_wait_2us(void) {****
>>
>>     {****
>>
>>         /*#[ operation SCET_wait_2us() */****
>>
>>     uint32 count;****
>>
>>         /* Performs a 60us delay using an __asm__ __volatile__ loop, this
>> piece of code has been****
>>
>>          * measured on HW to validate the duration is correct */****
>>
>>     __asm__ __volatile__("set " XSTR(NB_ITER_60US) ", %0" : "=r"(count));
>> ****
>>
>>     __asm__ __volatile__("StartLoop1us:");****
>>
>>     __asm__ __volatile__("dec 1, %0" : "=r" (count));****
>>
>>     __asm__ __volatile__("cmp %0, 0" : "=r" (count));
>>
> While this should work, the count variable is actually an input here, so
> you really just need
> __asm__ __volatile__("cmp %0, 0" : :  "r" (count));
>
> As always, check the output of the assembler pass to make sure your
> function looks like how you expect. The compiler could (in theory) move
> data between memory and register within this code block.
>
>> ****
>>
>>     __asm__ __volatile__("bne StartLoop1us");****
>>
>>     __asm__ __volatile__("nop");****
>>
>>         /*#]*/****
>>
>>     }****
>>
>> }
>>
>>
>> 2013/4/23 Joel Sherrill <joel.sherrill at oarcorp.com>
>>
>>>  Hi
>>>
>>> SPARC register usage combined with the the register windowing
>>> makes things difficult to figure out.  Using save/restore in the middle
>>> of inline assembly like that is too scary for my personal taste. It is
>>> certainly not normal SPARC programming.
>>>
>>> I don't like the fact they used a "trivial" save instruction which adds
>>> 0 bytes to the stack as best I can tell. It is equivalent to
>>> "save %g0,%g0,%g0". Normal usage includes three real arguments
>>> and looks more like this:
>>>
>>>         PUBLIC(_CPU_Context_save_fp)
>>> SYM(_CPU_Context_save_fp):
>>>         save    %sp, -CPU_MINIMUM_STACK_FRAME_SIZE, %sp
>>>
>>> That saves space on the stack to save the window. I THINK the trivial
>>> save rotates the CWP but doesn't make space. I expect this would
>>> lead to a crash eventually as (my guess) is that you end up with
>>> two register windows associated with the same spot on the stack.
>>> You have rotated twice but only saved one hole on the stack. As
>>> you start returning and restoring, I expect this would result in
>>> some odd type of stack reuse.
>>>
>>> My first question is always ... Why is this in inline assembly anyway?
>>>
>>> If it is to do a tight loop with a known number of cycles, then the
>>> second round of questions are:
>>>
>>> + Why didn't they use the proper asm statement constraints?
>>> + Why isn't this asm volatile?
>>> + What happens if an interrupt occurs in the middle of this?
>>>
>>> If you are using a general purpose register gcc may use, then you need to
>>> specify that. Generally speaking, you can declare local variables and
>>> "pass"
>>> them to inline asm via constraint specifications. This lets gcc pick the
>>> register(s)
>>> and avoids one type of trouble.
>>>
>>> There are some asm with constraint examples in cpukit/score/cpu/sparc.
>>>
>>> --joel
>>>
>>>
>>> On 4/23/2013 4:02 AM, Leonard Bise 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
>>>
>>>
>>>
>>> --
>>> Joel Sherrill, Ph.D.             Director of Research & Development joel.sherrill at OARcorp.com        On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>> Support Available                (256) 722-9985
>>>
>>>
>>
>>
>> --
>> *
>> *
>> *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
>>
>>
>


-- 
*
*
*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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130424/1506bf25/attachment-0001.html>


More information about the users mailing list