Re: Further limits/stdint issues

[Glenn Weinberg <glenn@cognitive-electronics.com>]

> On Dec 3, 2014, at 12:01 PM, Rich Felker <dalias@libc.org> wrote:
> 
> On Wed, Dec 03, 2014 at 11:34:02AM -0500, Glenn Weinberg wrote:
>> 
>> The fundamental answer is that our architecture does not define any
>> 8, 16 or 32-bit integer arithmetic operations. Integer add,
>> subtract, divide and remainder take 64-bit operands and produce a
>> 64-bit result; integer multiply, multiply-add and multiply-subtract
>> take 64-bit operands and produce a 128-bit result.
> 
> Thanks for the explanation. I don't see how this makes smaller
> operations "slow" though. The compiler will just generate the 64-bit
> operations and ignore the junk in the upper bits of the register,
> which will eventually get discarded when storing back to memory.

If the compiler doesn't limit intermediate results to 32 bits it's not preserving unsigned wraparound overflow semantics as required by the C standard.  Consider the following 32-bit pseudo assembly language implementing (0xffffffff + 2) / 2:

	r1 = 0xffffffff	// 0xffffffff
	r2 = 2		// 0x00000002
	r3 = r1 + r2	// 0x00000001 (Wraparound overflow)
	r4 = r3 / r2	// 0x00000000
	Store r4	// 0x00000000

Now consider it in 64-bit (without adding additional code to limit the value in r3):

	r1 = 0xffffffff	// 0x00000000ffffffff
	r2 = 2		// 0x0000000000000002
	r3 = r1 + r2	// 0x0000000100000001 (No overflow, 64-bit)
	r4 = r3 / r2	// 0x0000000080000000
	Store low32(r4)	// 0x80000000

> Is it
> just the cost of that store you're worried about? Being that there
> will be lots of 32-bit stores even if the fast32 type is 64-bit (e.g.
> everything that's plain "int" and things which are explicitly
> [u]int32_t), I would think you'd want/need 32-bit store to be fast
> anyway.


If it were free would we add 8, 16 and 32-bit arithmetic operations and fast 8, 16 and 32-bit stores to the hardware architecture?  Sure.  But it's not free, the architecture is what it is, and that is precisely the reason why the "fast" types should remain architecture-specific. 

	Regards,

	Glenn
--
Glenn Weinberg
Vice President, Product
Cognitive Electronics, Inc.
www.cognitive-electronics.com
glenn@cognitive-electronics.com