RTEMS stack + TSIM-LEON2 weird behaviour

[Joel Sherrill]

Jiri Gaisler wrote:
> %sp is set either by the boot loader (mkprom), grmon
> or rdbmon (gdb stub). The %sp is also stored to an
> unused part of the trap table (0x7C0). This works
> fine without any problems on both simulator and
> real hardware ...
>   
I understand that but what is the purpose
of the sub instruction at line 228 of start.S?
It is using the original %sp in math to get
the starting stack.

Is the value of %sp always 0 here?  Or is it
possible to be non-zero? 

If it is always zero, then a mov would be safer.

If it is non-zero, does this statement make sense?

I trust the environment is right when the BSP
gets control.  I have never seen a problem but
the math just bothers me and there must be
a guarantee I am missing.

--joel
> Jiri.
>
> Joel Sherrill wrote:
>
>   
>> I don't disagree.  But why is the stack pointer set the way it is in
>> start.S? It assumes some value is in %sp from the invoking environment.
>> If that
>> isn't 0, it looks to me that the code doesn't work.
>>
>> --joel
>>     
>>> Jiri.
>>>
>>>
>>>
>>> Joel Sherrill wrote:
>>>
>>>       
>>>> Aitor.Viana.Sanchez at esa.int wrote:
>>>>
>>>>         
>>>>>> The initial value of %sp seens to be 0 on the sparc configurations I
>>>>>>
>>>>>>             
>>>>> have.
>>>>>
>>>>>           
>>>>>> So the sub instruction you highlighted above would set the %sp to
>>>>>> the area below the work space.
>>>>>>         This code hasn't changed in a LONG time and makes
>>>>>> assumptions about
>>>>>> the execution environment which I cannot personally guarantee.  Jiri
>>>>>> would be able to do so.
>>>>>>
>>>>>>             
>>>>> i am pretty sure (Jiri will correct me if I am wrong) that TSIM
>>>>> initializes %sp and %fp to allow direct RAM execution in case the SW
>>>>> does not have a bootstrap SW behind (e.g. mkprom)
>>>>>
>>>>>
>>>>>           
>>>>>> My first thought this morning is that this may have been a valid
>>>>>>
>>>>>>             
>>>>> assumption
>>>>>
>>>>>           
>>>>>> at one time (initial %sp is 0) but with more variations and starting
>>>>>> environments,
>>>>>> it may not be valid anymore.  I would guess that the "sub" statement
>>>>>>
>>>>>>             
>>>>> would
>>>>>
>>>>>           
>>>>>> be better changed to a "mov %l3, %sp" and ignore the inherited %sp.
>>>>>>
>>>>>>             
>>>>> I think this a good solution.
>>>>>
>>>>>
>>>>>           
>>>> It is certainly simple.  We need confirmation from Jiri or Daniel.
>>>>
>>>>         
>>>>> Regards,
>>>>>
>>>>> Aitor
>>>>>
>>>>>
>>>>>
>>>>>           
>>     


-- 
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