On 29/07/2021 15:01, Gedare Bloom wrote:
On Thu, Jul 29, 2021 at 12:56 AM Sebastian Huber
<sebastian.hu...@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.hu...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
