Just curious, why wouldn't there ever be a 64-bit version of GEM?
I've been thinking that a 64-bit build of Pd-extended would be nice
to have, especially because using 64-bit floats as Pd's native format
would make it much more flexible. You could represent UNIX
timestamps properly, for example.

.hc

On Aug 3, 2007, at 1:19 PM, chris clepper wrote:

I have at least 4 MacPros running GEM here right now. Assuming you
want to run OSX there aren't that many problems related to the
Intel chips beyond the general decrease in performance over the
previous G5/PPC 970.

There is no 64bit version of GEM for OSX and there never will be one.

On 8/3/07, bigswift@cox.net < bigswift@cox.net> wrote: hi

i just received a new g5 and wanted to get tips and pointers and
caveats regarding pd on this machine, ideally it will run pd,Gem
and pdp/pidip etc..

links, frozen warnings etc... anticipated

pp

Patrick Pagano Sound and Light Technologist School of Theatre and Dance University of Florida

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

Mistrust authority - promote decentralization. - the hacker ethic

Hans-Christoph Steiner wrote:

Just curious, why wouldn't there ever be a 64-bit version of GEM?
I've been thinking that a 64-bit build of Pd-extended would be nice to have, especially because using 64-bit floats as Pd's native format would make it much more flexible. You could represent UNIX timestamps properly, for example.

Max/msp already uses doubles for its 'float' type, even on 32-bit versions. As Chris said, in a 64-bit build the floats stay 32 bit. You would have to declare them all as double instead. In pd the t_float would probably have to be changed to a pointer-to-double since the double is too big to fit in an atom (assuming that atoms must all be the same size). Perhaps a script could be written to change all the "float" to "double*" and prefix all the float assignments with "*". Also all the places where gcc complains about "type-punning", where a string of four bytes is interpreted as a float, would need to be looked at. And everywhere (especially in externals) float variables have been used instead of t_floats. And anywhere the guts of the float are manipulated directly (in osc~ this is done using a double). Martin