Good day, everyone. I hope someone can help to clarify some confusion
about FDIV function. We are using MEMSic for angle measurement.
Without going into details about memsic chip and fucntions, we are
required to compare some values obtained from memsic with the lookup
table that we have to created on the 68hc11 board. Here are my problems:
We are not allowed to use Floating Math package (the application that
we are developing is time sensitive), so we have to use what we have
just from 68hc11. Particularly, we need to divide 2 numbers obtained
from memsic. Provided that I will test and ensure that numerator <
denominator before I use FDIV. The description of FDIV tells that the
result will be a binary weighted function, i.e. if I get $FFFF it will
be equivalent to 0.99998. The question is : does 68hc11 keep track of
it somehow ?(i.e that the result is not actually 65K+ (largest number
that can be represented by 16 bits, but that it is a binary weighted
fraction).
I need to know this to create proper values in my look table (I will
be searching in lookup table based on the results of the FDIV).
I greatly appreciate any input, thoughts and ideas. Thank you.
Alex
Help with FDIV
Started by ●October 23, 2005
Reply by ●October 24, 20052005-10-24
Alex,
my reply is from (distant) memory only so please
make sure to verify it.
The FDIV is a very useful instruction.
Basically, it divides 32 bits by 16, the 32 bits
being the dividend shifted left 16 times. Obviously
the divisor must be > divisor so the result can
fit into 16 bits; I don't remember if the V bit
gets set by the HC11 (I would guess it does).
Having also the IDIV opcode, you can easily
calculate 16/16 bit division with a 32 bit
precise quotient (the point being after the
16-th bit); you do the IDIV, the result is
your quotients upper 16 bits, then you FDIV the
remainder and the result here are the lower
16 bits (i.e. the fraction).
Hope I remember this correctly.
To anyone on the list who have not heard from me
for quite some time - hi!
Since the HC11 shows remarkable resilience (if only
for teaching purposes, it seems very much alive),
I'll dig what used to be on my old www site and put
it on the new one within a month or two, if I hear
encouraging voices from this list in that respect.
Dimiter
------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------
--- sirius_advocate <aberezhnoy@aber...> wrote:
> Good day, everyone. I hope someone can help to
> clarify some confusion
> about FDIV function. We are using MEMSic for angle
> measurement.
> Without going into details about memsic chip and
> fucntions, we are
> required to compare some values obtained from memsic
> with the lookup
> table that we have to created on the 68hc11 board.
> Here are my problems:
>
> We are not allowed to use Floating Math package (the
> application that
> we are developing is time sensitive), so we have to
> use what we have
> just from 68hc11. Particularly, we need to divide 2
> numbers obtained
> from memsic. Provided that I will test and ensure
> that numerator <
> denominator before I use FDIV. The description of
> FDIV tells that the
> result will be a binary weighted function, i.e. if I
> get $FFFF it will
> be equivalent to 0.99998. The question is : does
> 68hc11 keep track of
> it somehow ?(i.e that the result is not actually
> 65K+ (largest number
> that can be represented by 16 bits, but that it is a
> binary weighted
> fraction).
>
> I need to know this to create proper values in my
> look table (I will
> be searching in lookup table based on the results of
> the FDIV). > I greatly appreciate any input, thoughts and ideas.
> Thank you. >
> Alex >
>
__________________________________
my reply is from (distant) memory only so please
make sure to verify it.
The FDIV is a very useful instruction.
Basically, it divides 32 bits by 16, the 32 bits
being the dividend shifted left 16 times. Obviously
the divisor must be > divisor so the result can
fit into 16 bits; I don't remember if the V bit
gets set by the HC11 (I would guess it does).
Having also the IDIV opcode, you can easily
calculate 16/16 bit division with a 32 bit
precise quotient (the point being after the
16-th bit); you do the IDIV, the result is
your quotients upper 16 bits, then you FDIV the
remainder and the result here are the lower
16 bits (i.e. the fraction).
Hope I remember this correctly.
To anyone on the list who have not heard from me
for quite some time - hi!
Since the HC11 shows remarkable resilience (if only
for teaching purposes, it seems very much alive),
I'll dig what used to be on my old www site and put
it on the new one within a month or two, if I hear
encouraging voices from this list in that respect.
Dimiter
------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------
--- sirius_advocate <aberezhnoy@aber...> wrote:
> Good day, everyone. I hope someone can help to
> clarify some confusion
> about FDIV function. We are using MEMSic for angle
> measurement.
> Without going into details about memsic chip and
> fucntions, we are
> required to compare some values obtained from memsic
> with the lookup
> table that we have to created on the 68hc11 board.
> Here are my problems:
>
> We are not allowed to use Floating Math package (the
> application that
> we are developing is time sensitive), so we have to
> use what we have
> just from 68hc11. Particularly, we need to divide 2
> numbers obtained
> from memsic. Provided that I will test and ensure
> that numerator <
> denominator before I use FDIV. The description of
> FDIV tells that the
> result will be a binary weighted function, i.e. if I
> get $FFFF it will
> be equivalent to 0.99998. The question is : does
> 68hc11 keep track of
> it somehow ?(i.e that the result is not actually
> 65K+ (largest number
> that can be represented by 16 bits, but that it is a
> binary weighted
> fraction).
>
> I need to know this to create proper values in my
> look table (I will
> be searching in lookup table based on the results of
> the FDIV). > I greatly appreciate any input, thoughts and ideas.
> Thank you. >
> Alex >
>
__________________________________
Reply by ●October 24, 20052005-10-24
sirius_advocate wrote:
> Good day, everyone. I hope someone can help to clarify some confusion
> about FDIV function. We are using MEMSic for angle measurement.
> Without going into details about memsic chip and fucntions, we are
> required to compare some values obtained from memsic with the lookup
> table that we have to created on the 68hc11 board. Here are my problems:
>
> We are not allowed to use Floating Math package (the application that
> we are developing is time sensitive), so we have to use what we have
> just from 68hc11. Particularly, we need to divide 2 numbers obtained
> from memsic. Provided that I will test and ensure that numerator <
> denominator before I use FDIV. The description of FDIV tells that the
> result will be a binary weighted function, i.e. if I get $FFFF it will
> be equivalent to 0.99998. The question is : does 68hc11 keep track of
> it somehow ?(i.e that the result is not actually 65K+ (largest number
> that can be represented by 16 bits, but that it is a binary weighted
> fraction).
Apparently, you don't actually know exactly what the instruction does.
These instructions (IDIV and FDIV) are one place where the usually
truly excellent documentation provided by Motorola falls down.
I investigated these instructions about two years ago when I did
a floating point package for the 6811.
The FDIV instruction computes (Numerator * 65536) / Denominator,
yielding a quotient and a remainder. Now, if Numerator < Denominator
then (mathematically) we have
(Numerator * 65536)/Denominator =
(Numerator/Denominator)*65536 < (1)*65536 = 65536.
So the quotient must fit. (The remainder, of course, is less
than the divisor.)
So there are two fixed point divides: One (IDIV) considers the radix
point to be to the right of the LSb of the numerator, and the other
(FDIV) considers the radix point to be to the left of the MSb of
the numerator. In this way, one can compute as many bits of the
quotient as desired, so long as the numerator is an integer
0 <= Numerator < 65536 and the divisor is an integer
0 < Divisor < 65536.
The way to do such a computation is to do an IDIV first, to
get any integer part of the quotient, and then get 16 bit
chunks of the fractional part by repeatedly using the remainder
(which is always guaranteed to be less than the divisor)
as the new numerator and using FDIV.
As a numeric example, suppose we want to compute 19/7. First,
we compute 19/7 using IDIV, and get a quotient of $0002 and a
remainder of $0005. Now we use FDIV to compute 5/7, and get
$B6DB as a quotient and $0003 as remainder. Then we use FDIV
to compute 3/7 and get $6DB6 as quotient and $0006 as remainder.
So 19/7 = $2.B6DB6DB6...
This can be continued as long as we wish, getting another
16 bits of the result for each FDIV.
The $B6D repeats forever, as it is not exactly representable
as a binary fraction, and we get a repeating "decimal".
Now, if you already know that the numerator is less than the
denominator, then you know the integral part is 0, and you
can skip the IDIV, saving 41 cycles.
Nicely, the remainder is in D, so all one has to do is reload
X. IOW, some code like this works...
...
tsy
ldd Num,y
ldx Den,y
idiv
stx Quo,y
ldx Den,y
fdiv
stx Quo+2,y
ldx Den
fdiv
stx Quo+4,y
...
> I need to know this to create proper values in my look table (I will
> be searching in lookup table based on the results of the FDIV). > I greatly appreciate any input, thoughts and ideas. Thank you.
Hope that helps.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
> Good day, everyone. I hope someone can help to clarify some confusion
> about FDIV function. We are using MEMSic for angle measurement.
> Without going into details about memsic chip and fucntions, we are
> required to compare some values obtained from memsic with the lookup
> table that we have to created on the 68hc11 board. Here are my problems:
>
> We are not allowed to use Floating Math package (the application that
> we are developing is time sensitive), so we have to use what we have
> just from 68hc11. Particularly, we need to divide 2 numbers obtained
> from memsic. Provided that I will test and ensure that numerator <
> denominator before I use FDIV. The description of FDIV tells that the
> result will be a binary weighted function, i.e. if I get $FFFF it will
> be equivalent to 0.99998. The question is : does 68hc11 keep track of
> it somehow ?(i.e that the result is not actually 65K+ (largest number
> that can be represented by 16 bits, but that it is a binary weighted
> fraction).
Apparently, you don't actually know exactly what the instruction does.
These instructions (IDIV and FDIV) are one place where the usually
truly excellent documentation provided by Motorola falls down.
I investigated these instructions about two years ago when I did
a floating point package for the 6811.
The FDIV instruction computes (Numerator * 65536) / Denominator,
yielding a quotient and a remainder. Now, if Numerator < Denominator
then (mathematically) we have
(Numerator * 65536)/Denominator =
(Numerator/Denominator)*65536 < (1)*65536 = 65536.
So the quotient must fit. (The remainder, of course, is less
than the divisor.)
So there are two fixed point divides: One (IDIV) considers the radix
point to be to the right of the LSb of the numerator, and the other
(FDIV) considers the radix point to be to the left of the MSb of
the numerator. In this way, one can compute as many bits of the
quotient as desired, so long as the numerator is an integer
0 <= Numerator < 65536 and the divisor is an integer
0 < Divisor < 65536.
The way to do such a computation is to do an IDIV first, to
get any integer part of the quotient, and then get 16 bit
chunks of the fractional part by repeatedly using the remainder
(which is always guaranteed to be less than the divisor)
as the new numerator and using FDIV.
As a numeric example, suppose we want to compute 19/7. First,
we compute 19/7 using IDIV, and get a quotient of $0002 and a
remainder of $0005. Now we use FDIV to compute 5/7, and get
$B6DB as a quotient and $0003 as remainder. Then we use FDIV
to compute 3/7 and get $6DB6 as quotient and $0006 as remainder.
So 19/7 = $2.B6DB6DB6...
This can be continued as long as we wish, getting another
16 bits of the result for each FDIV.
The $B6D repeats forever, as it is not exactly representable
as a binary fraction, and we get a repeating "decimal".
Now, if you already know that the numerator is less than the
denominator, then you know the integral part is 0, and you
can skip the IDIV, saving 41 cycles.
Nicely, the remainder is in D, so all one has to do is reload
X. IOW, some code like this works...
...
tsy
ldd Num,y
ldx Den,y
idiv
stx Quo,y
ldx Den,y
fdiv
stx Quo+2,y
ldx Den
fdiv
stx Quo+4,y
...
> I need to know this to create proper values in my look table (I will
> be searching in lookup table based on the results of the FDIV). > I greatly appreciate any input, thoughts and ideas. Thank you.
Hope that helps.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Reply by ●October 24, 20052005-10-24
Nicely explained Mike, thanks.
Mike McCarty <Mike.McCarty@Mike...> wrote:
sirius_advocate wrote:
> Good day, everyone. I hope someone can help to clarify some confusion
...
---------------------------------
Yahoo! FareChase - Search multiple travel sites in one click.
sirius_advocate wrote:
> Good day, everyone. I hope someone can help to clarify some confusion
...
---------------------------------
Yahoo! FareChase - Search multiple travel sites in one click.
Reply by ●October 24, 20052005-10-24
Scott Grodevant wrote:
> Nicely explained Mike, thanks.
Well, thanks for the kudos. I see that you are not
the OP. Well, as I thought, there are a lot of people
out there who don't know exactly what FDIV and IDIV
do, and why. I know I didn't when I first started
on the floating point package.
I did make one little mistake, where I left off a ",y"
on "ldx Den,y". I hope that didn't cause any confusion.
Of course, one should never write uncommented code
like that. It was intended to be an example in the context
of the surrounding commentary.
Have a nice day doing divides!
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
> Nicely explained Mike, thanks.
Well, thanks for the kudos. I see that you are not
the OP. Well, as I thought, there are a lot of people
out there who don't know exactly what FDIV and IDIV
do, and why. I know I didn't when I first started
on the floating point package.
I did make one little mistake, where I left off a ",y"
on "ldx Den,y". I hope that didn't cause any confusion.
Of course, one should never write uncommented code
like that. It was intended to be an example in the context
of the surrounding commentary.
Have a nice day doing divides!
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Reply by ●October 25, 20052005-10-25
Dimiter Popoff wrote:
[good stuff about FDIV]
> To anyone on the list who have not heard from me
> for quite some time - hi!
> Since the HC11 shows remarkable resilience (if only
> for teaching purposes, it seems very much alive),
> I'll dig what used to be on my old www site and put
> it on the new one within a month or two, if I hear
> encouraging voices from this list in that respect.
>
> Dimiter
Hi Dimiter. Not sure whether you remember me, but I was
around when this was run by Motorola about 4 years ago
or so.
I'd be interested.
BTW, would you be interested in collaborating on a port
of LCC or similar to the '11 and '12?
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
[good stuff about FDIV]
> To anyone on the list who have not heard from me
> for quite some time - hi!
> Since the HC11 shows remarkable resilience (if only
> for teaching purposes, it seems very much alive),
> I'll dig what used to be on my old www site and put
> it on the new one within a month or two, if I hear
> encouraging voices from this list in that respect.
>
> Dimiter
Hi Dimiter. Not sure whether you remember me, but I was
around when this was run by Motorola about 4 years ago
or so.
I'd be interested.
BTW, would you be interested in collaborating on a port
of LCC or similar to the '11 and '12?
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
