gamedevlists-windows — List for discussing game development on the Windows platform

Re: [GD-Windows] memory alignment vs passing by value

[Dan T. <da...@ar...>]

Hmm now I'm confused. I'm going to make some statements and see if I 
can't show my ignorance in such a way that it can be corrected.

It seems weird that aliasing would be a problem - since everything is in 
4 bytes chunks. From what I understood about aliasing, that only 
mattered if you broke dword alignment, e.g.

unsigned char* pData = some_aligned_junk;
return *(pData + 1);   // hit 1 byte off the alignment produced by the 
compiler.

However everything he is dealing with is already in dwords, effectively, 
so this shouldn't be a problem...

Could it be that the compiler recognizes the dprod as const, and as such 
can inline it directly without creating the parameter as a new instance? 
i.e. the code effectively just drops in without any copy constructors 
being called at all, whereas with a reference, it still has to chase the 
pointers, making it a bit slower?

Does this make sense?

-Dan



Jon Watte wrote:

>>I measured the time of computing 100 million bilinear interpolation using
>>dot products, and changing the dprod operation to accept a const reference
>>instead of the const value makes the test run an order of magnitude
>>    
>>
>slower!!
>
>Is this Evil Aliasing, Part II ? You could find out by disassembling
>both versions and comparing. If it's re-loading through the reference
>pointer all the time, then it's probably aliasing related. References
>are really pointers, so they can introduce (false) aliasing hazards.
>
>Cheers,
>
>			/ h+
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Gamedevlists-windows mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
>
>  
>

Re: [GD-Windows] using typedef to create aligned types

[Brett B. <res...@ga...>]

Exactly, as I said it's only the start address.  If you have an array then 
it needs to be padded between each start address.

----- Original Message ----- 
From: "Andras Balogh" <bn...@ma...>
To: <gam...@li...>
Sent: Thursday, December 02, 2004 8:30 AM
Subject: RE: [GD-Windows] using typedef to create aligned types


> Let Fred be:
>
> class Fred {
> public:
> int helloiamfred;
> };
>
> then sizeof(Fred) will be 4
>
> but if I align the same class to 16 bytes:
>
> class __declspec(align(16)) Fred {
> public:
> int helloiamfred;
> };
>
> then sizeof(Fred) will be 16!!!
>
> The reason is that if you want an array of Freds, each have to be aligned,
> so it's not just the base address, that's changed, but the padding too!
>
> Look here for more info and examples:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm
> /msmod_18.asp
>
>
>
> Andras
>
>
>> -----Original Message-----
>> From: gam...@li...
>> [mailto:gam...@li...] On Behalf Of
>> Brett Bibby
>> Sent: Wednesday, December 01, 2004 4:12 PM
>> To: gam...@li...
>> Subject: Re: [GD-Windows] using typedef to create aligned types
>>
>> Not sure what kind of type Fred is, but Fred and Fred Aligned are the 
>> same
>> type, thus the same size.  They just _start_ at an aligned location in
>> RAM.
>> If Fred is a struct, your alignment doesn't say anything about the
>> alignment
>> of each element _within_ the struct.  If Fred is an element of a struct,
>> then that would effect the size of the struct it is contained within.
>>
>> If you are trying to align data within structs, it's better to pack them
>> nicely and align the struct start address than peppering code with
>> alignments everywhere.  There's a presentation about cache issues you
>> might
>> want to check out:
>>
>> http://www.gdconf.com/archives/2003/Ericson_Christer.ppt
>>
>> -Brett
>>
>> ----- Original Message -----
>> From: "Andras Balogh" <bn...@ma...>
>> To: <gam...@li...>
>> Sent: Thursday, December 02, 2004 7:45 AM
>> Subject: [GD-Windows] using typedef to create aligned types
>>
>>
>> > MSDN says that I can use typedef to make aligned versions of my types,
>> eg:
>> >
>> > typedef __declspec(align(16)) Fred FredAligned16;
>> >
>> > This works when I declare variables, eg:
>> >
>> > Fred fred1;
>> > FredAligned16 fred2;
>> >
>> > fred2 is 16 bytes aligned, while fred1 is not
>> >
>> > But the strange thing is that sizeof(Fred) == sizeof(FredAligned16) is
>> > true,
>> > even though Fred's size is not a multiple of 16 bytes...
>> >
>> > When I declare different types (ie. not using typedef), then the sizeof
>> > will
>> > be different because the aligned type will be padded to the next
>> multiple
>> > of
>> > 16 bytes.
>> >
>> > Is this a bug in the compiler??
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Andras
>> >
>> >
>> >
>> >
>> > -------------------------------------------------------
>> > SF email is sponsored by - The IT Product Guide
>> > Read honest & candid reviews on hundreds of IT Products from real 
>> > users.
>> > Discover which products truly live up to the hype. Start reading now.
>> > http://productguide.itmanagersjournal.com/
>> > _______________________________________________
>> > Gamedevlists-windows mailing list
>> > Gam...@li...
>> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>> > Archives:
>> > http://sourceforge.net/mailarchive/forum.php?forum_id=555
>> >
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://productguide.itmanagersjournal.com/
>> _______________________________________________
>> Gamedevlists-windows mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555 

