mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Renate Meijer <kleuske@xs4all.nl>
To: Dag Arne Osvik <da@osvik.no>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, linux-kernel@vger.kernel.org
Subject: Re: Use of C99 int types
Date: Sun, 3 Apr 2005 21:23:27 +0200	[thread overview]
Message-ID: <524d7fda64be6a3ab66a192027807f57@xs4all.nl> (raw)
In-Reply-To: <424FE1D3.9010805@osvik.no>


On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote:

> Stephen Rothwell wrote:
>
>> On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <da@osvik.no> wrote:
>>
>>> I've been working on a new DES implementation for Linux, and ran into
>>> the problem of how to get access to C99 types like uint_fast32_t for
>>> internal (not interface) use.  In my tests, key setup on Athlon 64 
>>> slows
>>> down by 40% when using u32 instead of uint_fast32_t.
>>>
>>
>> If you look in stdint.h you may find that uint_fast32_t is actually
>> 64 bits on Athlon 64 ... so does it help if you use u64?
>>
>>
>
> Yes, but wouldn't it be much better to avoid code like the following, 
> which may also be wrong (in terms of speed)?
>
> #ifdef CONFIG_64BIT  // or maybe CONFIG_X86_64?
>  #define fast_u32 u64
> #else
>  #define fast_u32 u32
> #endif

Isn't it better to use a general integer type, reflecting the cpu's 
native register-size and let the compiler sort it out? Restrict all 
uses of explicit width types to where it's *really* needed, that is, in 
drivers, network-code, etc. I firmly oppose any definition of "#define 
fast_u32 u64". This kind of definitions will only create needless 
confusion.

I wonder how much other code is suffering from this kind of overly 
explicit typing. It's much easier to make assumptions about integer 
size unwittingly than it is to avoid them. I used to assume (for 
instance) that sizeof(int) == sizeof(long) == sizeof(void *) at one 
point in my career. Fortunately, reality soon asserted itself again.

Regards,

Renate Meijer.


  parent reply	other threads:[~2005-04-03 19:18 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-03 11:55 Dag Arne Osvik
2005-04-03 12:05 ` Stephen Rothwell
2005-04-03 12:30   ` Dag Arne Osvik
2005-04-03 13:27     ` Andreas Schwab
2005-04-03 22:48       ` Dag Arne Osvik
2005-04-03 23:05         ` Al Viro
2005-04-03 23:17         ` Grzegorz Kulewski
2005-04-03 23:20           ` Dag Arne Osvik
2005-04-04  0:05         ` Adrian Bunk
2005-04-03 18:13     ` Al Viro
2005-04-03 23:03       ` Dag Arne Osvik
2005-04-04  3:08         ` Herbert Xu
2005-04-04  8:42           ` Dag Arne Osvik
2005-04-03 19:23     ` Renate Meijer [this message]
2005-04-03 20:25       ` Kenneth Johansson
2005-04-03 22:08         ` Kyle Moffett
2005-04-04 10:05           ` Renate Meijer
2005-04-04 10:50             ` Dag Arne Osvik
2005-04-04 20:30               ` Renate Meijer
2005-04-04 20:57                 ` Al Viro
2005-04-04 21:25                   ` Richard B. Johnson
2005-04-04 21:49                     ` Kyle Moffett
2005-04-05  9:23                       ` Renate Meijer
2005-04-05 11:27                         ` Kyle Moffett
     [not found]                           ` <09142f748cc6ad2bf4fffab7a5519226@xs4all.nl>
2005-04-05 22:11                             ` Kyle Moffett
     [not found]                               ` <eb65bccddde63541ae4b7b2d6c4c32d3@xs4all.nl>
2005-04-06 21:11                                 ` Kyle Moffett
2005-04-07 11:28                                   ` Renate Meijer
2005-04-05 12:18                       ` Richard B. Johnson
2005-04-05 21:47                         ` Kyle Moffett
2005-04-05  8:49                   ` Renate Meijer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=524d7fda64be6a3ab66a192027807f57@xs4all.nl \
    --to=kleuske@xs4all.nl \
    --cc=da@osvik.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®