tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] casting bug?


From: Alexander Strasser
Subject: Re: [Tinycc-devel] casting bug?
Date: Mon, 18 Jul 2005 15:42:03 +0200
User-agent: Mutt/1.5.6+20040907i

Hi again,

  sorry for the late answer...

Felix Nawothnig wrote:
> Alexander Strasser wrote:
> >>Then we have "int" which is at least 16bit wide and should be the native 
> >>register size (I dunno if the standard specifically says this but that's 
> >>the way it was before the (x86) empire), so should be the "fastest" type 
> >>(unless we talk about 8-bit CPUs for which ANSI C isn't really suited 
> >>anyway :)
> >Ah back on topic, int isn't native register size on x86_64 anymore.
> 
> That depends on the compiler and not on the architecture ofcourse. Also 

  Of course that is what i meant, just was to lazy write
it out so detailed...

> some compilers allow you to choose between LP64 / LLP64.
> >And this breaks the assumption (which is afaik not really guaranteed
> >by the standard) I and many others (including you) made.
> 
> Not for x86_64 as 32bit operations are just as fast as 64bit ones (in 
> theory - gcc didn't properly optimize them but I think that was fixed 
> recently (?)).

  I am not sure about this, but I also don't have time to investigate.

> >>You can't have both a guaranteed size and guaranteed performance (while 
> >>being portable), so what would your proposed "int_fast32_t" be then?
> >It's not my proposed type, this exists already I don't know if it is
> >covered by C99 or not. But the trick would be let's say on a 64bit arch

  It is standard as you might have noticed while reading
Dave's post.

> >and a compiler using LP64 model (int is normally 32bit in this case) you
> >would still get a 64bit integer. It is not about having fixed 32 bits
> >it is more about having a at least 32bit wide type.
> 
> I see, you mean what_int_ought_to_be_t and what_long_ought_to_be_t :-)
> 
> >Well, of course it is not optimal if you target 16bit architectures in
> >that case you would have to use int_fast16_t.
> 
> Well, you rarely really need "at least 32bit" anyway (which is why it's 
> called long) and most likely not in performance critical code...

  2 scentences might have been less confusing here,
but yes (if i understood you correctly).

> >It's probably never really optimal, but it would be possible to use
> >practically at least. Best would be if the modern 64bit systems would
> >support for example the ILP64 model, and thus the good old int assumption
> >would still hold. But i think that train has already left and is far 
> >away...
> 
> I don't think so. Most new (UNIX) code is written with portability in 
> mind (often using the autotools), C99 usage (stdint) is widespread.
> 
> Most stuff would probably run with ILP64 - and for the stuff that 
> doesn't a #pragma and/or a commandline switch could be introduced...
> 
> Or maybe I'm just a bit naive...

  Well yes and no, but what i meant is it could have been
much simpler, and that train already left.

  Maybe the discussion is going way too offtopic here,
so let's just stop it for now.

  Alex (beastd)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]