Hello list!
I was wondering if someone could explain why arrays in PD on 64-bit machines are messed up? I see in the bug on sourceforge that there are a couple of sub-optimal ways to solve this: what does that mean?
Shouldnt it be as easy as changing the array pointers from int to long? (I havent looked at the code and I think that I would just get lost if I did. Im not very good at programming.)
Thanks for the explination in advance! -thewade
On Sat, 19 Mar 2005, thewade wrote:
Hello list!
I was wondering if someone could explain why arrays in PD on 64-bit machines are messed up? I see in the bug on sourceforge that there are a couple of sub-optimal ways to solve this: what does that mean?
Shouldnt it be as easy as changing the array pointers from int to long? (I havent looked at the code and I think that I would just get lost if I did. Im not very good at programming.)
No, its not that easy. Maybe I find some time to implement a solution and upload a diff this week, so you can at least have the "hacky" solution.
Thanks for the explination in advance!
Here it goes:
Array don't store floats but unions of t_word, which are 64 bit broad on 64 bit architectures.
types of the temporary variables in all objects accessing array to double. (externals using float arrays have to be adapted too)
as floats in arrays (and read them as floats like it is now)
arrays (instead of ++ or []) and change all the occurrencers of all float array objects according to this. (Breaks all float array externals).
The second solution is the ugliest one, but would keep all float array reading objects happy. I actually had that implemented when I was regularily using the 64 bit alpha AFAICR.
Guenter
(PS: written down from memory. I would be happy to be wrong and there are better solutions)
-thewade
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list