[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141203170136.GL4574@brightrain.aerifal.cx>
Date: Wed, 3 Dec 2014 12:01:36 -0500
From: Rich Felker <dalias@...c.org>
To: Glenn Weinberg <glenn@...nitive-electronics.com>
Cc: musl@...ts.openwall.com
Subject: Re: Further limits/stdint issues
On Wed, Dec 03, 2014 at 11:34:02AM -0500, Glenn Weinberg wrote:
>
> > 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.
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. 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.
Rich
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.
