On 10/31/2013 01:34 PM, Sebastian Huber wrote:
On 2013-10-31 13:21, Daniel Hellstrom wrote:
On 10/31/2013 12:38 PM, Sebastian Huber wrote:
On 2013-10-31 12:30, Daniel Hellstrom wrote:
I see that the cpu_set_word_t is set to 32-bit which suites most CPUs, there is
probably a good reason for it but would it make sens to make it dependent on
the architecture? So that 64-bit machines have it sized to 64-bits. I'm not
sure there are 16-bit SMP machines :) .
No, this should be a fixed size integer for all architectures to allow static
initialization. Anyway it will be a long way for RTEMS to support 33
processors.
So what is the point of having an array of 32-bits in the set? If there were a
16-bit SMP CPU would not performance be better to describe it with a 16-bit
instead of an 32-bit word? Its probably not realistic with a 16-bit SMP machine
anyway, more realistic is a 64-bit SMP machine. Would the atomicity of having a
64-bit word instead of 32-bit word on a 64-bit machine matter?
Performance of the operations at this API level is completely irrelevant. What
the implementation does with these CPU sets internally is something different.
Other operating systems don't have a static link-time configuration.
At this point we
haven't been discussing atomic cpusets, my guess is that other OSes have
definitions for that and in that case on a 64-bit machine it could make sens,
or what do you think?
What do you mean with "atomic cpusets".
Should have said atomic set, there are atomic counters defined so haveing an atomic set is not that far off. If multiple-cpus wants to enable/disable CPUs independently one can do that with atomic
sets. This is not important.
Daniel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
