cpuset macro /vs/ inline implementation

[Sebastian Huber]

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.

-- 
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.