[quake3] first win64 patch

[Ludwig Nussel]

James Lacey wrote:
> -----Original Message-----
> From: Ludwig Nussel [mailto:ludwig.nussel at suse.de] 
> Sent: Monday, February 13, 2006 12:32 PM
> To: quake3 at icculus.org
> Subject: Re: [quake3] first win64 patch
> 
> James Lacey wrote:
> > -----Original Message-----
> > From: Ludwig Nussel [mailto:ludwig.nussel at suse.de] 
> > Sent: Monday, February 13, 2006 10:23 AM
> > To: quake3 at icculus.org
> > Subject: Re: [quake3] first win64 patch
> > 
> > On Monday 13 February 2006 05:19, James Lacey wrote:
> > > Here is my first Win64 Quake 3 patch. A couple of notes:
> > 
> > - Are all those int -> size_t (ie signed 32bit -> unsigned 64bit)
> >   changes actually needed? Did you verify they don't break stuff by
> >   looking at the code or by running the game? E.g. the loop in
> >   SV_Status_f, l could become negative (yeah the code is broken
> >   anyways)?
> > 
> > I did verify that the int -> size_t changes don't break anything as far as
> I
> > have played a couple of maps and everything seems to work fine. There was
> > one bug I can think of that was caused this way because of a for loop
> > "counting backwards" i.e. for(int i = SOME_NUMBER; i >= 0; i--). A lot of
> > the int to size_t changes were for file system and memory functions. Not
> > that realistically Quake 3 needs to address more than 4 GB of memory but I
> > made the changes so that it was clean 64-bit code. Besides, isn't it good
> > practice to use size_t for things like length and size?
> 
> > Yes it is but personally I'm not very keen to debug the non obvious
> > problems it causes when blindly changing the existing (and working!)
> > code. There is btw also no need to use a 64bit type if a 32bit one
> > suffices. On x86_64 the code size to process 64bit integers is
> > larger than for 32bit integers.
> 
> Perhaps this is just a matter of personal taste. I don't really think it
> makes debugging that much harder because if all you did was change int to
> size_t and something stops working, after you identify where the failure is,
> all you have to do is change it back. The reason I made the changes was
> because keeping things as int instead of size_t opened the door for possible
> (but not probable) data truncation.

If you find a place where it actually happens it's ok. It's
certainly not required to make q3 64bit clean as it already is (on
Linux).

> I don't know enough to dispute you, but why would the code size to process
> 64 bit integers be larger than 32 bit integers on a 64 bit CPU? 8 bytes
> would be the machine word. Nevertheless, since I don't really know, I will
> take your word for it.

Not 64bit CPUs in general, AMD64. The 64bit opcodes have a prefix
byte there. Search Google for "Software Optimization Guide for AMD64
Processors". I doubt that it matters much, I just wanted to say that
blindly changing variables to 64bit types is not necessarily a good
thing.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/