I've been looking a little more into Chuck's issues with 64-bit platforms, and thought I should summarize what I've found. I have managed to get it running to a certain point, but of course many things don't work. But I got basic math and the <<<>>> operator working. No point posting a patch since it would be almost totally useless, but instead I'll describe it in english: By the way, everything I'll discuss here is flagged in the source, so Ge is of course aware of these things, but I thought it might help to start discussing it a bit. Basically the 64-bit problems come down to two issues, as far as I can see: - the stack pointer is divided by 4 instead of divided by 8. - assumptions of type depending on size=4 or size=8. How many issues are we dealing with? $ grep -e 'ISSUE' * | grep 64 | wc -l 70 This is not trivial, but you know, 70 seems kind of manageable. Where are they, mostly? $ grep -e 'ISSUE' * | grep 64 | cut -d: -f1 | sort -u chuck_emit.cpp chuck_instr.cpp util_opsc.h Hey, that's not bad, the problems are mostly just in these three files. Let's look at the different kinds of problems. Typically the type assumptions have lines like "size == 4" or "size == 8". $ grep -e '== 4' * | wc -l 38 $ grep -e '== 4' * | grep ISSUE | cut -d: -f1 | sort -u chuck_emit.cpp chuck_instr.cpp Okay, we can assume the type assumptions constitute about half of the issues. What about the divide-by-4 problems, which can simply be replaced by divide-by-8? These are usually something like ">> 2": $ grep -e '>> 2)' -e '>> 2 ' * | wc -l 49 $ grep -e '>> 2)' -e '>> 2 ' * | cut -d: -f1 | sort -u chuck_instr.cpp util_opsc.cpp util_sndfile.c We hit on a few more potential areas there, but it's still within the same ballpark. These divide-by-4 errors are pretty simple to fix anyways, just replace >> 2 with >> 3. So, in summary, the problems are concentrated in something like 70 to 80 lines of only 3 or 4 source files. The division problems can, I think, mostly be fixed with search-and-replace. The erroneous type assumptions will need more attention, for sure. It basically constitutes refactoring of the execution code for all instructions, making sure not to assume that 4-byte values are either integers or string pointers, and 8-byte values are floating point. imho it would be better to change this code to get the data type from the actual data type member of the Chuck_Type struct, which is *right there*, called "xid". There might be other issues hiding away, of course. And I haven't even begun looking at the DSP code, or any of the ugens, since I've stuck to simple test cases so far. However, I think there's a good chance that this could be solved with a little attention. Raking over the VM code didn't turn up any other major issues at first glance. By the way, this little excursion into the source made me notice that every single chuck instruction is executed as a virtual function. This means that for every instruction the struct must be dereferenced, and then it's vtable, and then the function can be called. This would be a great place to look into for optimization, I think. A jump table or big switch statement with inlined functions might be way faster. cheers, Steve