Large Capsicum patch for review.

[Christoph Mallon]

On 26.02.2013 13:13, Pawel Jakub Dawidek wrote:
> On Tue, Feb 26, 2013 at 11:43:12AM +0100, Dag-Erling Smørgrav wrote:
>> Pawel Jakub Dawidek <pjd at FreeBSD.org> writes:
>>> I use size_t as this is preferred type for size, but I don't need size_t
>>> for iterator, because I know the value will never need more than 16
>>> bits, so I use int as a more CPU-friendly type.
>>
>> Using int as an iterator can lead to warnings about signedness mismatch
>> in loop conditions etc., so you should at the very least use unsigned
>> int. [...]
> 
> I use 'int' for 'ssize_t' and 'unsigned int' for 'size_t'.
> 
>> [...] Besides, size_t is equal to unsigned long on all platforms, so
>> "CPU-friendly" is not a valid argument.
> 
> Is long more CPU-friendly than int?

Interestingly, yes:
32 bit ints or uints are stored in the lower half of a 64 bit register on AMD64.
All 32 bit operations automatically zero extend their result to 64 bits, i.e. the upper half is set to 0.
Comparing an uint with size_t can therefore done directly with a 64 bit comparison.
But to compare an int with an ssize_t, the int value has to be sign extended to 64 bits.
This takes another instruction (movsx) and an extra register to temporarily hold the sign-extended value.
On MIPS it's the other way round:
32 bit operations sign extend their result to 64 bits.
So comparing int and ssize_t can be done directly and uint+size_t costs another instruction.

In summary, mismatched types make the code harder to read and have the potential to force the compiler to produce worse code.

	Christoph