From the original SynthMaker forum (2004–2014), with its members’ names and dates.
MegaHurtz ·
Since this is partially a bug ill post it here.
I want to use andnps and it works but since the syntax colouring is off, want to save myself the hassle of debugging uncoloured code. So next to this being a PITA, is there another cheap fix I can use?
Oh.. and rcpps does`nt live up to the task also 😕
trogluddite ·
I always edit my assembly in Notepad++ these days - it's a free download from Source Forge. If you search for 'Notepad++', I posted up a custom syntax file for it... [old link] Sounds awkward cutting and pasting between two different app's, but actually Notepad++ is a really nice editing environment, and is much more responsive than SM if you need more than a few dozen lines of code. The customisable syntax means you can colour things any way you like, and add the missing opcodes that SM's syntax checker doesn't recognise.
trogluddite ·
MegaHurtz wrote: Oh.. and rcpps does`nt live up to the task also
Yeah, I followed the tip on the Wiki too - thinking is was some kind of whizzo programming trick - seems worse than divps, and it's less accurate!
MegaHurtz ·
it differs from the reciprocal in synthmaker code?
MegaHurtz ·
Ill try it 😉 The thing is im kind of annoyed by the way this works. To yump ahead to another topic, JZ is only one chanel so if I want it to work allaround synthmaker I have to write everything in the single registers.. And it wouldnt be more efficient. So JZ is pretty useless I guess. And it`s probbably days before I figure out if it`s possible to call a subroutine.
trogluddite ·
MegaHurtz wrote: it differs from the reciprocal in synthmaker code?
Well, I was led to believe that... rcpps xmm0,xmm0; mulps xmm1,xmm0; ...would be more efficient than... divps xmm1,xmm0; ...but on my Quad Core, the omly difference seems to be that rcpps is only 12bits accurate! Dunno, maybe it makes a big CPU saving on old P4s or something.
MegaHurtz wrote: JZ is only one chanel
If you're using mostly sse instructions, then JZ always jumps over all 4 channels together (have a look at code with hops in) - so you could bypass a whole chumk of code for all four channels, but not just selectively for one or two channels. You can sort of get around this with the shufps opcode - using it to store the input values, and then selectively putting them back at the end - but, be warned, it's one of the mind bending-est opcodes to use.
Subroutines don't really work any good - they'd always all have to be within the same code block anyway. If you have code you need to re-use a lot, the easiest way is with Cut and Paste within Notepad++ (you can have many windows open at once). I save a lot of useful little chunks of code to disk for using later - just begin the code with a little comment line that says something like 'xmm0 is input, xmm2 is output, xmm3-8 not used' so you don't lose track of registers when you paste it in.
Guess I'm lucky - I never knew any x86 assembly before SM - it must seem a bit limiting to people who are used to x86 or C++.
MegaHurtz ·
The problem is if you use, shufps xmm1,xmm1,0; The option for poly, and X4 are lost. So thats no option 🙁 Im very fond of having it in one code, for a theres no loss of sync 😀 and it save a bunch of ASM shells. Wich notably save cpu. So I am "reluctantly" going for the selectors.. Only this will not be sample accurate. I think it`s a musthave feat for a programming language to start and end loops at will. But with a fixed samplerate 😕 I do see some trouble ahead.
trogluddite ·
MegaHurtz wrote: I think it`s a musthave feat for a programming language to start and end loops at will
The trouble is in the processor rather than the language. For SSE to be so efficient, all 4 channels must use the same opcodes in precisely the same order - so selective loop lengths per channel will never work in SSE no matter what language you use - the CPU architecture is the limiting factor here. SSE was included by Intel to make pure 'number crunching' faster - it was never intended to be used for programming decision making structures. The only workaround in code that I can think of is to make all four channels loop for as many times as the longest loop you need (after calculating which is the longest loop) - and then use a comparison to lock the value for any other channel which has already completed enough iterations. Whether this is efficient or not depends on how often you'd need the maximum loop length of course - unfolding the loops into regular x86 code could still end up being more effiicient. I think the designers of SM made a decision to make SM easy to use, instead of super flexible, so the assembly and code here will never have the possibilities of C++ or a proper compiler - but doing it that way, you'd lose all the nice green and GUI things that makes SM so nice to use.
MegaHurtz ·
ASM is bigger than what we are getting.. It`s a full blown language, yust on a very low level. It`s the continuous loose ends that starting to get to me.
trogluddite ·
I think maybe we just get the bits that are used in the stock primitives. Don't think the code and assembler have had an update for a very long time. I would love to have proper breakpoints and 'step one instruction' for the assembler, like in a full compiler. Debugging is so hard sometimes without tools like that. Like I say, SM is designed to make development easy and painless. We have to think of code and assembly as being nice add ons to SMs core functions - the number of users pushing at the limits of the software by doing hardcore coding will be very small - and Outsim is very small, so they have to fix the things that will be used by the most people.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker