Hi Robin! Thanks for the email! This is really awesome of you! We are actually the verge of releasing a 64-bit update of ChucK -- we'll definitely take this into account. I've attached our unified diff (between 1.3.0.2 and this version *so far*, which will soon be out as 1.3.1.0). This current update is based on Paul Bossier's 64-bit port for Ubuntu (for 1.2.0.8!), plus quite a bit of additional changes and re-factoring. It's also in an svn branch: https://chuck-dev.stanford.edu/svn/chuck/branches/64-bit/ (actually just merged it back into trunk too) Also additional notes below:

seeking to improve my ChucK setup's performance (and learning some more about the VM internals) I spent part of my weekend trying to get ChucK to compile as a 64-bit application. First I reapplied Steven Sinclair's patch posted some years ago on this list (fixing some other stuff along the way). Then I hacked together a fix for Chuck_Array usage.

The patches are based on ChucK 1.3.0.2 and a Jack-support patch by me. I can elaborate on the Jack-patch as well as I think it's quite useful... Can rebase the patches on SVN trunk if necessary. I could also host my fork on Github if that helps. I was only testing with linux-jack and never experienced the realtime audio issues Steven initially described. Tested with some ChucK examples and the ChucK setup I'm working on. Most stuff appears to be working. The performance increase I achieved is significant!

Can you elaborate on the Jack-support patch? So far we have our 64-bit version working on OS X, and have it compiling remotely on linux-jack (being remote, we haven't yet tested real-time audio via jack).

Some notes: * I don't like the way how integers must be machine-word-sized (yet alone because of frequent pointer-to-int casting). It'd better if the ChucK-internal datatypes are decoupled from the machine-word-size. When 64-bit support will be adopted people will run both 32-bit and 64-bit versions of ChucK. For the sake of ChucK script portability it would be nice if ChucK scripts ran with the same integer size on every machine. It should at least be possible to build a 32-bit ChucK using 64-bit ints or a 64-bit ChucK using 32-bit ints respectively.

Indeed. In our efforts so far, we've started to decouple dependency on type sizes. As you rightly point in your patch, sz_INT == sz_FLOAT on 64-bit systems. We actually introduced a mechanism (called "kindof", haha) in cases where we need differentiation in emit and instr. As for the integer size issue, we considered a lot of different options (including adding a 'long' datatype, similar to Java). The current thinking is that we'd "adapt" the integer size to the underlying platform. We will probably come back and revisit this again.

* The array patch is a hack really. I tried to fix the issue by turning Chuck_Array4 into a class for 1-word Chuck values, Chuck_Array8 for 2-word ChucK values, etc. This turned out to be a bad idea - because sometimes the array's actual C++ type matters and because sometimes a Chuck_Array e.g. for floats is used but the necessary Chuck_Array* type is machine-dependent (2-word floats vs. 1-word floats). Also, I find the Chuck_Array* implementation largely redundant and unnecessarily complex. I will try to revise Chuck_Array as a parameterized class that can be instantiated for every ChucK type. This should be much better. * Will also try to fix some array-related bugs in the process (bugs that also exist on 32-bit ChucK of course)

There is definitely a lot that needs work for the arrays. With much refactoring, we did get the current system to work on both 32-bit 64-bit, somwhat cleanly. The only misnomer in the code is that Chuck_Array4 is still named that, but on 64-bit systems, it holds 8-byte values.

Any thoughts, ideas, remarks?

This is really excellent of you - we've already start going through your patch, and while it takes a slightly different approach, there is much there to working in over time. Thank you very much! The 64-bit journey has certainly been a big team effort dating back several years (thanks also to Paul Brossier, Steven Sinclair, and others!) Would love to get your thoughts on we have so far (we are actually pretty close to releasing an update, which in usual chuck fashion we plan to "hot-fix" with rapid incremental updates). Rock on, Ge!