Here is an initial attempt at a patch to make Chuck run on 64-bit architectures.
Mostly it only modifies chuck_instr.cpp and chuck_emit.cpp.
First I'll summarize the results so far and then describe the patches a little.
Result:
-------
This code seems to allow the Chuck VM to run on 64-bit platforms. I
haven't had 100% success with every computer I've tried it on, but I'm
able to run several test programs, with while loops. Function calls
seem to work, as do classes with member functions. I ran into
problems with the real-time audio, which I'll discuss below, however
time does seem to advance and using WvOut I'm able to generate a
seemingly good .wav file. I've only tested with SinOsc so far. Also,
I should note that the only code in chuck_instr.cpp that I have *not
touched* yet is the array stuff, which probably still has issues.
(Although, it seems I'm able to make int and float arrays okay, but I
would expect problems, seeing as the array types are based on byte
size.)
This has only been tested on Fedora and Ubuntu, it may work
differently on other platforms. (Particularly with other compilers if
I got the #ifdefs wrong for some particular case.)
Oh yes and the patches are generated against today's CVS.
Technical:
----------
The technique here is to change all the places that depend on byte
count or type assumptions and replace them with word sizes instead.
So, for example when the Reg_Push_Imm2 instruction is called, this no
longer for "floats", but for "types using 2 words". Correspondingly,
the emitter emits the 1-word instruction for floating-point values, so
Imm2 is only used for complex types.
So you'll see lots of replacements of things like "if ( ..
type->size==4)" with "if ( .. type->words()==1 )".
In general, word size is calculated by sizeof(type) / sizeof(long).
This is done in chuck_def.h, and a series of "wd_" macros are defined
similar to the "sz_" macros.
There is one special case where I couldn't see any alternative except
to use #ifdef, so I defined a macro called CK64BIT based on a few
common compiler macros used to define a 64-bit environment. This case
was for places that needed to agnostically refer to "some type" of a
particular word size. For example, lots of code referred to t_CKUINT
for a 1-word type and t_CKFLOAT for a 2-word type. This code didn't
actually need to know that it was a floating-point number, since it's
just copying memory from one place to another, but it needed a type of
the correct size. So I defined t_CK1WORD, t_CK2WORD, and t_CK4WORD
which are different depending on the architecture, and replaced
references of CKUINT to CK1WORD, and CKFLOAT to CK2WORD, etc.
Also, though arguably not necessary, there were also a lot of places
where CKUINT is used interchangeably with object pointers. I replaced
these with CKVOIDPTR. On both 32- and 64-bit architectures CKUINT and
CKVOIDPTR are the same size, but I thought it would be better to make
this more semantically accurate regardless.
Lastly there are a few places where a "zero" value is placed on the
stack. This was the only other place where I needed the CK64BIT
macro, which was to define some constants for the zero values, which
are of different sizes depending on the architecture. There was no
chuck_def.cpp to place these in so I stuck them in chuck_type.cpp
instead. Possibly memset() could be used here instead of using the
const values.
So, this was enough to get things running, but it seemed that if I
included a ugen in the test program Chuck would just hang. It turns
out this was some problem with RtAudio for ALSA, where snd_pcm_readn()
returns EPIPE indicating XRUN, but the XRUN flag is not set. I don't
know what the issue is, but I found that if snd_pcm_link() is not
called the problem doesn't occur, so I've included here a work-around
patch for now. I'm discussing this with Gary Scavone at the moment,
so hopefully we'll be able to fix it. (It occurs even with
RtAudio/STK 4.3.1, so he's interested in getting it working.) That
said, even with this patch it doesn't quite *sound* right. A sine
wave sounds all choppy and distorted, so it *might* have something to
do with RtAudio's byte swapping code, but I'm still investigating
this. The same script sent to a file with WvOut produces a good sine
wave, so it's certainly an RtAudio issue and not a deeper problem.
Finally, I was getting a segfault whenever an error message was
printed, and I think it's due to the handling of variable arguments in
the error handler, specifically the ap_list being used more than once
after va_start(), so I include here a separate patch for this issue.
....
So I've got to take a break from this now and do other things, because
this has been somewhat consuming me for a week. I found it an
interesting problem to solve, but the RtAudio issues are driving me
_crazy_. If anyone wants to try this patch and tell me how it goes,
I'd love to hear from you. I'll keep working on it eventually, but I
have to catch up now on other stuff.. :)
Steve
