[chuck-users] Anyone else running ChucK dual-core in 64-bit mode?

Mark Pauley mpauley at mac.com
Sun Apr 29 16:40:16 EDT 2007

Not sure about linux, but I know that for darwin linking of 32 bit  
binaries to 64 bit binaries is impossible.  In the best case, you will  
have to do all sorts of tricks at the kernel level to allow 64 bit  
code (with pointers possibly way way up in the address space) to run  
in 32 bit mode.

Your particular seg-fault issue may be related to an invalid alignment  
problem.  If your OBJ_MEMBER_DATA macro evaluates to a value that  
isn't a multiple of the unsigned long size (8 bytes), then  
OBJ_MEMBER_UINT could effectively be causing an invalid instruction to  
be generated.

You could add a check to make sure that the value OBJ_MEMBER_DATA  
returns in OBJ_MEMBER_UINT is a multiple of 8.


On Apr 28, 2007, at 3:48 PM, Ken Restivo wrote:

> Hash: SHA1
> On Sat, Apr 28, 2007 at 05:06:29PM -0400, Ge Wang wrote:
>>>> He shook his head sadly at the use of macros instead of inline
>>>> functions, the use of casts to obliterate type safety, of #define's
>>>> instead of typedefs, and the obscuring of the likelihood that - 
>>>> >data is
>>>> a struct. He said, basically, this is C, not C++, regardless of  
>>>> what
>>>> the file extension says. I poked around some more and it looks  
>>>> like a
>>>> lot of the Ugen code was lifted from another, older project-- maybe
>>>> that was C code?
>> These are fair criticisms in general, but sometimes we do have our  
>> own
>> reasons for implementing things the way we do.  In other instances,  
>> we
>> probably should adopt better practices.  In the end, it's just how  
>> our
>> warped minds work.  Our goal isn't necessarily to make C++ happy, but
>> rather to make ChucK users happy (and fitter, and more productive).
> No prob. Love the Radiohead reference too. And thanks for taking the  
> time to reply, amidst preparing for your oral dissertation defense.
>>>> I'd be willing to do the gruntwork of search-and-replacing code, if
>>>> someone who knows what they're doing wants to tell me pretty much
>>>> exactly what to do. If nobody jumps up to do that over the next  
>>>> day or
>>>> two, it'd probably be a better use of time to start learning CSound
>>>> instead, and maybe have another look at ChucK in a few years if  
>>>> anyone
>>>> gets it 64-bit safe by then.
>> I think it's gonna take a system-wide evaluation/fixing/testing to  
>> make
>> things robustly 64-bit.  Until then it's hard to say what needs to be
>> done.  We are fully planning to do that at some future point.  For  
>> now,
>> is it possible to compile ChucK in 32-bit mode under linux (similar  
>> to
>> the 64-bit Apple G5)?
> That was the first thing I tried, last week: compiling with -m32.  
> Everything compiled, but the final link step failed, because it was  
> apparently trying to link to the 32-bit versions of the JACK  
> libraries, which obviously don't and can't exist on this system.  
> Maybe there's some way to convince GCC to link a bunch of 32- 
> bit .o's to 64-bit libraries?
>>> Ironically, I got interested in ChucK because CSound seemed a very
>>> kludgy way to do audio programming. - Oh well, there's always
>>> SuperCollider ;)
>> We think it's a good idea to learn as many languages as possible.
>> Different tools tailored for different tasks!
> And, for what I'm doing, I find ChucK a far more natural and user- 
> friendly language. So, I'll spend some time trying to get it running.
> - -ken
> Version: GnuPG v1.4.1 (GNU/Linux)
> EorX3o9C+iQqZmzQYtKAhNM=
> =KhYk
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

More information about the chuck-users mailing list