Bank-to-Turn <Bank-to-Turn@mchsi.com> wrote in message news:<f44fo0p77uoc0l3qimlgo7t0djlorseves@4ax.com>...
> On 2 Nov 2004 00:21:54 -0800, argon_gold@hotmail.com wrote:
> 
> >>I've tried the above method in GUI56600 (Motorola's simulator) by
> >>using the following values:
> >>Fractional Value = 0.10  = 0x0CCD (Q1.15 format or Q.15 format)
> >>Scale Factor = 6.3121    
> >>Expected result = 0.63121000000000 (in Q1.15 format)
> >>
> >>EXPRIMENT:
> >>Multiplication with Integer Part
> >>a. left shift (0x0CCD) three times for interger part 6.
> 
> If you left shift three times, you multiply by 8, not 6.
> 
> >>b. add 0.3121 (0x27F3) the fractional part
> 
> Let me make certain that I understand what you did ...
> 
> You multiplied 0.1 by 8, then added 0.3121?  How is that in any
> way like multiplying 0.1 by 6.3121?
> 
> >>Result = 0x8E5B  (in hex) = 36443 (in decimal) = 36443/(2^15) =
> >>0.55607604980469 (in fractional form Q1.15 format)
> >>
> >>why the result is not exactly the same as expected? 
> >>What goes wrong? Any comments?
> 
> I assume that you are trying to implement the second method that I
> suggested ("Multiply by 0.7890125, then left-shift three times"):
> 
> The number "0.7890125" is equal to 6.3121/8.  So what you need to
> do is FIRST multiply 0x0CCD (0.10 decimal) by 0x64FE (0.7890125
> decimal), yielding 0x050CC766 (0.078904962 decimal), THEN left
> shift three times to get 0x28663B30 (0.631239697 decimal).  This
> is equivalent to FIRST multiplying by (6.3121/8), and THEN
> multiplying by 8.  Maintain as many bits in the accumulator as
> possible, else you'll lose precision in the left shift.
> 
> Greg Berchin

Thanks for a clear explanation.....
This time it works...

Argon

On 2 Nov 2004 00:21:54 -0800, argon_gold@hotmail.com wrote:

>>I've tried the above method in GUI56600 (Motorola's simulator) by
>>using the following values:
>>Fractional Value = 0.10  = 0x0CCD (Q1.15 format or Q.15 format)
>>Scale Factor = 6.3121    
>>Expected result = 0.63121000000000 (in Q1.15 format)
>>
>>EXPRIMENT:
>>Multiplication with Integer Part
>>a. left shift (0x0CCD) three times for interger part 6.

If you left shift three times, you multiply by 8, not 6.

>>b. add 0.3121 (0x27F3) the fractional part

Let me make certain that I understand what you did ...

You multiplied 0.1 by 8, then added 0.3121?  How is that in any
way like multiplying 0.1 by 6.3121?

>>Result = 0x8E5B  (in hex) = 36443 (in decimal) = 36443/(2^15) =
>>0.55607604980469 (in fractional form Q1.15 format)
>>
>>why the result is not exactly the same as expected? 
>>What goes wrong? Any comments?

I assume that you are trying to implement the second method that I
suggested ("Multiply by 0.7890125, then left-shift three times"):

The number "0.7890125" is equal to 6.3121/8.  So what you need to
do is FIRST multiply 0x0CCD (0.10 decimal) by 0x64FE (0.7890125
decimal), yielding 0x050CC766 (0.078904962 decimal), THEN left
shift three times to get 0x28663B30 (0.631239697 decimal).  This
is equivalent to FIRST multiplying by (6.3121/8), and THEN
multiplying by 8.  Maintain as many bits in the accumulator as
possible, else you'll lose precision in the left shift.

Greg Berchin

Bank-to-Turn <Bank-to-Turn@mchsi.com> wrote in message news:<at45o0ptg7292r65o4tlk09fotlu9ei5ks@4ax.com>...
> On 29 Oct 2004 07:47:13 -0700, wavebox@wavebox.com.br (Luis
> Fernando) wrote:
> 
> >>i'm working with a motorola that can represent 1.15 fixed-point numbers
> >>
> >>any ideas on how can I multiply a number by 6.3121?
> 
> 6.3121 = 4 + 2 + 0.3121
> 
> 	Multiply by 4 = left shift twice
> 
> 	Multiply by 2 = left shift once
> 
> 	0.3121 = 0x4FE6 in 1.15 fixed
> 
> or
> 
> 	Multiply by 0.7890125, then left-shift three times

GREETINGS,
I've tried the above method in GUI56600 (Motorola's simulator) by
using the following values:
Fractional Value = 0.10  = 0x0CCD (Q1.15 format or Q.15 format)
Scale Factor = 6.3121    
Expected result = 0.63121000000000 (in Q1.15 format)

EXPRIMENT:
Multiplication with Integer Part
a. left shift (0x0CCD) three times for interger part 6.
b. add 0.3121 (0x27F3) the fractional part

Result = 0x8E5B  (in hex) = 36443 (in decimal) = 36443/(2^15) =
0.55607604980469 (in fractional form Q1.15 format)

why the result is not exactly the same as expected? 
What goes wrong? Any comments?

Thanks
Argon

Randy Yates wrote:

(snip)

> We've gone over this here a few dozen times in past years, but for the
> OP's sake, here's a quick explanation. Let's generalize the binary
> point location and say that we have two operands in x.y format. When
> we multiply them, the result is in 2x.2y format. In order to
> "left-justify" the binary point so that the result is x.(2y + x)
> (i.e., to match the input binary point), we shift left by x bits. If
> the inputs are considered fractional numbers (-1 <= N < +1), then x =
> 1 and the amount of left shift required is 1.

