gamedevlists-general

Re: [GD-General] The joy of type aliasing and C

[Alen L. <ale...@cr...>]

> I think the aliasing rules
> make it easier to compete with fortran compilers here.

Of course, I understand the reasoning on why hidden aliasing needs to
reduced/eliminated. But if some part of code _needs_ to access the bit pattern
of some data then there must be a legal way to tell the compiler "look, I'm
doing something nasty here". Is there?

> The problem with int x=*(int *)&f; is sort of side effect here.
> I don't really know for sure why there must be a problem,
> because the aliasing of the values is sort of obvious, and could
> be deduced separately.

Seconded.

Alen

RE: [GD-General] The joy of type aliasing and C

[Neil S. <ne...@r0...>]

> The problem with int x=*(int *)&f; is sort of side effect here.
> I don't really know for sure why there must be a problem, 
> because the aliasing of the values is sort of obvious, and 
> could be deduced separately.  Maybe the comittee just wanted 
> to keep the definitions simple?

The aliasing in that example is fairly obvious, but it can easily become
non-obvious, which is why compilers give you the option to switch "assume no
aliasing" off.

Optimisation with optimal handling of aliasing is a virtually unsolvable
problem in C/C++, as they give you more than enough rope to hang yourself
several times over. The committees have tried to go down the "tightening up"
route, where they make it illegal to do certain things that will break the
optimiser but this has, on the whole, failed, mainly because the compilers
can't stop you doing it.

The "restrict" keyword was another attempt to solve the problem, by letting
programmers tell the compiler which pointers it is safe to assume no
aliasing on. The advantage of this approach is that the optimiser will not
make any mistakes, the downside being that the compiler will not be able to
perform certain optimisations without it, so you have to put it almost
everywhere if you want full optimisation. You could argue that you only need
full optimisation in a few places, so the use of restrict could be kept
quite small in practice.

An alternative would be to have an "alias" keyword, which is used to tell
the compiler what *not* to perform these optimisations on. The obvious
advantage is that it will optimise a lot more stuff, but the penalty is that
if you forget to use it where it's needed, your code will break.

- Neil.

RE: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> An alternative would be to have an "alias" keyword, which is used
> to tell the compiler what *not* to perform these optimisations on.

Casting to a void * or (unsigned) char * will force this.

Brian

RE: [GD-General] The joy of type aliasing and C

[Neil S. <ne...@r0...>]

> 
> Casting to a void * or (unsigned) char * will force this.
> 

Hmm, slightly freakish though. Also, I think I prefer the idea of using
"restrict" to tell the compiler what's safe to bugger about with, rather
than it assuming everything's fair game until it sees one of these casts,
especially when it rarely knows what it's safe to assume.

- Neil.

Re: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> Surely, most hardware cannot work with float16 natively, but it is
> still useable for lossy compression of some data. As long as I
> define what I want my float16 to look like, it is not less portable
> than any other user defined type.

Sure.

> Generally, trying to look at a float as if it's some kind of a
> black box that stores real numbers, is kinda silly. 

I think this depends entirely on the application's domain.  A lot of 
applications will merrily use a float and perform floating point 
operations and have no care at all whether the underlying 
implementation is IEEE-754 or some freakish VAX implementation.

> You have to be
> aware of its internal representation, or you can't work with it
> (without getting yourself into various precision losses, etc). 

You can inspect an implementation's internal representation by using 
<float.h> and inspecting the associated predefined constants.  These 
are a part of the C standard and must exist on all implementations 
that claim to adhere to it.  These will give you the min, max, radix 
(FLT_RADIX), precision in digits (FLT_DIG), etc.

I feel so ashamed for knowing this stuff...

Brian

Re: [GD-General] The joy of type aliasing and C

[Colin F. <cp...@ea...>]

>>> that claim to adhere to it.  These will give you the min, max,
>>> radix (FLT_RADIX), precision in digits (FLT_DIG), etc.
>>>
>>> I feel so ashamed for knowing this stuff...