RE: [GD-Windows] memory alignment vs passing by value

[Jon W. <hp...@mi...>]

> I measured the time of computing 100 million bilinear interpolation using
> dot products, and changing the dprod operation to accept a const reference
> instead of the const value makes the test run an order of magnitude
slower!!

Is this Evil Aliasing, Part II ? You could find out by disassembling
both versions and comparing. If it's re-loading through the reference
pointer all the time, then it's probably aliasing related. References
are really pointers, so they can introduce (false) aliasing hazards.

Cheers,

			/ h+

RE: [GD-Windows] using typedef to create aligned types

[Andras B. <bn...@ma...>]

Let Fred be:

class Fred {
public:
	int helloiamfred;
};

then sizeof(Fred) will be 4

but if I align the same class to 16 bytes:

class __declspec(align(16)) Fred {
public:
	int helloiamfred;
};

then sizeof(Fred) will be 16!!!

The reason is that if you want an array of Freds, each have to be aligned,
so it's not just the base address, that's changed, but the padding too!

Look here for more info and examples:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm
/msmod_18.asp



Andras


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Brett Bibby
> Sent: Wednesday, December 01, 2004 4:12 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] using typedef to create aligned types
> 
> Not sure what kind of type Fred is, but Fred and Fred Aligned are the same
> type, thus the same size.  They just _start_ at an aligned location in
> RAM.
> If Fred is a struct, your alignment doesn't say anything about the
> alignment
> of each element _within_ the struct.  If Fred is an element of a struct,
> then that would effect the size of the struct it is contained within.
> 
> If you are trying to align data within structs, it's better to pack them
> nicely and align the struct start address than peppering code with
> alignments everywhere.  There's a presentation about cache issues you
> might
> want to check out:
> 
> http://www.gdconf.com/archives/2003/Ericson_Christer.ppt
> 
> -Brett
> 
> ----- Original Message -----
> From: "Andras Balogh" <bn...@ma...>
> To: <gam...@li...>
> Sent: Thursday, December 02, 2004 7:45 AM
> Subject: [GD-Windows] using typedef to create aligned types
> 
> 
> > MSDN says that I can use typedef to make aligned versions of my types,
> eg:
> >
> > typedef __declspec(align(16)) Fred FredAligned16;
> >
> > This works when I declare variables, eg:
> >
> > Fred fred1;
> > FredAligned16 fred2;
> >
> > fred2 is 16 bytes aligned, while fred1 is not
> >
> > But the strange thing is that sizeof(Fred) == sizeof(FredAligned16) is
> > true,
> > even though Fred's size is not a multiple of 16 bytes...
> >
> > When I declare different types (ie. not using typedef), then the sizeof
> > will
> > be different because the aligned type will be padded to the next
> multiple
> > of
> > 16 bytes.
> >
> > Is this a bug in the compiler??
> >
> >
> >
> > Thanks,
> >
> > Andras
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://productguide.itmanagersjournal.com/
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=555
> >
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555

RE: [GD-Windows] memory alignment vs passing by value

[Andras B. <bn...@ma...>]