To generalize a little more, if you multiply v.w by x.y the product
has the form v+x.w+y.  You then need to shift to get the appropriate
bits of the product, which could have p.q format, into the appropriate
register bits.

> FYI, I do not like using this notation. An "x.y" number implies you
> have x bits for the integer portion of the number, and you do not (you
> have x-1 bits).

Well, I would say that you should subtract 1 for signed numbers before
writing them that way.   Note that PL/I, one of the few languages that
support such operations, expresses it as the number of value bits, not
including the sign bit, comma, the number after the radix point.

That is, FIXED BINARY(15,15) for 15 bits, not counting sign, and 15 
after the binary point.   PL/I will also do FIXED DECIMAL with the
decimal point in various places.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Randy Yates wrote:
>
> (snip)
>
>> The OP should note that whether the number is 1.15, 16.0, or whatever,
>> the difference is chiefly in your viewpoint. What Motorola hardware
>> does is left shift by one after a multiply, which allows two numbers that
>> were originally in fractional format (1.15) to remain in fractional
>> format. However, those numbers don't HAVE to be considered
>> fractional.
>
> Many (non-DSP) processors provide a multiply instruction
> that will multiply two N bit numbers producing an 2N bit product.
> The position of the binary point in the operands 

... which is the viewpoint I speak of (you won't actually SEE a
decimal place in the debugger when you examine the operands - it
is implied by usage) ...

> determine the position in the product.  A shift will put the
> appropriate bits into the destination register.

It might be a little more precise to say "a shift will place the 
implied binary point at the desired location."

We've gone over this here a few dozen times in past years, but for the
OP's sake, here's a quick explanation. Let's generalize the binary
point location and say that we have two operands in x.y format. When
we multiply them, the result is in 2x.2y format. In order to
"left-justify" the binary point so that the result is x.(2y + x)
(i.e., to match the input binary point), we shift left by x bits. If
the inputs are considered fractional numbers (-1 <= N < +1), then x =
1 and the amount of left shift required is 1.

FYI, I do not like using this notation. An "x.y" number implies you
have x bits for the integer portion of the number, and you do not (you
have x-1 bits).
-- 
%  Randy Yates                  % "I met someone who looks alot like you,
%% Fuquay-Varina, NC            %             she does the things you do, 
%%% 919-577-9882                %                     but she is an IBM."
%%%% <yates@ieee.org>           %        'Yours Truly, 2095', *Time*, ELO   
http://home.earthlink.net/~yatescr

Randy Yates wrote:

(snip)

> The OP should note that whether the number is 1.15, 16.0, or whatever,
> the difference is chiefly in your viewpoint. What Motorola hardware
> does is left shift by one after a multiply, which allows two numbers that
> were originally in fractional format (1.15) to remain in fractional format. 
> However, those numbers don't HAVE to be considered fractional. 

Many (non-DSP) processors provide a multiply instruction
that will multiply two N bit numbers producing an 2N bit product.
The position of the binary point in the operands determine the
position in the product.   A shift will put the appropriate bits
into the destination register.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Kevin Neilson wrote:
>
>> Luis Fernando wrote:
>
>>> i'm working with a motorola that can represent 1.15 fixed-point numbers
>
>>> any ideas on how can I multiply a number by 6.3121?
>
>> I'm not sure what you mean by 1.15.  I assume this means 1 bit left
>> of the radix point and 15 bits right of the radix point, although
>> you obviously can't store '6' in one bit.  But if we assume three
>> bits of integer and 15 bits of fraction,
>
> He wants to multiply a 1.15 number by decimal 6.13121.  The product
> could have more than one bit to the left of the binary point, but
> he can either keep it (not in 1.15) or truncate it.
>
> I don't know how the motorola multiply works, but in most cases
> it can be done with some pre or post shifting.

The OP should note that whether the number is 1.15, 16.0, or whatever,
the difference is chiefly in your viewpoint. What Motorola hardware
does is left shift by one after a multiply, which allows two numbers that
were originally in fractional format (1.15) to remain in fractional format. 
However, those numbers don't HAVE to be considered fractional. 
-- 
%  Randy Yates                  % "Ticket to the moon, flight leaves here today 
%% Fuquay-Varina, NC            %  from Satellite 2"
%%% 919-577-9882                % 'Ticket To The Moon' 
%%%% <yates@ieee.org>           % *Time*, Electric Light Orchestra
http://home.earthlink.net/~yatescr

Kevin Neilson wrote:

> Luis Fernando wrote:

>> i'm working with a motorola that can represent 1.15 fixed-point numbers

>> any ideas on how can I multiply a number by 6.3121?

> I'm not sure what you mean by 1.15.  I assume this means 1 bit left of 
> the radix point and 15 bits right of the radix point, although you 
> obviously can't store '6' in one bit.  But if we assume three bits of 
> integer and 15 bits of fraction,

He wants to multiply a 1.15 number by decimal 6.13121.  The product
could have more than one bit to the left of the binary point, but
he can either keep it (not in 1.15) or truncate it.

I don't know how the motorola multiply works, but in most cases
it can be done with some pre or post shifting.

-- glen

Luis Fernando wrote:
> hello
> 
> i'm working with a motorola that can represent 1.15 fixed-point numbers
> 
> any ideas on how can I multiply a number by 6.3121?
> 
> thanks
I'm not sure what you mean by 1.15.  I assume this means 1 bit left of 
the radix point and 15 bits right of the radix point, although you 
obviously can't store '6' in one bit.  But if we assume three bits of 
integer and 15 bits of fraction,

6.3121 = 110.010011111110011

I used a function I wrote for Matlab to do this, but you can do the same 
  thing manually:

integer part (6) = 110
fraction part (.3121) * 2^15 = 010011111110011

-Kevin