How do you come to the conclusion that all the inputs are integer?

Also, if, as you state, all inputs are actually integer and the only operations are add, sub and mul then why do you suddenly need float for mu?

u code is also much slower by using the FPU, remember the OP wanted to optimise it, not slow it down. You code has many bugs and won't give you the correct answer, try it if you don't believe me.

Your code will produce incorrect results.

First of all - we're not living DOS-times anymore - all videocard shaders are written in float only. That's for the sake of ease and YES you CAN write to an address of 1.5 in any modern videocard because its rounded off by the driver. The names are ATI xxxx (any), nVidia xxxx (any).

A Little about SSE - Intel CPUs have it from Pentium III and AMD CPUs have it from Athlon XP, which were both introduced around 1999. There's no need to worry about someone having it. Older than that won't run newer operating systems anyway - neither run graphics normally

1) Why would anyone want to convert to integer when int<->float conversion costs so much and most graphical routines (D3D, OGL) are using floats?

2) Where did you find the integral routine?

3) What if the points you give to the algorithm aren't real screen co-ordinates (like 100 and 314), but imaginary co-ordinates (as is the case with y0 and y3, which they just might be), which don't have to be integers at all? You will have major rounding errors.

4) And why do you expect it to give back integer results? You won't leave any room for example anti-aliasing if you wanna do that later.

5) The same question revolution already asked - why did you put an example of 5 times slower code than the original here? FILDs / FISTPs have 6 clock latency while SSE instructions with xmm,m128 have no latency at all.

6) What do you mean with THAT sentence: "I told you that the compilers are better than the average assembly programmer" ???

What proves that? Which measurement? There have been no comparisons? How can you assume that?

14 cycle instead of 20 for me is just a mental masturbation for assembly programmers

3) What if the points you give to the algorithm aren't real screen co-ordinates (like 100 and 314), but imaginary co-ordinates (as is the case with y0 and y3, which they just might be), which don't have to be integers at all? You will have major rounding errors.
4) And why do you expect it to give back integer results? You won't leave any room for example anti-aliasing if you wanna do that later.

a*t^3 + b*t^2 + c*t + d    

t*(t*(t*a+b)+c)+d    

(t-r1)*(t-r2)*(t-r3)*a    

5) The same question revolution already asked - why did you put an example of 5 times slower code than the original here? FILDs / FISTPs have 6 clock latency while SSE instructions with xmm,m128 have no latency at all.

Madis731: You and me also, I spend all day wondering how to save one clock cycle in my GUI code so that when the user clicks it can respond 0.3ns faster. Forget about the fact that it is only clicked once per day, that is not important.

it's not only '0.3ns', but think of it like this: if you didn't do it, no one would've (at least if they used the same mentality as M$), and then the code wouldn't improve in this aspect -- so it was a GOOD thing, nonetheless, getting closer to the limit (when n->infinity) to perfection.. albeit we're not at n=infinity yet

Even Igor seems to have lessened his hero worship of Intel's compiler technology and taken to bitching on the Intel forum about how crappy their compiler is.

Actually we did this t*(t*(t*a+b)+c)+d manually and also Intel's compiler figured it out so I don't understand where are you getting at!? Look at a few posts back, both C and ASM are given.

Memory moves (especially aligned ones) have little to none latency compared to reg,reg moves because of architectural design (ARM has high latency when doing memory operations). For example movaps xmm0,[esp] doesn't need register rename after a 'suspicious' operation on an xmm0, whereas movaps xmm0,xmm1 does.
And by latency I mean "additional latency" - not the actual micro-ops taken. They still do take time if that's what you're surprised at.

The speed of different ALU units are again architecture specific and they are related in this way: SSE_INT >= SSE_FLOAT >= INT > FLOAT, the '>' sign meaning left is faster than right. And IIRC Intel's FPUs are known to be slower than i.e. AMDs.

The thing is, I'm also using this to draw curved lines (instead of bezier splines, which I found too complicated for my needs) So the usage of this routine goes up by quite a lot, imagine... I'm calling this from a 0.0 to 1.0 on X stepping per data set.

data = Compute cubic (normal way) at 0.0
d1 = Compute 1st derivative
d2 = Compute 2nd derivative
d3 = Compute 3rd derivative

; multiply derivatives by step size
d1 *= step
d2 *= step
d3 *= step

loop from 0.0 to 1.0
  data += d1
  d1 += d2
  d2 += d3

  ; do something with 'data'
end loop