> Post your function if you can... its kinda hard to figure it out with what
> you say.

Sure, here's a simple sample :)

//______________________________________________________________
template <class T>
class Vector
{
public:
	union {
		T v[4];
		struct {
			T	x;
			T	y;
			T	z;
			T	w;
		};
	};

	Vector() {}
	Vector(T f): x(f), y(f), z(f), w(f) {}
	Vector(T ix, T iy, T iz = 0, T iw = 0): x(ix), y(iy), z(iz), w(iw)
{}
	operator T* () {return v;}
	__forceinline inline T dprod(const Vector u) const { return x*u.x +
y*u.y + z*u.z + w*u.w;}
};

//______________________________________________________________
typedef float f32;
typedef unsigned long int u32;
typedef Vector<float> v4f;

//______________________________________________________________
inline v4f interpolate_CPP_1(const f32 x, const f32 y, const v4f v[])
{
	f32 xy = x*y;
	v4f c(1-x-y+xy, x-xy, y-xy, xy);
	return v4f(
		c.dprod(v[0]),
		c.dprod(v[1]),
		c.dprod(v[2]),
		c.dprod(v[3])
	);
}
//______________________________________________________________

I measured the time of computing 100 million bilinear interpolation using
dot products, and changing the dprod operation to accept a const reference
instead of the const value makes the test run an order of magnitude slower!!
And I also did the same change in a vector math heavy graphics demo, and the
speed difference was remarkable!


Andras 

Re: [GD-Windows] using typedef to create aligned types

[Brett B. <res...@ga...>]

Not sure what kind of type Fred is, but Fred and Fred Aligned are the same 
type, thus the same size.  They just _start_ at an aligned location in RAM. 
If Fred is a struct, your alignment doesn't say anything about the alignment 
of each element _within_ the struct.  If Fred is an element of a struct, 
then that would effect the size of the struct it is contained within.

If you are trying to align data within structs, it's better to pack them 
nicely and align the struct start address than peppering code with 
alignments everywhere.  There's a presentation about cache issues you might 
want to check out:

http://www.gdconf.com/archives/2003/Ericson_Christer.ppt

-Brett

----- Original Message ----- 
From: "Andras Balogh" <bn...@ma...>
To: <gam...@li...>
Sent: Thursday, December 02, 2004 7:45 AM
Subject: [GD-Windows] using typedef to create aligned types


> MSDN says that I can use typedef to make aligned versions of my types, eg:
>
> typedef __declspec(align(16)) Fred FredAligned16;
>
> This works when I declare variables, eg:
>
> Fred fred1;
> FredAligned16 fred2;
>
> fred2 is 16 bytes aligned, while fred1 is not
>
> But the strange thing is that sizeof(Fred) == sizeof(FredAligned16) is 
> true,
> even though Fred's size is not a multiple of 16 bytes...
>
> When I declare different types (ie. not using typedef), then the sizeof 
> will
> be different because the aligned type will be padded to the next multiple 
> of
> 16 bytes.
>
> Is this a bug in the compiler??
>
>
>
> Thanks,
>
> Andras
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

RE: [GD-Windows] using typedef to create aligned types

[Andrew G. <ag...@cl...>]

You're changing the alignment, not the size.

Alignment determines where a variable will be allocated in memory, e.g
FredAligned16 will always be allocated on a 16 byte memory boundry but the
size of both types will be the same.


A.
 

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Andras Balogh
> Sent: Wednesday, December 01, 2004 3:46 PM
> To: gam...@li...
> Subject: [GD-Windows] using typedef to create aligned types
> 
> MSDN says that I can use typedef to make aligned versions of 
> my types, eg:
> 
> typedef __declspec(align(16)) Fred FredAligned16;
> 
> This works when I declare variables, eg:
> 
> Fred fred1;
> FredAligned16 fred2;	
> 
> fred2 is 16 bytes aligned, while fred1 is not
> 
> But the strange thing is that sizeof(Fred) == 
> sizeof(FredAligned16) is true, even though Fred's size is not 
> a multiple of 16 bytes...
> 
> When I declare different types (ie. not using typedef), then 
> the sizeof will be different because the aligned type will be 
> padded to the next multiple of
> 16 bytes.
> 
> Is this a bug in the compiler??
> 
> 
> 
> Thanks,
> 
> Andras
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide Read honest & 
> candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

