[pulseaudio-discuss] [PATCH v3] netbsd: Stop depending upon nonstandard __WORDSIZE

Pali Rohár pali.rohar at gmail.com
Thu Dec 17 04:33:42 PST 2015


On Thursday 17 December 2015 15:10:12 Andrey Semashev wrote:
> On 2015-12-17 14:50, Andrey Semashev wrote:
> >On 2015-12-17 02:44, Kamil Rytarowski wrote:
> >>
> >>On 16.12.2015 11:02, Pali Rohár wrote:
> >>>
> >>>Hi! There is probably no portable way for checking CPU type. But
> >>>you do not need to know CPU type here. You need to know if CPU has
> >>>fast 64bit numeric operations (and use 64bit speed optimization),
> >>>right?
> >>>
> >>>And this could be possible by checking size of int_fast32_t type
> >>>(defined in stdint.h). If is same as size of int_fast64_t type then
> >>>you could use 64bit optimization otherwise not (= 32bit integers
> >>>are faster then 64bit).
> >>>
> >>>But I will let this suggestion for reviewing of other people.
> >>
> >>This sounds like a good way to go.
> >
> >I don't think it does. int_fast32_t does not have to be 64-bit if 32-bit
> >integers are fast.

Yes. I did not wrote that int_fast32_t must be 64-bit. I wrote to
compare size of int_fast32_t and int_fast64_t.

> >It _may_ be larger than 32-bit if 32-bit integers are
> >slow (most likely - do not have the target hardware support). I don't
> >think this is the case for x32 or x86_64.

On 64bi x86 sizeof(int_fast32_t) is 8 and sizeof(int_fast64_t) also 8. On
32bit x86 sizeof(int_fast32_t) is only 4.

> >If integer performance is what this preprocessor check influences, I'd
> >suggest checking the size of size_t. Or testing for particular
> >architectures explicitly, with 64-bit being the default and 32-bit only
> >for the tested architectures (this would probably make the code more
> >easily maintainable in the future).
> 
> I've sent this privately in error.
> 
> Also, it seems size_t is 32-bit on x32, so disregard that suggestion.

Important question is: what you want to distinguish? It is not 32 vs 64
bit processor right? It is if architecture has 64bit long registers? Or
something else?

-- 
Pali Rohár
pali.rohar at gmail.com


More information about the pulseaudio-discuss mailing list