Req: 64bit real-time DSP for Assembly primitive

[infuzion]

I've requested this for 7 years now on the SM forum, & since they are re-merging the 2 products I'll have to repost here. I'll have to edit later for SSE4+; I'm open to suggestions.

I'm requesting simply that new ASM opcodes & connectors would be added to the Assembly primitive so those of us that need higher quality real-time DSP can stick with FS, & don't have to rely on questionable Ruby or outside methods. The community can create modules for higher-level 64bit DSP as needed, so I am really only asking 1 day or less of work from 1 programmer. I've spent more time requesting this than the time needed to add it!

Old message follows; let me know if I need to add more opcodes, but please do your homework & prove why!
==
Why are more SSE opcodes are needed?
64bit audio signal path is expected by some for mastering.
64bit audio is needed for some filters to be stable by reducing rounding errors (RBJ, scilab's s-z transform).
Better optimizations (SSE3 allows faster FFT, packed int for fast Sine).

What is needed to do this?
SM2.0 has connectors for double-float (Stream, Poly, & Mono, but not Dual-Packed Mono AFAIK) and Stream 2 Double & Double 2 Stream primitives now already. Here is a priority list for adding more SSE support to SM:

1. SSE2 & SSE3 instructions opened for the ASM primitive (see below)
2. + 64bit/Double-Stream connectors for Assembly primitive.
3. + Double-Stream Mono VST in/out
4. + converters to & from Poly/Pack4, Mono, & Double-Stream Pack2 (64bit stereo)
5. + Double-Stream input to primitives (starting with Code, Wave Reader, Wave Table Read)
6. allow Float Array handle Double-Stream floats, including Preset Parameter Array

addpd //Packed Double-FP Add
andnpd //Bit-Wise Logical And Not (for Double-FP)
andpd //Bit-Wise Logical And (for Double-FP)
cmppd //Packed Double-FP Compare compare
cvtdq2pd //Packed Signed INT32 to Packed Double-FP Conversion
cvtpd2pi //Packed Double-FP to Packed INT32 Conversion
cvtpd2ps //Packed Double-FP to Packed Single-FP Conversion
cvtpi2pd //Packed Signed INT32 to Packed Double-FP Conversion
cvtps2pd //Packed Single-FP to Packed Double-FP Conversion
divpd //Packed Double-FP Divide
maxpd //Packed Double-FP Maximum
minpd //Packed Double-FP Minimum
movapd //Move Aligned Packed Double-FP
mulpd //Packed Double-FP Multiply
orpd //Bit-Wise Logical OR for Double-FP Data
shufpd //Shuffle Double-FP
sqrtpd //Packed Double-FP Square Root
subpd //Packed Double-FP Substract
xorpd //Bit-wise Logical XOR for Double-FP Data
I/O:
s64in/out, s64intin/out, s64boolin/out,

movhpd //Move High Packed Double-FP movement
movhlps //Move High Single-FP to Low {faster AMD vs Intel}
movhps //Move High Packed Single-FP
movlpd //Move Low Packed Double-FP movement
movlps //Move Low Packed Single-FP
rsqrtps
unpckhpd //Unpack High Packed Double-FP Data shuffle
unpcklpd //Unpack Low Packed Double-FP Data shuffle
unpcklps //useful for merging 2 mono streams into 1
xorps
SSE3:
addsubpd - Adds the top two doubles and subtracts the bottom two, useful for stereo balance
addsubps - Adds top singles and subtracts bottom singles, useful for stereo balance
haddpd - Top double is sum of top and bottom, bottom double is sum of second operand's top and bottom.
haddps - Horizontal addition of single-precision values.
hsubpd - Horizontal subtraction of double-precision values.
hsubps - Horizontal subtraction of single-precision values.
movshdup - Duplicates the high singles into high and low singles.
movsldup - Duplicates the low singles into high and low singles.

* rounding controlled by MXCSR register (bits 13 and 14)
ldmxcsr //Load MXCSR register
stmxcsr //Save MXCSR register state
(SM default of rounded off?)

I'd prefer to have replies to this post be focused on what opcodes are needed & other 64bit DSP/audio improvements are needed.
No whining!

[DSP]

I was under the impression that if you go 64bit the inline assembler code was not allowed anymore?

[infuzion]

I was under the impression that if you go 64bit the inline assembler code was not allowed anymore?

Do you mean if they have 64bit OS VST exports then the ASM primitive will never work? I thought I read that also, but that sounds to be more like a programmer who does not know programming well enough. I do not see how the 2 are related. If they expect to have us rely on Ruby for all audio code, then I think they are mistaken.

I could be proven wrong...

[tor]

Another possibly good reason to have 64bit or even higher for the robotic/automation/research/scientific people is that one can actually never get enough precision in the discrete domain. This is very important for audio DSP as Infusion mention. But I also guess when scientific students, established scientists or matematicians that discover the power of FlowStone and graphical programming they will require that extra precision aswell for realtime experiments and measuring.

If FlowStone shall become a industry standard

I think they will have to implement this or reevaluate their price policy. As every one else DSProbotics will have to work hard and invest long hours to meet the future and present needs and not atleast to keep their cusomers from SynthMaker.

Take a look at Cockos Reaper one price/license for personal non commercial and educational use and one professional. This is a policy based on trust. Trust that in the end will benefit the company with a much larger userbase and growth. Heck, there could be three licenses for the SAME product and features. Personal, Commersial and large Enterprice.

Sorry to bring in the price policy but it was meant to be a incentive for DSProbotict to take theese matters seriously. Higher precision IS important

[infuzion]

Another possibly good reason to have 64bit or even higher for the robotic/automation/research/scientific people is that one can actually never get enough precision in the discrete domain.

Ah good points!
Would 80bit single-channel precision channel be useful? (x86)

Take a look at Cockos Reaper one price/license for personal non commercial and educational use and one professional...Sorry to bring in the price policy

You can bring it up, but perhaps in a new thread?!?

I wonder if I should ask for AVX also... 4 channel double float, or 8 channel single anyone?
http://en.wikipedia.org/wiki/Advanced_Vector_Extensions
http://software.intel.com/en-us/article ... xtensions/

[CoreStylerz]

The fact of x64 OS does not even matter.
Im in italy and there's no way to purchase a x86 machine, even notebooks (maybe netbooks) since they are out of the maket for the SysWow64 that in any case support the x86 based software.

Should be possible for DSP robotics to complie 2 executables of FlowStone, one running x86 (with asm instruction for x86 only) and the x64 software that use 64 bit instructions and obiviuosly x64 native plugins export!.

This makes sense.

And synthmaker users need to trusth DSP robotics, and this can be possible only integrating the features that we are asking for years.

[infuzion]

Should be possible for DSP robotics to complie 2 executables of FlowStone, one running x86 (with asm instruction for x86 only) and the x64 software that use 64 bit instructions and obiviuosly x64 native plugins export!.

Would be a good idea, if FS2 & SM2 did not already have double-floats built in. Look inside Wave Player/Counter/PreciseCounter & see the Double Stream primitives yourself. Perhaps they use x86 inside those, but I doubt it. IMHO they are likely the very same commands I want to see opened up in the ASM.

[tor]

One can always ask and hope for more

AVX is tha sexy future of DSP

[tor]

Would be a good idea, if FS2 & SM2 did not already have double-floats built in. Look inside Wave Player/Counter/PreciseCounter & see the Double Stream primitives yourself. Perhaps they use x86 inside those, but I doubt it. IMHO they are likely the very same commands I want to see opened up in the ASM.

mhmmmm
+1

[trogluddite]

Not an opcode, but something that seems fitting here in terms of code optimisation and opening new possibilities...

Can we please have a way to access the "mem" data type directly from within code/assembly blocks.
Why?
There have been quite a few stock modules etc., such as delays, that have been re-coded successfully to have far lower CPU requirements through optimisation of the data structures and read/write code for accessing arrays. But this is not possible at the moment for e.g. loaded wave data, one has to resort to multiple code blocks and external wave reader/writer modules, which are always fixed to use all four SSE channels - thus very inefficient when all four channels are not required. It also means that data collected into a code/assembly array cannot be made "visible" outside of the code block, again restricting the possibility for sharing/storing such data.
This would also open up opportunities for creating completely new types of module which are presently very difficult to implement - for example FIR filters and convolution reverbs, where currently the impulse response would have to be hard-coded, or use impractical numbers of discrete inputs/outputs.
As stated by infuzion previously, I do not think that any of the featires requested in this thread are "specialised" features only of use to former SM users - they wpuld surely be useful for users wishing to "number crunch" any kind of real time data using FFT techniques etc. Nor are they purely "power user" features, as even users with no code/assembly knowledge are able to make use of modules generously shared by the code "gurus".
Such code/assembly modules are the nearest thing that we have to an SDK with which users can create a library of modules that push FS beyond the boundaries of the bundled primitives - thus helping the user base to increase the value of the software without requiring a large drain on the development team's resources.