[GD-Windows] using typedef to create aligned types

[Andras B. <bn...@ma...>]

MSDN says that I can use typedef to make aligned versions of my types, eg:

typedef __declspec(align(16)) Fred FredAligned16;

This works when I declare variables, eg:

Fred fred1;
FredAligned16 fred2;	

fred2 is 16 bytes aligned, while fred1 is not

But the strange thing is that sizeof(Fred) == sizeof(FredAligned16) is true,
even though Fred's size is not a multiple of 16 bytes...

When I declare different types (ie. not using typedef), then the sizeof will
be different because the aligned type will be padded to the next multiple of
16 bytes.

Is this a bug in the compiler??



Thanks,

Andras

Re: [GD-Windows] memory alignment vs passing by value

[Dan T. <da...@ar...>]

I'm not an expert by any stretch of the imagination, but here's my 
thoughts. (*actual* experts encouraged to pipe up, so I know where I'm 
being stupid)

>I don't know about other platforms/compilers, but with MSVC, passing a 4
>component floating point vector by value is far more efficient than passing
>it as a reference (could anyone explain why this is the case btw?).
>  
>
Huh. That doesn't seem to make sense. Passing by value means you'll be 
calling whatever copy constructor you have, and dumping that onto the 
stack (if I remember this stuff right. Who knows if I am). However a 4 
component float vector should be something like 16 bytes - and depending 
on your system the reference is 4 or 8 bytes. So the difference isn't a 
whole lot. My money is on the gains from the smaller parameter is 
getting lost in chasing the pointer down however many times you use it - 
or you are doing something like.

void MyFunc(vector4* pMyVec)
{
    vector4 holder = *pMyVec;
    // avoid copying onto the stack in the call, only to copy onto the 
stack in the body.
    // for a grand total of (sizeof(vector4*) + sizeof(vector4)) copied 
so far, less optimizations.
}

Of course, the best way to find out is to take a look at the generated 
asm for each, and see what is really going on.
If this is being called a lot, make sure you aren't busting cache 
lines... If you are calling by reference and the data is in the cache, 
then there really shouldn't be any problem with the pointer version as I 
understand it (provided you don't ask for local copies like in the 
example). Post your function if you can... its kinda hard to figure it 
out with what you say.

Not sure what you are going for with the aligning stuff. It was my 
understanding the compiler will align anything you need for speed (had 
this bite me with a struct a couple times).

-Dan

>One more thing that can help performance is correct alignment in memory.
>Problem is, when I my vectors are aligned, then I cannot pass by value
>anymore, I'm forced to use reference.
>
>These requirements knock each other out, so what can I do? :)
>
>The interesting thing is that I can still create local variables on the
>stack, and they will be correctly aligned, but it cannot align the passed
>parameters? Why?
>
>
>Thanks,
>
>
>Andras
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Gamedevlists-windows mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
>
>  
>

[GD-Windows] memory alignment vs passing by value

[Andras B. <bn...@ma...>]

I don't know about other platforms/compilers, but with MSVC, passing a 4
component floating point vector by value is far more efficient than passing
it as a reference (could anyone explain why this is the case btw?).

One more thing that can help performance is correct alignment in memory.
Problem is, when I my vectors are aligned, then I cannot pass by value
anymore, I'm forced to use reference.

These requirements knock each other out, so what can I do? :)

The interesting thing is that I can still create local variables on the
stack, and they will be correctly aligned, but it cannot align the passed
parameters? Why?


Thanks,


Andras

RE: [GD-Windows] Compiler code gen

[Jon W. <hp...@mi...>]

This is the well-defined behavior both of how arguments get
passed through ellipsis, and how the va_arg() macro works. It's
just one of those things, like "don't read memory after you've
free()-ed it" or "don't use single-equals in conditional
expressions." It bites you once, and you learn to deal with it.
The type promotion through ellipsis is how ALL arguments got
passed to functions back in K&R C -- just be grateful you have
the tighter ANSI type scoping for non-ellipsis arguments ;-)

