[ODE] Re: ODE (and mainly OPCODE) for 64bits

[Frederic Marmond]

Ok,
that's what I was wondering.

But maybe it would be a good compromize, even in speed:
- this would occurs ONLY when on a 64bits system (32bits system keep
4bytes/pointers, unchanged)
- those systems are faster than 32bits ones
=> so, dispite of the 8 bytes/pointers waste, it may be faster to use opcode in
a 64bits than in a 32bits
=> it will allow to compile the entire application in 64bits, and so, the
general performances will be greater


making a kind of basepointer (64bits) + offset (32bits) won't work in a 64bits
system, as all memory segments may be mapped everywhere within the 64bits
space.
I haven't look deep into opcode, so, I may be wrong, and you allocate memory by
yourself (the base+offset may work if you allocate all your needed memory at
once, and you are sure that the segment fits in a 32bits space (I believe it
fits! ;)))

Fred


Selon Pierre Terdiman <pierre.terdiman at novodex.com>:

> Hi,
>
> > Well, I don't know, but it misses a typedef inside ICE:
> > for pointers...
> >
> > Actually in the code, pointers may be casted into udword, which are
> 4bytes.
> > In a 64bits AMD64 architecture, pointers are 8 bytes...
> > So, the warnings we see at compile time.
> >
> > I have no time to investigate more, and to add the pointer typedef (and I
> even
> > don't know if it is possible to make it fit into actual sctuctures)
> >
> > If Pierre wants, I can cooperate with him for that port... (if it is not
> > longer than 2 or 3 evenings...)
>
> As far as I'm concerned, storing an 8-bytes pointer within the Opcode
> structures is just not an option. The whole point was to save some memory, I
> obviously don't want to waste it now, especially to store useless data.
>
> So, porting Opcode to 64-bits isn't as simple as changing the pointer size.
> To do that correctly you have to replace all the pointers with (32 bit)
> indices, and give the collision code access to the base pointer (64 bit) so
> that it can recreate the correct addresses at runtime (which might be a
> small performance hit).
>
> Well, feel free to do it but I don't have time for this.
>
> - Pierre
>
>
>


--
Fred Marmond