Well, maybe you'd feel a little less ashamed if you took a
look at Section 2.1 of Game Programming Gems 2: 
"Floating-Point Tricks: Improving Performance with IEEE
Floating Point" (Yossarian King, Electronic Arts Canada).
It's 14 pages of this stuff!

It begins like this (which is "aliasing" not "punning", right?):

  typedef union
  {
  int   i;
  float f;
  } INTORFLOAT;

The author points out that "(int)f" costs about 60 cycles
on a Pentium II, and then shows the following faster code:

  INTORFLOAT  n;     // floating-point number to convert
  INTORFLOAT  bias;  // "magic" number

  bias.i = (23 + 127) << 23; // bias constant = 1 x 2^23
  n.f = 123.456f;            // some floating-point number

  n.f += bias.f; // add as floating-point
  n.i -= bias.i; // subtract as integer
  // n.i is now 123 - the integer portion of the original n.f

The author says this reduces the conversion time from 60 cycles
to about 5 cycles (assuming everything is in cache).  Wow!

Later in the article the author mentions a fast absolute
value:

  INTORFLOAT  ftmp;
  ftmp.f = f;
  ftmp.i &= 0x7fffffff;
  f = ftmp.f;

But I'm not sure how this compares with the inline __fabs()
instruction.

The author shows an improved version of the old square-root
trick (bit shift followed by add), taking about 16 cycles 
instead of 80 on a Pentium II; five times faster.

The Intel "Software Optimization Cookbook" (2002) has fun items
like this:

  float FastSqrt( float f )   // roughly 5% error
  {
    float RetVal;
    __asm
      {
      mov  eax, f
      sub  eax, 0x3f800000
      sar  eax, 1
      add  eax, 0x3f800000
      mov  RetVal, eax
      }
  return RetVal;
  }

But, check it; they have the following code on p. 157
(taken out of context):

  return (*((int *)&f) - IT_FTOI_MAGIC_NUM) >> 1;

Type punning!  Intel compiler?

--- Colin

Re: [GD-General] The joy of type aliasing and C

[Alen L. <ale...@cr...>]

>> Generally, trying to look at a float as if it's some kind of a
>> black box that stores real numbers, is kinda silly.
>I think this depends entirely on the application's domain.  A lot of
>applications will merrily use a float and perform floating point
>operations and have no care at all whether the underlying
>implementation is IEEE-754 or some freakish VAX implementation.

True, but I happen to work in such domain that just I have to care. But I
guess we all do. ;)

>You can inspect an implementation's internal representation by using
><float.h> and inspecting the associated predefined constants.  These
<...>
I am aware of that, but I don't find it particularly useful, except for
stuff like: assert(FLT_MANT_DIG>=24). Honestly, have you ever made an app
that dynamically adjust itself depending on number of bits in mantissa? Most
code I see uses things like typedef int INT32; and adjusts it with #ifs for
different platforms. Not to say that a generic int shouldn't be available,
for people that want it, but for sanity sake, standards could just add
int16, int32 etc. and get over with the mess. Am I wrong?

Alen

Re: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> but for sanity sake, standards could just add int16, int32 etc. and
> get over with the mess. Am I wrong?

They already have.  As of C99, there's <stdint.h> and <inttypes.h> 
which had a host of types, including int16_t, uint32_t, etc.  There 
are also "fast" versions that are "at least this size, but may be 
larger", and constant macros for 64-bit values.

Brian

Re: [GD-General] The joy of type aliasing and C

[Alen L. <ale...@cr...>]

Whoops, pardon my ignorance!
This sounds like a good news. Which compilers support those?

Alen

----- Original Message -----
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Wednesday, December 31, 2003 5:51 PM
Subject: Re: [GD-General] The joy of type aliasing and C


> but for sanity sake, standards could just add int16, int32 etc. and
> get over with the mess. Am I wrong?