Cheers,

		/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brett Bibby
Sent: Tuesday, November 30, 2004 3:56 PM
To: gam...@li...
Subject: Re: [GD-Windows] Compiler code gen


Doh! Not very many holes, but one new one.  My gripe with CodeWarrior is
that it recognizes the float being passed and promotes it to double from the
caller, then I try to retrieve it with the type float and obviously it knows
that it must promote that to double but doesn't.  I'm not sure it's a
standard problem as much as their implementation of the va_arg function.
Brett

Re: [GD-Windows] Compiler code gen

[Brett B. <res...@ga...>]

Doh! Not very many holes, but one new one.  My gripe with CodeWarrior is 
that it recognizes the float being passed and promotes it to double from the 
caller, then I try to retrieve it with the type float and obviously it knows 
that it must promote that to double but doesn't.  I'm not sure it's a 
standard problem as much as their implementation of the va_arg function.
Brett

----- Original Message ----- 
From: "Jon Watte" <hp...@mi...>
To: <gam...@li...>
Sent: Wednesday, December 01, 2004 6:06 AM
Subject: RE: [GD-Windows] Compiler code gen


>
>> I guess his point is that va_arg(ap, float) as defined is always going to
> do
>> the wrong thing because variable argument lists can never contain floats.
> I
>> don't know how that could be fixed, considering that va_arg() is
> essentially
>> a macro hack created to avoid adding language constructs.
>
> In C++, you could catch that use with a compile-time assert.
>
> In both C and C++ you can actually pass floats by using unions, and/or
> type punning. Thus, being able to specify float as the argument for
> va_arg() isn't entirely useless -- but, as many things, may cause hole
> in the feet of previously inexperienced programmers.
>
> Corollary: experience is directly proportional to the number of holes
> in your feet, thus more experienced programmers walk slower.
>
> Cheers,
>
> / h+
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

RE: [GD-Windows] Compiler code gen

[Jon W. <hp...@mi...>]

> I guess his point is that va_arg(ap, float) as defined is always going to
do
> the wrong thing because variable argument lists can never contain floats.
I
> don't know how that could be fixed, considering that va_arg() is
essentially
> a macro hack created to avoid adding language constructs.

In C++, you could catch that use with a compile-time assert.

In both C and C++ you can actually pass floats by using unions, and/or
type punning. Thus, being able to specify float as the argument for
va_arg() isn't entirely useless -- but, as many things, may cause hole
in the feet of previously inexperienced programmers.

Corollary: experience is directly proportional to the number of holes
in your feet, thus more experienced programmers walk slower.

Cheers,

			/ h+

Re: [GD-Windows] Compiler code gen

[Javier A. <ja...@py...>]

Jon Watte wrote:
>> I changed my va_arg(ap, float) to va_arg(ap, double) and it works
>> now. Thanks!  I think it's questionable that CodeWarrior doesn't do
>> the right thing when retrieving a float from from va_arg, but maybe
>> they have a good reason for doing it that way...
>
> Are you saying it's bad of CodeWarrior to follow the language
> standard, just like all other compilers?


I guess his point is that va_arg(ap, float) as defined is always going to do 
the wrong thing because variable argument lists can never contain floats. I 
don't know how that could be fixed, considering that va_arg() is essentially 
a macro hack created to avoid adding language constructs.

CodeWarrior is definitely innocent here.

-- 
  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] Compiler code gen

[Jon W. <hp...@mi...>]

> > I believe this is type promotion, as defined by the C/C++ language. You
> > should get the float arguments back out using va_arg(double). Sadly, the
> > C++ standards document just punts to the C standard document, so I can't
> > give you a definitive reference.

> I changed my va_arg(ap, float) to va_arg(ap, double) and it works now.
> Thanks!  I think it's questionable that CodeWarrior doesn't do the right
> thing when retrieving a float from from va_arg, but maybe they have a good
> reason for doing it that way...


Are you saying it's bad of CodeWarrior to follow the language standard, just
like all other compilers?


Cheers,

			/ h+

RE: [GD-Windows] Compiler code gen

[Paul B. <pa...@wi...>]

