Are you referring to cs4 or cs5?  I thought I had done that in cs5;
perhaps I did not finish it -- but using portaudio/libsndfile stopped
the details.   Look at the cs5 Attic, but why change cs4 now?
==John ffitch

Ben, 

Since you do not seem to have gotten any other responses, I thought I would
weigh in with my opinion (which may not mean much as I am by no means an
expert on any of this :).


On 11/2/04 5:42 PM, Ben Collver etched in stone:

> I would like to use WORDS_BIGENDIAN from config.h to make the functions
> in natben.c conditional (ie: on a big-endian system, benlong(x) == x).
> Are there any comments on this?

I would not change these without checking every occurence of where these
functions are called in the code and making sure that none of those calls
are assuming an unconditional byte swap.  If you can guarantee that (or use
WORDS_BIGENDIAN to conditionally call byte-swapping functions at appropriate
spots), then I do not see why this would be a problem.

> Another problem is that the code assumes that sizeof(long)==4.  On some
> platforms this is not true, ie: NetBSD/sparc64 has sizeof(long)==8, and
> the current code loses.

I did briefly mention this a little bit ago.  There are now several common
platforms with 64-bit CPUs (AMD 64, Apple PowerMac G5, etc).  However,
modifying Csound to not assume 4 byte longs (and also to check for ambiguous
usage of int) could be a HUGE task.  It is one that I think SHOULD be done
though, as users are likely to start wanting to compile optimized versions
for these CPUs.  If you are feeling up to the task, then by all means have
at it!  Just be warned that there are a lot of special bit-manipulation
tricks in Csound code (e.g. in table access for oscil), and special
hard-coded 32-bit values (e.g. in entry.c) that will need to be treated with
kid gloves.

Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/

I would definitely only attempt the 64-bit clean mods with CS5.  (Just my
opinion though).  The benlong() stuff though would be up to you.  (I am
using Cs4 and I am on a big-endian system too :)

Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/

On 11/3/04 10:18 PM, Ben Collver etched in stone:

> Should I drop cs4 and start trying to get cs5 to work?

Note that as an alternative to a forest of #ifdefs, it can all be done 
programmatically. I got this from the SNDAN sources (I use in pvfileio.c for 
reading PVOC_EX files), and  don't see why it wouldn't work just as effectively 
with a 64bit int:

static int byte_order()					
{						
   int   one = 1;
   char* endptr = (char *) &one;
   return (*endptr);
}

e.g:

int is_little_endian = byte_order();

Richard Dobson



Anthony Kozar wrote:

> I would definitely only attempt the 64-bit clean mods with CS5.  (Just my
> opinion though).  The benlong() stuff though would be up to you.  (I am
> using Cs4 and I am on a big-endian system too :)
> 
> Anthony Kozar
> anthony.kozar@utoledo.edu
> http://akozar.spymac.net/
> 
> On 11/3/04 10:18 PM, Ben Collver etched in stone:
> 
> 
>>Should I drop cs4 and start trying to get cs5 to work?
> 
> 
> 
> 

The build-time approach does in theory offer greater efficiency by avoiding the 
if test, at the cost of lots of #ifdefs. Of course, if this difference is 
significant (typically it will be dwarfed by the overhead of disk i/o), we will 
want the faster system.

Advantages of the programmatic apprach are:

(a) arguably tidier-looking than #ifdefs; can be useful in debugging
(b) for code not exclusive to Csound (such as pvfileio), one is not tied to a 
particular preprocessor symbol. If I had used say

#ifndef LITTLE_ENDIAN
....
#else
...
#endif

Either my code would have to be changed to use to new symbol, or that symbol 
would have to be added to the compiler list, one way or another.

Also (in situations where autoconf cannot be relied upon or isn't being used), 
this approach ~relies~ on the symbol being defined, or on  being correctly 
undefined. A fully robust solution is to require that either WORDS_BIGENDIAN or 
WORDS_LITTLE_ENDIAN must be defined, or the compiler will report an error. This 
is because it is meaningless to "default" to a certain byte-order; it ~must~ be 
one or the other!


Richard Dobson


Ben Collver wrote:

> That is an interesting idea to detect the byte order at run-time instead
> of build-time.  However, the build system (autoconf) is already checking
> it before build-time.
> 
> Why is
> 	if (is_little_endian) {
> 	...
> 	}
> better than
> 	#ifndef WORDS_BIGENDIAN
> 	...
> 	#endif
> ?
> 
> Cheers,
> 
> Ben
> 
> On Thu, Nov 18, 2004 at 05:29:47PM +0000, Richard Dobson wrote:
> 
>>Note that as an alternative to a forest of #ifdefs, it can all be done 
>>programmatically. I got this from the SNDAN sources (I use in pvfileio.c 
>>for reading PVOC_EX files), and  don't see why it wouldn't work just as 
>>effectively with a 64bit int:
>>
>>static int byte_order()					
>>{						
>>  int   one = 1;
>>  char* endptr = (char *) &one;
>>  return (*endptr);
>>}
>>
>>e.g:
>>
>>int is_little_endian = byte_order();
>>
>>Richard Dobson
> 
> 
> 
> 

Csound 5

find . -type f -print | xargs egrep -l '^long (ben|nat)long'
./Opcodes/natben.c
./Top/natben.c
./util1/scot/scot_main.c
./util1/scot/main.c
./util1/sortex/smain.c
./strings/makedb.c