Re: 128 by 64 unsigned division

In article <37893520203559@xxxxxxxxxxxxxx>, Marcel Hendrix <mhx@xxxxxx> wrote:
Albert van der Horst <albert@xxxxxxxxxxxxxxxxxx> Re: 128 by 64 unsigned division
[..]
There is only one way to go, IMHO. These kind of elementary
operations are to be written in assembler.

Thank you. How do I write this one (unsigned 128 by 64 division)
in 32bit assembler, and why can't I do it in 32bit Forth?

An 8 bit processor would be reasonable as a starting point as the
registers are short by a factor 4, like you have.
I have a pretty implementation in 6809 ciforth, shaving some cycles
even from the Camelforth version. It exhibits the same
register shortage you might have in your case.
A shift algorithm for 64 bits starts out by lasting 4 times
as long as for 8 bits, though.


I'm pretty convinced of the correctness of my 128 by 64 divide
on the DEC alpha, because it was a straightforward adaption of
chain division, such as can be ported from e.g. on Z80 figForth.

I think I understand what you mean. In this case speed is no
problem, so I may try to dig out the algorithm somewhere and
try to write in high-level Forth.

See above.


Why anybody would even consider an alternative to the DIV instruction,
for 64 bit architectures that provide is, is beyond me.

For 32 bit architectures that don't provide it, obviously.
And fdiv on a 32bit Pentium is the same as idiv, if you
really didn't know that already :-)

Okay, I didn't realize this was 32 bit.


[..]
I would consider replacing F>D 2DUP D>F by F>S DUP S>F.
If it still works the algorithm is independant of the quality
of the floating point implementation.

It quite obviously can not and will not, and if it did, I don't
see what the quality of the FP implementation would prove.

You should express your concern more directly.

The above proves that the quality of the implementation of
F>D is crucial, but that was already apparent to you.
So one gets nowhere without very precisely
analysing whatever the f.p. implementation provides here.
f.p. means inaccuracy.
That is what I meant.

<SNIP>


-marcel


Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

.

Relevant Pages

  • Re: 128 by 64 unsigned division
    ... Albert van der Horst Re: 128 by 64 unsigned division ... in 32bit assembler, and why can't I do it in 32bit Forth? ... For 32 bit architectures that don't provide it, ... If it still works the algorithm is independant of the quality ...
    (comp.lang.forth)
  • Re: Optimization help please
    ... few people that can improve such a routine using assembly. ... Have the compiler output assembler code for that routine and see if any ... be read then the CRC can be computed on each 'block' and the algorithm could ... > checksum is cpu and disk intensive, ...
    (comp.lang.asm.x86)
  • Re: Population count in SSE2, again
    ... This is a crude version of the well-known code in AMD's optimization ... and is not as fast as the AMD code. ... oneself that the algorithm is mathematically sound. ... Yes I'm sure you are right, but a typo in assembler is easily made. ...
    (comp.lang.asm.x86)
  • Re: Thinking assembly?
    ... This is one part of thinking in assembler to me. ... > algorithm and implement it in the higher-level language. ... you can't merely go back the HLL code to obtain ...
    (alt.lang.asm)
  • About Quality (minini-essay) [BTPC Extension - PyramidWorkshop]
    ... Or you use a computer generated algorithm that is hopefully ... somewhat near what a human would describe as quality and use this one. ... most sure have changed (more saturated pictures look better, ... subjectivity, or leads to changes in it. ...
    (comp.compression)