> -----Original Message-----
> From: gam...@li...=20
> To: gam...@li...
> Subject: Re: [GD-Windows] Compiler code gen
>=20
> I changed my va_arg(ap, float) to va_arg(ap, double) and it=20
> works now.=20
> Thanks!  I think it's questionable that CodeWarrior doesn't=20
> do the right thing when retrieving a float from from va_arg,=20
> but maybe they have a good reason for doing it that way...
> Cheers,
> Brett=20

As was noted before, this is part of the default argument promotions
that C and C++ define as standard.  This is more explicit in the ANSI
C standard (search for "default argument promotions" in your favorite
ANSI C spec).  The C++ version handwaves a bit when it comes to the
float, int, and enum promotions but (I think) the behavior is the
same.

Paul

Re: [GD-Windows] Compiler code gen

[Brett B. <res...@ga...>]

>Jon Watte wrote:
> I believe this is type promotion, as defined by the C/C++ language. You
> should get the float arguments back out using va_arg(double). Sadly, the
> C++ standards document just punts to the C standard document, so I can't
> give you a definitive reference.

I changed my va_arg(ap, float) to va_arg(ap, double) and it works now. 
Thanks!  I think it's questionable that CodeWarrior doesn't do the right 
thing when retrieving a float from from va_arg, but maybe they have a good 
reason for doing it that way...
Cheers,
Brett 

RE: [GD-Windows] Compiler code gen

[Jon W. <hp...@mi...>]

> After much looking at the code I can see that floats passed to variadic
> functions are having 8 bytes pushed onto the stack instead of 4 bytes.  If
I
> call a non-variadic function only 4 bytes are used.  Is this considered
> correct behavior for Windows?

I believe this is type promotion, as defined by the C/C++ language. You
should get the float arguments back out using va_arg(double). Sadly, the
C++ standards document just punts to the C standard document, so I can't
give you a definitive reference.

This program shows how it works (note: func2 is correct, func1 is
incorrect):




#include <stdarg.h>
#include <stdio.h>

void func1( int a, ... ) {
  va_list vl;
  va_start( vl, a );
  float f1 = va_arg( vl, float );
  float f2 = va_arg( vl, float );
  printf( "%f %f\n", f1, f2 );
}

void func2( int a, ... ) {
  va_list vl;
  va_start( vl, a );
  float f1 = va_arg( vl, double );
  float f2 = va_arg( vl, double );
  printf( "%f %f\n", f1, f2 );
}

int main() {
  func1( 1, 2.0f, 3.0f );
  func2( 1, 2.0f, 3.0f );
  return 0;
}



Cheers,

			/ h+

[GD-Windows] Compiler code gen

[Brett B. <res...@ga...>]

Hello,
I have a really bizarre problem that I'm trying to track down.  I got it 
down to one case that works and one that doesn't and hopefully somebody here 
can help shed some light on this for me.  The situation is that when I pass 
a float to one of my variadic functions, the paramters in the receiving 
function are not right.  If I change the variable to an integer it works 
fine.

After much looking at the code I can see that floats passed to variadic 
functions are having 8 bytes pushed onto the stack instead of 4 bytes.  If I 
call a non-variadic function only 4 bytes are used.  Is this considered 
correct behavior for Windows?  I assume that the variadic function should be 
popping the 8 bytes if it pushed it, but I can see in my memory dump that 
all parameters on the stack after floats appear are trashed.

My compiler is CodeWarrior.

Thanks,
Brett

RE: [GD-Windows] another devenv problem

[Jon W. <hp...@mi...>]

It will improve your full re-build speeds. However, it will 
make the incremental relink-relaunch cycle more painful. Also, 
we found, just when doing one of these gang files per library, 
that there are many files with dependencies on actually being 
a separate translation unit, because of naming of statics, or 
macros, or helper classes, or whatever.

We got this mechanism working, and used it for over a year, 
but we've stopped doing it now. Full builds are less common 
than single-file re-builds.

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Lewin, Gareth
Sent: Monday, November 15, 2004 3:05 PM
To: gam...@li...
Subject: RE: [GD-Windows] another devenv problem


