On 10/31/2013 02:44 PM, Sebastian Huber wrote:
On 2013-10-31 14:34, Daniel Hellstrom wrote:
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.
Sorry, I'm not sure I understand what you are saying or if we are saying the
same thing or that I'm just don't understand as usual :) All I meant with my
question was why specify it to 32-bit for all architectures? Why not have it
16-bit for 16-bit CPUs, 32-bit for 32-bit CPUs and 64-bit for 64-bit CPUs. I'm
not sure what that has to do with linking or maximum number of CPUs. Linux for
example have defined it to a unsigned long, which is a minimum 32-bit and on
some 64-bit machines will be 64-bit, I can't see what the problem is with that.
For the LEON it is better with a hard 32-bit definition, so I'm satisfied with
the current implementation.
In case this cpu_set_t is architecture specific, then your application configuration has to deal with this and this is bad. We may add CPU sets to the Configuration (rtems_configuration_table) in
the future.
Ok, I didn't think that far. Can't see that it would be a big problem though.
However that's a reason anyway which I'm not intending to get deeper into.
Thanks!
Daniel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
