Re: bsr-algorithm?

spamtrap wrote:
So what you're really trying to do is to write a custom int->fp
conversion algorithm, instead of using one of the formats that the hw
supports directly, and which will be orders of magnitude faster?

Yes. But fp->int anf fp->fp transcoding too. And actually I have

OK, the fp inputs haven't been mentioned before this.

working and correct code since a year. I just want a MMX-variation of
bsr.

[... the description of the fp->fp trancoder ...]

You forgot subnormal numbers, and nan-conversion.

See above, both sub-norm and NaN are impossible for integer inputs.

As usual, when you explain the real problem, the fast solution is
totally different from what you initially expected.

Yes, it is unexpected. The importf()-codepath indeed is fbpos-free. I
did'n think of importf((float)short). The problem is that importf()
[the algorithm you described above] is about twice as complicated as
importl() [both include sub/nan/inf handling].

Again, see above: sub/nan are impossible and so are inf for integer inputs, as long as you have at least 5-7 exponent bits.

I doubt [importf] it is actually faster [than importl] on GPRs with
bsr.

Depends on the output format: If it is equal to float or double, or very similar to one of them, then it is indeed faster.


I can't make a MMX-version of it without bsr anyway. You gave me the
correct advice to (mis)use the floating-point conversion function for
bsr-emulation, which is crazy, but it works.

:-)

BTW, I'm disregarding MMX since there's no fp support without SSE anyway.

Terje

--
- <Terje.Mathisen@xxxxxxxxxxxxx>
"almost all programming can be viewed as an exercise in caching"

.