Well you could create a master .cpp file, #include all the .cc files in
it, and make all of them non-build files. It will work, and as a side
issue it will improve you build speeds.

_________________________________________
Gareth Lewin - http://www.garethlewin.com

"Facts are useless. You can use facts to prove anything that's even
remotely true. Facts shmacts!" -- Homer Jay Simpson. 

> -----Original Message-----
> From: Chris Raine [mailto:c....@gm...] 
> Sent: Monday, November 15, 2004 4:11 PM
> To: gam...@li...
> Subject: RE: [GD-Windows] another devenv problem
> 
> On Mon, 2004-11-15 at 18:35, Jon Watte wrote:
> > The .sln and .vcproj files are text files. You can open 
> them and edit 
> > them. I suggest saving a copy of your .vcproj, then 
> changing one file 
> > and saving, then running diff on the project file. When 
> done, write a 
> > perl script to apply the same change for all files.
> > 
> > It is also sometimes possible to select more than one file 
> and make a 
> > change on many files at the same time in the property 
> pages. I don't 
> > recall whether this is one of those cases.
> > 
> > Cheers,
> > 
> > 			/ h+
> > 
> 
> I had also thought about writing a perl script, which parses 
> the devenv project files. But my perl-foo is too limited to 
> do such a task. And maintaining another piece of crypto-code 
> for every new devenv release (this unix code is going to 
> stick with us for a while) .... yuck.
> 
> I guess either living with the second solution (that actually 
> works - I feel quite stupid now), or going for SCons 
> (www.scons.org) or this boost-jam seems the only way to go. 
> 
> Thanks for the tip.
> 
> --
> regards,
> Chris Raine 
> 
> 


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5

RE: [GD-Windows] another devenv problem

[Lewin, G. <gl...@ea...>]

Well you could create a master .cpp file, #include all the .cc files in
it, and make all of them non-build files. It will work, and as a side
issue it will improve you build speeds.

_________________________________________
Gareth Lewin - http://www.garethlewin.com

"Facts are useless. You can use facts to prove anything that's even
remotely true. Facts shmacts!" -- Homer Jay Simpson.=20

> -----Original Message-----
> From: Chris Raine [mailto:c....@gm...]=20
> Sent: Monday, November 15, 2004 4:11 PM
> To: gam...@li...
> Subject: RE: [GD-Windows] another devenv problem
>=20
> On Mon, 2004-11-15 at 18:35, Jon Watte wrote:
> > The .sln and .vcproj files are text files. You can open=20
> them and edit=20
> > them. I suggest saving a copy of your .vcproj, then=20
> changing one file=20
> > and saving, then running diff on the project file. When=20
> done, write a=20
> > perl script to apply the same change for all files.
> >=20
> > It is also sometimes possible to select more than one file=20
> and make a=20
> > change on many files at the same time in the property=20
> pages. I don't=20
> > recall whether this is one of those cases.
> >=20
> > Cheers,
> >=20
> > 			/ h+
> >=20
>=20
> I had also thought about writing a perl script, which parses=20
> the devenv project files. But my perl-foo is too limited to=20
> do such a task. And maintaining another piece of crypto-code=20
> for every new devenv release (this unix code is going to=20
> stick with us for a while) .... yuck.
>=20
> I guess either living with the second solution (that actually=20
> works - I feel quite stupid now), or going for SCons=20
> (www.scons.org) or this boost-jam seems the only way to go.=20
>=20
> Thanks for the tip.
>=20
> --
> regards,
> Chris Raine=20
>=20
>=20

RE: [GD-Windows] another devenv problem

[Chris R. <c....@gm...>]

On Mon, 2004-11-15 at 18:35, Jon Watte wrote:
> The .sln and .vcproj files are text files. You can open them=20
> and edit them. I suggest saving a copy of your .vcproj, then=20
> changing one file and saving, then running diff on the project=20
> file. When done, write a perl script to apply the same change=20
> for all files.
>=20
> It is also sometimes possible to select more than one file and=20
> make a change on many files at the same time in the property=20
> pages. I don't recall whether this is one of those cases.
>=20
> Cheers,
>=20
> 			/ h+
>=20

