[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <550452A6-49D8-4CED-91E1-5F5A9AE4A33E@cognitive-electronics.com>
Date: Wed, 3 Dec 2014 11:34:02 -0500
From: Glenn Weinberg <glenn@...nitive-electronics.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Further limits/stdint issues
> On Dec 3, 2014, at 12:03 AM, Rich Felker <dalias@...c.org> wrote:
>
> On Tue, Dec 02, 2014 at 11:10:58PM -0500, Glenn Weinberg wrote:
>>
>>> On Dec 2, 2014, at 8:02 PM, Rich Felker <dalias@...c.org> wrote:
>>>
>>> The fast16/fast32 types and limits are still in bits/stdint.h despite
>>> not varying between archs. Removing those would make bits/stdint.h
>>> tiny/trivial. Aside from PAGE_SIZE, both bits/limits.h and
>>> bits/stdint.h would essentially have no information except
>>> "long/pointer size" and maybe we could even eventually eliminate them
>>> by having a global idea of "wordsize".
>>
>> I don't think it's safe to make such assumptions. Our architecture
>> is native 64-bit, so we define all the fast types as 64-bit.
>
> Could you elaborate on your motivations? There's no inherent reason
> that the fast types should be defined as 64-bit just because the
> native word size is 64-bit, and there are lots of reasons against it.
I can, although I need to be a bit circumspect because our product won't be in the market for another year or so and thus we're not exposing all the details yet.
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.
> Lots of people misinterpret the "fast" types as "fast unit for moving
> data", i.e. in the sense of "given N bytes of data to move, what's the
> fastest type to move it as?" This is not the meaning the C language
> assigns to them; in fact this sense is rather meaningless since C does
> not permit the aliasing that would be needed to move data as any type
> other than its actual type or a character type.
Don't think I'm one of those people, but I've been wrong before :-)
> Rather, "fast" is a matter of "given N values, possibly with just N=1,
> what type should be used to optimize operations on the value(s)?" In
> this sense, it's almost always best for the fast type to be the same
> as the least type, unless the least type incurs some heavy penalty
> (e.g. a machine that can't do 16-bit loads and stores and has to
> emulate them with byte loads/stores or atomic cas on larger words).
> As an example, take x86_64, where glibc made their [u]int_fast32_t
> types 64-bit. Addition and subtraction are the same speed for 32- or
> 64-bit operations, and perhaps multiplication is too (?), but division
> is significantly slower for 64-bit, and perhaps more importantly,
> using 64-bit storage doubles the number of cache lines you use and
> effectively halves the size of your cache.
While we have 8, 16 and 32-bit loads and stores that promote into/demote from a 64-bit register, there is a penalty for stores of less than 64 bits.
> If you have a good reason that the fast types should be 64-bit on some
> archs, I'd like to hear it. I'm open to listening to alternative views
> on this.
I hope this explains our reasoning sufficiently. If not, I'd be happy to discuss this further privately.
Regards,
Glenn
--
Glenn Weinberg
Vice President, Product
Cognitive Electronics, Inc.
www.cognitive-electronics.com
glenn@...nitive-electronics.com
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