They already have.  As of C99, there's <stdint.h> and <inttypes.h>
which had a host of types, including int16_t, uint32_t, etc.  There
are also "fast" versions that are "at least this size, but may be
larger", and constant macros for 64-bit values.

Brian




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

Re: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> This sounds like a good news. Which compilers support those?

Any that claim C99 compliance.  While there are no 100% C99 compliant 
compilers out there, there are a lot of "mostly compliant" ones.  GCC, 
VC++ 7.x, Intel C/C++, Borland, etc. should all support <stdint.h> and 
<inttypes.h>

Brian

Re: [GD-General] The joy of type aliasing and C

[Alen L. <ale...@cr...>]

Erm, are you sure about that? Can't verify other compilers ATM, but for VC++
7.1 I can't find anything like that either in the docs or in the include
directory.

Alen

----- Original Message -----
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Saturday, January 03, 2004 16:13
Subject: Re: [GD-General] The joy of type aliasing and C


> This sounds like a good news. Which compilers support those?

Any that claim C99 compliance.  While there are no 100% C99 compliant
compilers out there, there are a lot of "mostly compliant" ones.  GCC,
VC++ 7.x, Intel C/C++, Borland, etc. should all support <stdint.h> and
<inttypes.h>

Brian

Re: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> Erm, are you sure about that? 

Nope, but my assumption has been that any compiler released since 2000 
on should have those, since it's not exactly difficulty technology to 
produce.

I know that GCC definitely has it, and I'm assuming CodeWarrior as 
well.  I'd be flatout flabbergasted if they didn't have it in MSVC 
7.x, but then again...I guess I wouldn't. =3D)

I don't blame a compiler vendor for being slow to implement some of 
the more radical features, like variable length arrays, variable 
argument macros, __func__, etc. but stdint.h and inttypes.h are 
trivial to implement.

Brian

RE: [GD-General] The joy of type aliasing and C

[Simon O'C. <si...@sc...>]

There's some interesting discussion about VC++ standards compliance =
here:

http://msdn.microsoft.com/chats/vstudio/vstudio_022703.asp=20

"Q: Follow-up on the C99 "varargs" question, what, if anything, from C99
will we see in the future from VC

A: In general, we have seen little demand for many C99 features. Some
features have more demand than others, and we will consider them in =
future
releases provided they are compatible with C++. It is more likely we'll
entertain C99 features if they are picked up in the next version of the =
C++
standard."


http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/vccore=
/html
/vcrefwhatsnewlibrariesvisualc70.asp

"Because the timing of the release of C99, this version of Visual C++ is =
not
conformant with that standard."=20


There aren't many other references to C99 compliance on MSDN, so they =
aren't
even really claiming partial conformance. Probably have to wait for =
Whidbey
for stdint.h and inttypes.h.


> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Brian Hook
> Sent: 04 January 2004 17:31
> To: gam...@li...
> Subject: Re: [GD-General] The joy of type aliasing and C
>=20
> > Erm, are you sure about that?=20
>=20
> Nope, but my assumption has been that any compiler released=20
> since 2000 on should have those, since it's not exactly=20
> difficulty technology to produce.
>=20
> I know that GCC definitely has it, and I'm assuming=20
> CodeWarrior as well.  I'd be flatout flabbergasted if they=20
> didn't have it in MSVC 7.x, but then again...I guess I wouldn't. =3D)
>=20
> I don't blame a compiler vendor for being slow to implement=20
> some of the more radical features, like variable length=20
> arrays, variable argument macros, __func__, etc. but stdint.h=20
> and inttypes.h are trivial to implement.
>=20
> Brian
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign=20
> up for IBM's Free Linux Tutorials.  Learn everything from the=20
> bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>=20
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.552 / Virus Database: 344 - Release Date: 15/12/2003
> =20
>=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.552 / Virus Database: 344 - Release Date: 15/12/2003
=20

Re: [GD-General] The joy of type aliasing and C

[Tom H. <to...@ve...>]

I don't have access to it, but this article supposedly goes into this topic 
in some detail.

http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm

Tom