I had also thought about writing a perl script, which parses the devenv
project files. But my perl-foo is too limited to do such a task. And
maintaining another piece of crypto-code for every new devenv release
(this unix code is going to stick with us for a while) .... yuck.

I guess either living with the second solution (that actually works - I
feel quite stupid now), or going for SCons (www.scons.org) or this
boost-jam seems the only way to go.=20

Thanks for the tip.

--=20
regards,=20
Chris Raine=20

RE: [GD-Windows] another devenv problem

[Chris R. <c....@gm...>]

On Mon, 2004-11-15 at 19:30, tweety wrote:
> Is there any reason you're not just renaming all the .cc files to .cpp
> files?
>=20
> ----------------------------------
> Peace and love,
> Tweety
> mi...@sy... - twe...@us...
> YahooID: tweety_04_01
>=20

Yip, during the old Playstation era with Alias PowerAnimator 9/10 we had
this huge and clunky ContentCreationEditor (nickname PAIN) running on
SGI. I am the poor fellow who has modernize it.=20

Somehow we might want to retain the possibility to pipe it through gcc
or the intel icc on Linux (or at least parts of it). IIRC, some
compilers (icc) had restrictions that the files had to be named .cc or
.c - same problem there, just the other way round.=20

--=20
regards,=20
Chris Raine=20

RE: [GD-Windows] another devenv problem

[tweety <mi...@sy...>]

Is there any reason you're not just renaming all the .cc files to .cpp
files?

----------------------------------
Peace and love,
Tweety
mi...@sy... - twe...@us...
YahooID: tweety_04_01

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Chris Raine
> Sent: Monday, November 15, 2004 8:55 AM
> To: gam...@li...
> Subject: [GD-Windows] another devenv problem
> 
> I have another devenv dilemma to add. 
> 
> I am currently supposed to port and maintain an old and large project
> from unix to win32, which is working out suprisingly well with the new
> studio 7.1 - except that *.cc files are still not fully supported.
> 
> I remember I had to set some registry values in devenv 6 to get it to
> compile *.cc files - in devenv 7.1 it recognizes and compiles them
> correctly, but I have to set the C++ project settings 
> manually for every
> single .cc file. 
> 
> With about 6 build configurations and >300 .cc files that is >300*6
> settings pages I have to configure manually.
> 
> I have searched the web and asked coworkers and friends - with no
> result, and if there is no solution, I will continue to beg for the
> permission to massively rename the >300 .cc files to .cpp - 
> or switch to
> a different build-system like scons or jam and use makefile projects. 
> 
> Is there a way to convince devenv that .cc files are exactly 
> the same as
> .cpp files and it should treat them in exactly the same way?
> 
> -- 
> regards, 
> Chris Raine 
> 
> 

RE: [GD-Windows] another devenv problem

[Jon W. <hp...@mi...>]

The .sln and .vcproj files are text files. You can open them 
and edit them. I suggest saving a copy of your .vcproj, then 
changing one file and saving, then running diff on the project 
file. When done, write a perl script to apply the same change 
for all files.

It is also sometimes possible to select more than one file and 
make a change on many files at the same time in the property 
pages. I don't recall whether this is one of those cases.

Cheers,

			/ h+

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Chris Raine
Sent: Monday, November 15, 2004 5:55 AM
To: gam...@li...
Subject: [GD-Windows] another devenv problem


I have another devenv dilemma to add. 

I am currently supposed to port and maintain an old and large project
from unix to win32, which is working out suprisingly well with the new
studio 7.1 - except that *.cc files are still not fully supported.

I remember I had to set some registry values in devenv 6 to get it to
compile *.cc files - in devenv 7.1 it recognizes and compiles them
correctly, but I have to set the C++ project settings manually for every
single .cc file. 

With about 6 build configurations and >300 .cc files that is >300*6
settings pages I have to configure manually.

I have searched the web and asked coworkers and friends - with no
result, and if there is no solution, I will continue to beg for the
permission to massively rename the >300 .cc files to .cpp - or switch to
a different build-system like scons or jam and use makefile projects. 

Is there a way to convince devenv that .cc files are exactly the same as
.cpp files and it should treat them in exactly the same way?

-- 
regards, 
Chris Raine