The sse registers are never really 'empty', they just have unknown contents. My comment at the beginning of SquaredDistanceEstimate means that before you call it, you should put the arguments x and y in xmm0 and xmm1, as I did in the second block where I do call it.

Ah that did clear that up for me, Going to pick at it some more in a bit. thanks!

@ Edfed: http://www.schlukhash.nl/index.php/thesis-vst
Been tweaking this for the last year.
Think it would be nice to have al the functional parts as classes. Or better yet an open assembly based sdk. Seeing skins are actually a more creative and intuitive thing. And dsp is fine in assembly.

To be more specific, the granular engine, lfo and functional parts I have in my portfolio as assembly macros, and i have prodominantly synthesis routines in my files. The skin is something I can design and human engineer, but have zero skills implementing in any sdk. So its a bit too focused on writing synthesis routines

Actually a good open asm dll in dll sdk is what im dreaming of, (all black for a change) .

coollllll! now i know i can test vst, then, i can code vst too.

if you want i can join you in the vst development, in asm and maybe in c++ too (but i prefer in asm).

your thesis vst is a good start i think if we want it in asm, we first should extract the functionning diagram, and then traduce it in asm.

i don't have a lot of time for this, but i will really enjoy to code vst.
we can discuss about it later if you want.

Glad you like it I was pondering to make it free one of these days.
The release version is way more versatile, and optimised Not that it really matters tho.

Was actually thinking about a compiler, will up some sketches probbably tuesday when the rest is layed out, maybe if theres interest i can start an opensource project/forum. But it all depends offcourse.

I am confident that my logic and syntax is (or are) correct, but I don't seem to be able to get a usable file. Yes I've looked at the documentation and all the examples in both fasm-for-dos and for windows. it is the instructions to fasm itself that I can't get right.
All I am trying to do is write programs that will solve Project Euler problems, ie, simple (!) add, subtract etc. not fancy display. I wrote a solution for PE#5. If I put it within the USEDPMI example, it compiles, runs and gives the correct answer, but if I try to get it as a stand-alone program, I get a message from "16-bit MS-DOS subsystem". Well of course, a 32-bit program won't go. So, my directives to FASM must be wrong.
How should I FORMAT etc?
2. Which FASM should I be using, for DOS? or Windows?
The windows examples look so complicated when all I am doing is calculating and display the answer?
3. I tried to write a 64-bit program. It compiles OK, but when I look at the machine code, I see that
mov rax,1000000000 compiles correctly to the correct hex values, but
mov rax,1000000000000000 doesn't? 8 bytes are allocated, including two zeros, but they are not the correct hex values? 64-bits should cope with a much bigger number?
4. The USEDPMI solution for PE#5 which runs OK from both the C: promplt and from the windows file on my 32-bit PC. But trying the run the same program on a 64-bit PC gets a message.... "contact your software people and get a proper 32 or 64-bit program. so... what directives should I try to get FASM to compile a 64-bit program?

whakamaru - Greetings and welcome, fellow kiwi!

I haven't dabbled with 64-bit stuff for quite a while so hopefully somebody else will help you, but iirc x86-64 CPU's don't generally support 64-bit immediate operands. Yes, I know, you would expect any self-respecting CPU that claims to be 64-bit to natively support an instruction to load a 64-bit immediate value into a 64-bit register. But apparently not...

[ Post removed by author. ]

MOV is one of the few instructions that supports imm64 operands,I had the same problem trying to multiplicate by big immediates and I had to MOVe them somewhere before the multiplication, so your code should be fine

neville: ARM and MIPS have fixed-width instructions - for the best optimizations: table[i] - and they are meant for pure register usage (see Magic-ARM compiler). 32/64/128BIT immediates can be loaded from IP relative literal tables in 1 instruction. X86 may be easier and more convenient for the programmer, but ARM has the greatest performance. No CPU design is perfect, though.

The problem is encoding space.

How would one encode this?: There has to be a limit somewhere else you get ridiculously long instruction encodings making the whole CPU decoder take a disproportionately large silicon area and costing a disproportionately large amount of performance issues.