[PATCH 2/2] bsps/sparc: Add XtratuM BSP.

Gedare Bloom gedare at rtems.org
Wed May 21 13:56:23 UTC 2014


On Wed, May 21, 2014 at 9:53 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 2014-05-21 15:44, Gedare Bloom wrote:
>>
>> On Wed, May 21, 2014 at 4:37 AM, Daniel Hellstrom <daniel at gaisler.com>
>> wrote:
>>>
>>> On 05/21/2014 10:01 AM, Sebastian Huber wrote:
>>>>
>>>>
>>>> Hello Gedare,
>>>>
>>>> thanks for your review.
>>>>
>>>> On 2014-05-20 16:58, Gedare Bloom wrote:
>>>>>>
>>>>>>
>>>>>> @@ -54,7 +58,15 @@ SYM(_CPU_Context_switch):
>>>>>>>
>>>>>>>           ld      [%g6 + SPARC_PER_CPU_ISR_DISPATCH_DISABLE], %o4
>>>>>>>           ! save it a bit later so we do not waste a couple of cycles
>>>>>>>
>>>>>>> +#ifdef RTEMS_PARAVIRT_XTRATUM
>>>>>>> +        mov     %o0, %l6
>>>>>>> +        mov     sparc_get_psr_nr, %o0
>>>>>>> +        __XM_AHC
>>>>>
>>>>>
>>>>> I'm guessing these symbols are defined in xm.h?
>>>>>
>>>>>>> +        mov     %o0, %o2
>>>>>>> +        mov     %l6, %o0
>>>>>>> +#else /* RTEMS_PARAVIRT_XTRATUM */
>>>>>>>           rd      %psr, %o2
>>>>>>> +#endif /* RTEMS_PARAVIRT_XTRATUM */
>>>>>
>>>>>
>>>>> It would be cleaner code if you can write this get_psr as an assembler
>>>>> macro, e.g.
>>>>>
>>>>> .macro GET_PSR REG, TMP0
>>>>> #ifdef RTEMS_PARAVIRT_XTRATUM
>>>>>     mov %o0, \TMP
>>>>>     mov sparc_get_psr_nr, %o0
>>>>>     __XM_AHC
>>>>>     mov %o0, \REG
>>>>>     mov \TMP, %o0
>>>>> #else
>>>>>     rd %psr, \REG
>>>>> #endif
>>>>>
>>>>> Same for some of the other functions that get used multiple times in
>>>>> this file, such as set_psr, set_pil, and clear_pil. Putting these in a
>>>>> header file would make them useful in start.S also.
>>>>>
>>>>> [...]
>>>>>
>>>>
>>>> I also think that assembler macros could be useful here.
>>>>
>>>> Daniel, what is you opinion with respect to the usage of assembler
>>>> macros
>>>> in this file?
>>>
>>>
>>>
>>> Personally I prefer C preprocessor macros/defines mixed with the ASM code
>>> instead. If the RTEMS project uses ASM macros I'm fine with it.
>>>
>> I noticed there was a macro in that file already, so I guess there is
>> precedence for using them. Possibly this issue needs to be taken up at
>> a higher level as a coding convention practice, as to whether to avoid
>> ASM macros or not. I can see reasons for and against.
>
>
> This file is currently free of assembler macros (the one you probably have
> in mind disappeared with the commit
> 7c0bd74c87b141454ae17ee1cfeeba42dc4b0df2).
>
> The PowerPC heavily uses assembler macros in the exceptions support.  The C
> pre-processor can be a bit tricky with multi-line statements since it
> produces a one-liner.  I don't have a strong opinion for using assembler
> macros or not.
>
OK, the use of #ifdef..#endif is fine with me also. It can be left
as-is since Daniel prefers the CPP approach at least for this
particular case.

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.




More information about the devel mailing list