Re: [KJ] Re: [PATCH] drivers/isdn/hisax: ARRAY_SIZE instead of sizeof
G'day Andi, On 6/11/07, Andi Drebes <[EMAIL PROTECTED]> wrote: > I'd suggest to not use another define, but use ARRAY_SIZE(foo) > _instead of_ eg. FNCOUNT. I thought of this, too, but I tried to keep things consistent. Let me explain that a little bit more in detail. If you have a look at the files in drivers/isdn/hisax then you will see that a lot of array size definitions are assigned to preprocessor macros. So I thought removing just one of the macros while the other continue to exist would make the code a little bit more inconsistent. However, one might disagree about that. So here's another patch that includes the changes from the original patch and removes the FNCOUNT preprocessor definition. Perhaps the original authors of the files should decide wether they want to keep it or not. I think what was meant here was to remove _all_ the macros that you assigned to the ARRAY_SIZE() macro. If you look at the two advantages replacing code with the ARRAY_SIZE() macro has; 1. More readable/consistent code. 2. Faster compile times, because of less macros being defined. If you were to simply redefine other macro's to be an ARRAY_SIZE() macro, the code will still contain the original macro's that people will have to look up, so would _not_ be more readable/consistent and you now have two stages of macro replacement, so the code will actually take _longer_ to compile. So to get the benefit of this change you have to _remove_ all the macros that are somehow equivalent to ARRAY_SIZE(), and replace their use in the code, with an appropriate ARRAY_SIZE() usage. Darren J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [KJ] Re: [PATCH] drivers/isdn/hisax: ARRAY_SIZE instead of sizeof
G'day Andi, On 6/11/07, Andi Drebes [EMAIL PROTECTED] wrote: I'd suggest to not use another define, but use ARRAY_SIZE(foo) _instead of_ eg. FNCOUNT. I thought of this, too, but I tried to keep things consistent. Let me explain that a little bit more in detail. If you have a look at the files in drivers/isdn/hisax then you will see that a lot of array size definitions are assigned to preprocessor macros. So I thought removing just one of the macros while the other continue to exist would make the code a little bit more inconsistent. However, one might disagree about that. So here's another patch that includes the changes from the original patch and removes the FNCOUNT preprocessor definition. Perhaps the original authors of the files should decide wether they want to keep it or not. I think what was meant here was to remove _all_ the macros that you assigned to the ARRAY_SIZE() macro. If you look at the two advantages replacing code with the ARRAY_SIZE() macro has; 1. More readable/consistent code. 2. Faster compile times, because of less macros being defined. If you were to simply redefine other macro's to be an ARRAY_SIZE() macro, the code will still contain the original macro's that people will have to look up, so would _not_ be more readable/consistent and you now have two stages of macro replacement, so the code will actually take _longer_ to compile. So to get the benefit of this change you have to _remove_ all the macros that are somehow equivalent to ARRAY_SIZE(), and replace their use in the code, with an appropriate ARRAY_SIZE() usage. Darren J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[kj][RFC] roll macro's in bitops.h
G'day people,
I was looking at bitops.h and noticed there were a couple of inline roll
functions to operate on 32bit variables. (left and right)
I think that is a little bit dumb as they are constant width (only
32bits) due to it being an inline function, and was wondering if anyone
thought it would be useful to have some (variable sized) roll macros
instead.
I whipped these twp up as examples, but have not tested them yet.
#define RollRight(Data, Distance) \
({ typeof(Data) __a = Data; \
typeof(Distance) __b = Distance%(sizeof(__a) * 8); \
__a = ((__a>>__b) | (__a<<((sizeof(__a) * 8) - __b))) \
__a; \
})
#define RollLeft(Data, Distance) \
({ typeof(Data) __a = Data; \
typeof(Distance) __b = Distance%(sizeof(__a) * 8); \
__a = ((__a<<__b) | (__a>>((sizeof(__a) * 8) - __b))) \
__a; \
})
Also if these are useful I was wondering how to handle the existing
functions ? #define them out for the time being ?
#define rol32(a, b) RollLeft(a, b)
#define ror32(a, b) RollRight(a, b)
Darren Jenkins
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[kj][RFC] roll macro's in bitops.h
G'day people,
I was looking at bitops.h and noticed there were a couple of inline roll
functions to operate on 32bit variables. (left and right)
I think that is a little bit dumb as they are constant width (only
32bits) due to it being an inline function, and was wondering if anyone
thought it would be useful to have some (variable sized) roll macros
instead.
I whipped these twp up as examples, but have not tested them yet.
#define RollRight(Data, Distance) \
({ typeof(Data) __a = Data; \
typeof(Distance) __b = Distance%(sizeof(__a) * 8); \
__a = ((__a__b) | (__a((sizeof(__a) * 8) - __b))) \
__a; \
})
#define RollLeft(Data, Distance) \
({ typeof(Data) __a = Data; \
typeof(Distance) __b = Distance%(sizeof(__a) * 8); \
__a = ((__a__b) | (__a((sizeof(__a) * 8) - __b))) \
__a; \
})
Also if these are useful I was wondering how to handle the existing
functions ? #define them out for the time being ?
#define rol32(a, b) RollLeft(a, b)
#define ror32(a, b) RollRight(a, b)
Darren Jenkins
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
