Hi,
I have updated the linux build on CVS, basically disabling portaudio builds as it is done in the official 0.37 version.
We might have to add portaudio at some point, could be that it solves some problems that we have with alsa.
Other than that I read through the differences, and here is what makes the CVS version different from upstream:
- some t_int int issues, that caused build failures on 64 bit architectures - array drawing dirty flags - experimental quoting with '"' as in "hello world" .. but this is a hack and has probably to go away Don't ask who did that :) - SIMD functions for Windows (added by Thomas)
I think the SIMD functions are a great thing, and eventually it would be good to have these on all architectures. In this case it would be nice to have the assembler blocks in macros, and eventually in a different file (might be a .h as well).
Otherwise the code will get terribly fragmented and hard to read. What do you think ? is this feasable ?
Greetings,
Guenter
Quoting guenter geiger geiger@xdv.org:
- SIMD functions for Windows (added by Thomas)
I think the SIMD functions are a great thing, and eventually it would be good to have these on all architectures. In this case it would be nice to have the assembler blocks in macros, and eventually in a different file (might be a .h as well).
Where are these SIMD (MMX? SSE? SSE2?) functions in the CVS? I just did a checkout of the maiin branch and don't see where they are. I'd like to do some Altivec for pd at some point (GEM, LAME are ahead of it on the list), and want to see the x86 code.
cgc
Hi,
Quoting guenter geiger geiger@xdv.org:
- SIMD functions for Windows (added by Thomas)
I think the SIMD functions are a great thing, and eventually it would be good to have these on all architectures. In this case it would be nice to have the assembler blocks in macros, and eventually in a different file (might be a .h as well).
Where are these SIMD (MMX? SSE? SSE2?) functions in the CVS? I just did a checkout of the maiin branch and don't see where they are. I'd like to do some Altivec for pd at some point (GEM, LAME are ahead of it on the list), and want to see the x86 code.
the SIMD (SSE) functions are only in the devel branch of the CVS. Some major functions dealing with copying, setting, adding, multiplying data have been adapted. Please also note that for meaningful usage of SIMD the signal vectors have to be aligned (which is also taken care of in the devel version). In flext exists a detector function for various SIMD capabilities (in flsimd.cpp) too which i haven't implemented in PD yet (maybe flext should be implemented into PD ;-) )
In principle i also think that external assembler blocks would be better but i wasn't sure how to do it right since i'm not too familiar with the GNU assembler.
good gain, Thomas
On Tue, 7 Oct 2003, Thomas Grill wrote:
In principle i also think that external assembler blocks would be better but i wasn't sure how to do it right since i'm not too familiar with the GNU assembler.
I thought of something along the line of
#ifdef MSVC #include <s_simd_i86ms.h> #elseif GNU #include <s_simd_i86gnu.h> #elseif OSX #include <s_simd_powerpc.h> ....
The header files contain macros for the inline assembler on the different architectures and there is a non-optimized version too. The problem is that I don't know if this is flexible enough, or if there is more involved ...
The parts can be filled by "specialists" later, its just important to have the right structure at the beginning.
Guenter
On Tue, 7 Oct 2003, Thomas Grill wrote:
Hi Guenter,
- experimental quoting with '"' as in "hello world" .. but this is a hack and has probably to go away Don't ask who did that :)
call it a hack but i'd really like it to stay, be it in this or another way.
Its just plainly odd that when saving a patch with doublequoted symbols they show up the next time as backslash escaped ...
If it could be changed, it would be a really nice feature IMHO. For less confusion when doing both jMax and pd they could be single quotes too ... anyone knows how this is handled in Max ?
Guenter
If it could be changed, it would be a really nice feature IMHO. For less confusion when doing both jMax and pd they could be single quotes too ... anyone knows how this is handled in Max ?
In Max the leading and trailing quotes are different (and quite non-standard characters), a thing one wouldn't want for pd......
Thomas
On Mon, 6 Oct 2003, guenter geiger wrote:
- some t_int int issues, that caused build failures on 64 bit architectures
May I know what those are?
- experimental quoting with '"' as in "hello world" .. but this is a hack and has probably to go away Don't ask who did that :)
Actually, in jMax4, I voted against the use of doublequotes as symbol-delimiter, because I suggested that doublequotes would be reserved for strings, and then it has been decided that instead singlequotes would be used as symbol-delimiter.
Which brings me to the question: is there any plan of bringing garbage-collected strings to PD ?
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Mon, 6 Oct 2003, Mathieu Bouchard wrote:
On Mon, 6 Oct 2003, guenter geiger wrote:
- some t_int int issues, that caused build failures on 64 bit architectures
May I know what those are?
Well, not a big issue, happens that t_int have to be able to hold pointers (which means they have to be 64 bit on 64 bit architectures).
This is problematic when using it with the printf() family of functions, which expect to have 32 bit ints for the %d formatter ...
I cast it to 32 bit and hope that pd will not occupy more than 32 bit address space ...
- experimental quoting with '"' as in "hello world" .. but this is a hack and has probably to go away Don't ask who did that :)
Actually, in jMax4, I voted against the use of doublequotes as symbol-delimiter, because I suggested that doublequotes would be reserved for strings, and then it has been decided that instead singlequotes would be used as symbol-delimiter.
Which brings me to the question: is there any plan of bringing garbage-collected strings to PD ?
hmm, not that I know of. What would be the difference between symbols and strings ?
Guenter
Which brings me to the question: is there any plan of bringing garbage-collected strings to PD ?
hmm, not that I know of. What would be the difference between symbols and strings ?
The difference would be that non-resident strings don't clutter up the symbol space. Once in a while i come across applications that produce textual output (e.g. in video applications deailing with text or with gui stuff). In PD there is no way to avoid that these string results don't get fed into the symbol table and consequently slow down symbol lookup! until PD is restarted. I'd really appreciate the advent of garbage-collected strings in PD.
good gain, Thomas
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
The difference would be that non-resident strings don't clutter up the symbol space. Once in a while i come across applications that produce textual output (e.g. in video applications deailing with text or with gui stuff). In PD there is no way to avoid that these string results don't get fed into the symbol table and consequently slow down symbol lookup! until PD is restarted.
Thanks for this explanaition. This sounds bad.
I'd really appreciate the advent of garbage-collected strings in PD.
I think, that escaping then should be done right, which means, that we also need a way to escape limiters. I don't know if the current hack allows " inside a string.
ciao
On Monday, Oct 6, 2003, at 12:57 America/New_York, guenter geiger wrote:
I have updated the linux build on CVS, basically disabling portaudio builds as it is done in the official 0.37 version.
We might have to add portaudio at some point, could be that it solves some problems that we have with alsa.
Other than that I read through the differences, and here is what makes the CVS version different from upstream:
- some t_int int issues, that caused build failures on 64 bit architectures
- array drawing dirty flags
- experimental quoting with '"' as in "hello world" .. but this is a hack and has probably to go away Don't ask who did that :)
- SIMD functions for Windows (added by Thomas)
I think the SIMD functions are a great thing, and eventually it would be good to have these on all architectures. In this case it would be nice to have the assembler blocks in macros, and eventually in a different file (might be a .h as well).
Otherwise the code will get terribly fragmented and hard to read. What do you think ? is this feasable ?
On a similar note, I had actually just been thinking about coming up with a standard set of CPU targets for compiling too, taking advantage of the optimizations gcc can do, using:
ifeq(${ARCH},????) CFLAGS = endif
in the makefiles. If its done in a way that is easy to compile, then I would be willing to compile and distribute a number of distros optimized for different CPUs. Add in SIMD/SSE/Altivec, and now we're talking... I think we should combine these efforts together.
.hc
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
-
cgc＠humboldtblvd.com -
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
Mathieu Bouchard -
Thomas Grill