doubt about 'bool is_executing'

[Sebastian Huber]

On 29/07/2021 15:01, Gedare Bloom wrote:
> On Thu, Jul 29, 2021 at 12:56 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>>
>> On 28/07/2021 21:54, Gedare Bloom wrote:
>>> Hello all,
>>>
>>> In most (all?) the SMP ports, we have in the CPU Context Control:
>>>     bool is_executing;
>>
>> Yes, all SMP ports need this. It is used to implement a TTAS lock in the
>> context switch:
>>
>> https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_services.html#thread-dispatch-details
>>
>>>
>>> This variable often is accessed through assembly language (i.e.,
>>> during the context switch), using something like
>>> ARCH_CONTEXT_CONTROL_IS_EXECUTING_OFFSET. Unfortunately, the 'bool'
>>> type is not standard, or rather its size is implementation-defined.  I
>>> think it is generally an 8-bit value though for us. I see that the
>>> riscv port uses explicitly a uint32_t so that's nice.
>>>
>>> I think we should replace 'bool' with uint8_t in the other ports that
>>> are using byte-size accesses from assembly, just to be well-defined.
>>> Most likely, this doesn't actually affect anything and I'm just a
>>> little paranoid.
>>
>> Is the bool size and alignment not defined by the ABI? We don't have to
>> use this type, we could also use an uint32_t or whatever. The convention
>> is that a zero value is false, everything else is true.
>>
> I'm no expert, but I believe bool is defined by the compiler. There is
> only a minimum size requirement of 1 byte, but no maximum size. So, we
> do get consistent size, but we rely on gcc (and clang) to do the same
> thing with bool and to not change their behavior in the future. This
> is probably safe, but making assumptions about what compiler
> implementers do can lead us into trouble.

It would be quite bad for interoperability if the bool type is not 
defined by the ABI.  For example:

https://developer.arm.com/documentation/ihi0055/b/

> 
> I would switch to an explicitly sized type, either uint8_t or uint32_t
> depending whether alignment may be more useful than potential 3B space
> savings. Since we only deal with 32b and larger architectures with
> data caches, the use of smaller types doesn't offer any great time
> advantages.

I am not against using another type, however, I have no time to do this.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/