Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #55929 > unrolled thread

n00b confusion regarding the implementation vs. specification of *

Back to article view | Back to comp.lang.forth

Contents

  n00b confusion regarding the implementation vs. specification of * Michael Barry <barrym95838@yahoo.com> - 2017-03-19 10:41 -0700
    Re: n00b confusion regarding the implementation vs. specification of * Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-19 13:58 -0500
      Re: n00b confusion regarding the implementation vs. specification of * rickman <gnuarm@gmail.com> - 2017-03-19 19:06 -0400
        Re: n00b confusion regarding the implementation vs. specification of * Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-20 03:53 -0500
          Re: n00b confusion regarding the implementation vs. specification of * rickman <gnuarm@gmail.com> - 2017-03-20 06:56 -0400
            Re: n00b confusion regarding the implementation vs. specification of * Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-20 07:53 -0500
              Re: n00b confusion regarding the implementation vs. specification of * rickman <gnuarm@gmail.com> - 2017-03-20 18:15 -0400
                Re: n00b confusion regarding the implementation vs. specification of * Coos Haak <htrofhc@gmail.com> - 2017-03-20 23:30 +0100
                Re: n00b confusion regarding the implementation vs. specification of * julian.fondren@endurance.com - 2017-03-20 15:34 -0700
                Re: n00b confusion regarding the implementation vs. specification of * "Elizabeth D. Rather" <erather@forth.com> - 2017-03-20 14:40 -1000
                  Re: n00b confusion regarding the implementation vs. specification of * hughaguilar96@gmail.com - 2017-03-20 19:41 -0700
                  Re: n00b confusion regarding the implementation vs. specification of * anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-21 17:18 +0000
            Re: n00b confusion regarding the implementation vs. specification of * anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-20 15:07 +0000
    Re: n00b confusion regarding the implementation vs. specification of * hughaguilar96@gmail.com - 2017-03-19 12:32 -0700
      Re: n00b confusion regarding the implementation vs. specification of * hughaguilar96@gmail.com - 2017-03-19 13:54 -0700
    Re: n00b confusion regarding the implementation vs. specification of * albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-19 21:21 +0100
      Re: n00b confusion regarding the implementation vs. specification of * Michael Barry <barrym95838@yahoo.com> - 2017-03-19 16:41 -0700
        Re: n00b confusion regarding the implementation vs. specification of * anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-21 17:56 +0000
    Re: n00b confusion regarding the implementation vs. specification of * anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-20 08:57 +0000

#55929 — n00b confusion regarding the implementation vs. specification of *

Hello all.  Linking to this document:
 (hopefully safe to post without getting decapitated)

http://www.forth200x.org/documents/forth-2012.pdf

I find the spec for *

6.1.0090 * "star" CORE
 ( n1 | u1 n2 | u2 –– n3 | u3 )
 Multiply n1 | u1 by n2 | u2 giving the product n3 | u3

This seems to imply that * can handle signed or unsigned integers
 equally well, but in my experience this is not possible.  My
 natural impulse would be to implement * for signed integers and
 U* for unsigned integers, but I see no mention of U* in the
 above-referenced document.

What simple detail am I missing in my attempt to understand this?

Mike B.

[toc] | [next] | [standalone]

#55936

Michael Barry <barrym95838@yahoo.com> wrote:
> Hello all.  Linking to this document:
> (hopefully safe to post without getting decapitated)
> 
> http://www.forth200x.org/documents/forth-2012.pdf
> 
> I find the spec for *
> 
> 6.1.0090 * "star" CORE
> ( n1 | u1 n2 | u2 -- n3 | u3 )
> Multiply n1 | u1 by n2 | u2 giving the product n3 | u3
> 
> This seems to imply that * can handle signed or unsigned integers
> equally well, but in my experience this is not possible.  My
> natural impulse would be to implement * for signed integers and
> U* for unsigned integers, but I see no mention of U* in the
> above-referenced document.
> 
> What simple detail am I missing in my attempt to understand this?

In two's complement representation, for every pair of arguments,
signed or unsigned, the resulting bit pattern is correct when
interpreted as either signed or unsigned.  This follows because signed
and unsigned addition don't need special handling, and multiplication
is no more than repeated addition.

Andrew.

[toc] | [prev] | [next] | [standalone]

#55949

On 3/19/2017 2:58 PM, Andrew Haley wrote:
> Michael Barry <barrym95838@yahoo.com> wrote:
>> Hello all.  Linking to this document:
>> (hopefully safe to post without getting decapitated)
>>
>> http://www.forth200x.org/documents/forth-2012.pdf
>>
>> I find the spec for *
>>
>> 6.1.0090 * "star" CORE
>> ( n1 | u1 n2 | u2 -- n3 | u3 )
>> Multiply n1 | u1 by n2 | u2 giving the product n3 | u3
>>
>> This seems to imply that * can handle signed or unsigned integers
>> equally well, but in my experience this is not possible.  My
>> natural impulse would be to implement * for signed integers and
>> U* for unsigned integers, but I see no mention of U* in the
>> above-referenced document.
>>
>> What simple detail am I missing in my attempt to understand this?
>
> In two's complement representation, for every pair of arguments,
> signed or unsigned, the resulting bit pattern is correct when
> interpreted as either signed or unsigned.  This follows because signed
> and unsigned addition don't need special handling, and multiplication
> is no more than repeated addition.

Try it sometime.  A multiplication routine doing shift and add of the 
multiplicand using the bits in the multiplier as enable flags does not 
work for a negative multiplier.  If your statement were correct, it 
should work regardless.  Instead the multiplier has to be negated along 
with the result.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#55959

rickman <gnuarm@gmail.com> wrote:
> On 3/19/2017 2:58 PM, Andrew Haley wrote:
>>
>> In two's complement representation, for every pair of arguments,
>> signed or unsigned, the resulting bit pattern is correct when
>> interpreted as either signed or unsigned.  This follows because signed
>> and unsigned addition don't need special handling, and multiplication
>> is no more than repeated addition.
> 
> Try it sometime.  A multiplication routine doing shift and add of the 
> multiplicand using the bits in the multiplier as enable flags does not 
> work for a negative multiplier.  If your statement were correct, it 
> should work regardless.  Instead the multiplier has to be negated along 
> with the result.

Please provide an example of a pair of numbers which demonstrates
this.

Andrew.

[toc] | [prev] | [next] | [standalone]

#55962

On 3/20/2017 4:53 AM, Andrew Haley wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On 3/19/2017 2:58 PM, Andrew Haley wrote:
>>>
>>> In two's complement representation, for every pair of arguments,
>>> signed or unsigned, the resulting bit pattern is correct when
>>> interpreted as either signed or unsigned.  This follows because signed
>>> and unsigned addition don't need special handling, and multiplication
>>> is no more than repeated addition.
>>
>> Try it sometime.  A multiplication routine doing shift and add of the
>> multiplicand using the bits in the multiplier as enable flags does not
>> work for a negative multiplier.  If your statement were correct, it
>> should work regardless.  Instead the multiplier has to be negated along
>> with the result.
>
> Please provide an example of a pair of numbers which demonstrates
> this.

Any non-trivial negative number for a multiplier.  Try it, you'll see. 
I wracked my brain trying to figure out a way to adjust the result to 
make it work.  After all, negative numbers just have the sign bit 
different, right?  Good luck!

Albert, indicated that multiply works the same for unsigned and signed 
numbers as long as the unsigned numbers don't overflow.  However if you 
do a signed multiply using an unsigned number with the msb set, that 
screws it up.  This is true even if the result is double precision.  So 
you can't do an unsigned multiply on signed numbers in the general case.

   0101  (5)  multiplicand
x 1010  (-6) multiplier

Here is each step
Multiplier  Product
1010        0000 0000
    ^--- zero, so don't add multiplicand and shift

0101        0010 1000
    ^--- one, so add multiplicand and shift

0010        0001 0100
    ^--- zero, so don't add multiplicand and shift

0001        0011 0010
    ^--- one, so add multiplicand and shift

Result is 0x32 or 50.


Negate first...

Multiplier  Product
0110        0000 0000
    ^--- zero, so don't add multiplicand and shift

0011        0010 1000
    ^--- one, so add multiplicand and shift

0001        0011 1100
    ^--- one, so add multiplicand and shift

0000        0001 1110
    ^--- zero, so don't add multiplicand and shift

Negate product
0001 1110   -->  1110 0010

Result is 0xE2 or -30.


Using the same binary numbers, but treating them as all unsigned gets 
the opposite results.  The -6 is now a 10.  The unsigned multiply gives 
the right result, 50 and the signed multiply gives 226, a wrong result.

I've read that Booth's algorithm works for both signed and unsigned 
numbers, but I don't know if they have to be handled differently.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#55964

rickman <gnuarm@gmail.com> wrote:
> On 3/20/2017 4:53 AM, Andrew Haley wrote:
>> rickman <gnuarm@gmail.com> wrote:
>>> On 3/19/2017 2:58 PM, Andrew Haley wrote:
>>>>
>>>> In two's complement representation, for every pair of arguments,
>>>> signed or unsigned, the resulting bit pattern is correct when
>>>> interpreted as either signed or unsigned.  This follows because
>>>> signed and unsigned addition don't need special handling, and
>>>> multiplication is no more than repeated addition.
>>>
>>> Try it sometime.  A multiplication routine doing shift and add of the
>>> multiplicand using the bits in the multiplier as enable flags does not
>>> work for a negative multiplier.  If your statement were correct, it
>>> should work regardless.  Instead the multiplier has to be negated along
>>> with the result.
>>
>> Please provide an example of a pair of numbers which demonstrates
>> this.
> 
> Any non-trivial negative number for a multiplier.  Try it, you'll see. 
> I wracked my brain trying to figure out a way to adjust the result to 
> make it work.  After all, negative numbers just have the sign bit 
> different, right?  Good luck!
> 
> Albert, indicated that multiply works the same for unsigned and signed 
> numbers as long as the unsigned numbers don't overflow.  However if you 
> do a signed multiply using an unsigned number with the msb set, that 
> screws it up.  This is true even if the result is double precision.  So 
> you can't do an unsigned multiply on signed numbers in the general case.
> 
>   0101  (5)  multiplicand
> x 1010  (-6) multiplier

The result is -30, which does not fit in a 4-bit signed integer.

The question is about the Forth word *, which by definition takes two
cell-size numbers and multiplies them together, producing a product of
cell size.  The question is not about any other definition of
multiplication, especially not one which has a double-length product.

Mixed-precision multiplication needs M* and UM*, obviously.

Andrew.

[toc] | [prev] | [next] | [standalone]

#55977

On 3/20/2017 8:53 AM, Andrew Haley wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On 3/20/2017 4:53 AM, Andrew Haley wrote:
>>> rickman <gnuarm@gmail.com> wrote:
>>>> On 3/19/2017 2:58 PM, Andrew Haley wrote:
>>>>>
>>>>> In two's complement representation, for every pair of arguments,
>>>>> signed or unsigned, the resulting bit pattern is correct when
>>>>> interpreted as either signed or unsigned.  This follows because
>>>>> signed and unsigned addition don't need special handling, and
>>>>> multiplication is no more than repeated addition.
>>>>
>>>> Try it sometime.  A multiplication routine doing shift and add of the
>>>> multiplicand using the bits in the multiplier as enable flags does not
>>>> work for a negative multiplier.  If your statement were correct, it
>>>> should work regardless.  Instead the multiplier has to be negated along
>>>> with the result.
>>>
>>> Please provide an example of a pair of numbers which demonstrates
>>> this.
>>
>> Any non-trivial negative number for a multiplier.  Try it, you'll see.
>> I wracked my brain trying to figure out a way to adjust the result to
>> make it work.  After all, negative numbers just have the sign bit
>> different, right?  Good luck!
>>
>> Albert, indicated that multiply works the same for unsigned and signed
>> numbers as long as the unsigned numbers don't overflow.  However if you
>> do a signed multiply using an unsigned number with the msb set, that
>> screws it up.  This is true even if the result is double precision.  So
>> you can't do an unsigned multiply on signed numbers in the general case.
>>
>>   0101  (5)  multiplicand
>> x 1010  (-6) multiplier
>
> The result is -30, which does not fit in a 4-bit signed integer.

So?  A multiply operation in general produces as many bits in the result 
as the total number of bits in the operands.  You can always toss any 
bits you choose, but that is not inherent in the multiply in any way.


> The question is about the Forth word *, which by definition takes two
> cell-size numbers and multiplies them together, producing a product of
> cell size.  The question is not about any other definition of
> multiplication, especially not one which has a double-length product.
>
> Mixed-precision multiplication needs M* and UM*, obviously.

Ok, if you limit multiplication to results that fit in the same word as 
the operands signed and unsigned may be the same.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#55978

Op Mon, 20 Mar 2017 18:15:24 -0400 schreef rickman:

> On 3/20/2017 8:53 AM, Andrew Haley wrote:
>> rickman <gnuarm@gmail.com> wrote:
>>> On 3/20/2017 4:53 AM, Andrew Haley wrote:
>>>> rickman <gnuarm@gmail.com> wrote:
>>>>> On 3/19/2017 2:58 PM, Andrew Haley wrote:
>>>>>>
>>>>>> In two's complement representation, for every pair of arguments,
>>>>>> signed or unsigned, the resulting bit pattern is correct when
>>>>>> interpreted as either signed or unsigned.  This follows because
>>>>>> signed and unsigned addition don't need special handling, and
>>>>>> multiplication is no more than repeated addition.
>>>>>
>>>>> Try it sometime.  A multiplication routine doing shift and add of the
>>>>> multiplicand using the bits in the multiplier as enable flags does not
>>>>> work for a negative multiplier.  If your statement were correct, it
>>>>> should work regardless.  Instead the multiplier has to be negated along
>>>>> with the result.
>>>>
>>>> Please provide an example of a pair of numbers which demonstrates
>>>> this.
>>>
>>> Any non-trivial negative number for a multiplier.  Try it, you'll see.
>>> I wracked my brain trying to figure out a way to adjust the result to
>>> make it work.  After all, negative numbers just have the sign bit
>>> different, right?  Good luck!
>>>
>>> Albert, indicated that multiply works the same for unsigned and signed
>>> numbers as long as the unsigned numbers don't overflow.  However if you
>>> do a signed multiply using an unsigned number with the msb set, that
>>> screws it up.  This is true even if the result is double precision.  So
>>> you can't do an unsigned multiply on signed numbers in the general case.
>>>
>>>   0101  (5)  multiplicand
>>> x 1010  (-6) multiplier
>>
>> The result is -30, which does not fit in a 4-bit signed integer.
> 
> So?  A multiply operation in general produces as many bits in the result 
> as the total number of bits in the operands.  You can always toss any 
> bits you choose, but that is not inherent in the multiply in any way.
> 
> 
>> The question is about the Forth word *, which by definition takes two
>> cell-size numbers and multiplies them together, producing a product of
>> cell size.  The question is not about any other definition of
>> multiplication, especially not one which has a double-length product.
>>
>> Mixed-precision multiplication needs M* and UM*, obviously.
> 
> Ok, if you limit multiplication to results that fit in the same word as 
> the operands signed and unsigned may be the same.

If you use * in a program, signed or unsigned results
(by nature) are the same. 2-complement arithmetic dictates this.

If you want different results, you have to use UM* and M*.

groet Coos

[toc] | [prev] | [next] | [standalone]

#55979

On Monday, March 20, 2017 at 5:15:24 PM UTC-5, rickman wrote:
> On 3/20/2017 8:53 AM, Andrew Haley wrote:
> > The question is about the Forth word *, which by definition takes two
> > cell-size numbers and multiplies them together, producing a product of
> > cell size.  The question is not about any other definition of
> > multiplication, especially not one which has a double-length product.
> >
> > Mixed-precision multiplication needs M* and UM*, obviously.
> 
> Ok, if you limit multiplication to results that fit in the same word as 
> the operands signed and unsigned may be the same.

THE STANDARD STRIKES AGAIN
A play.

Self-describe n00b: hmm.. is the Earth flat? I just saw this video...

Raving Idiot: yes it is! ANSI DOESN'T WANT YOU TO KNOW

(a rabble of confused people)
It must be flat. Roads are flat.
You can't find a single flat road on a sphere!
Have you *seen* Australia?
Look at this NATO map projection!

Non-idiot: what? what? Look, it's a flattened sphereoid. (explains in detail)

Petulant wrong guy:ok sure if you LIMIT your PERSPECTIVE to
what's REAL and VERIFIABLE by air quotes SCIENCE air quotes
then sure MAYBE the Earth might not be completely flat... jerk.

[toc] | [prev] | [next] | [standalone]

#55983

On 3/20/17 12:15 PM, rickman wrote:
> On 3/20/2017 8:53 AM, Andrew Haley wrote:
>> rickman <gnuarm@gmail.com> wrote:
>>> On 3/20/2017 4:53 AM, Andrew Haley wrote:
>>>> rickman <gnuarm@gmail.com> wrote:
>>>>> On 3/19/2017 2:58 PM, Andrew Haley wrote:
>>>>>>
>>>>>> In two's complement representation, for every pair of arguments,
>>>>>> signed or unsigned, the resulting bit pattern is correct when
>>>>>> interpreted as either signed or unsigned.  This follows because
>>>>>> signed and unsigned addition don't need special handling, and
>>>>>> multiplication is no more than repeated addition.
>>>>>
>>>>> Try it sometime.  A multiplication routine doing shift and add of the
>>>>> multiplicand using the bits in the multiplier as enable flags does not
>>>>> work for a negative multiplier.  If your statement were correct, it
>>>>> should work regardless.  Instead the multiplier has to be negated
>>>>> along
>>>>> with the result.
>>>>
>>>> Please provide an example of a pair of numbers which demonstrates
>>>> this.
>>>
>>> Any non-trivial negative number for a multiplier.  Try it, you'll see.
>>> I wracked my brain trying to figure out a way to adjust the result to
>>> make it work.  After all, negative numbers just have the sign bit
>>> different, right?  Good luck!
>>>
>>> Albert, indicated that multiply works the same for unsigned and signed
>>> numbers as long as the unsigned numbers don't overflow.  However if you
>>> do a signed multiply using an unsigned number with the msb set, that
>>> screws it up.  This is true even if the result is double precision.  So
>>> you can't do an unsigned multiply on signed numbers in the general case.
>>>
>>>   0101  (5)  multiplicand
>>> x 1010  (-6) multiplier
>>
>> The result is -30, which does not fit in a 4-bit signed integer.
>
> So?  A multiply operation in general produces as many bits in the result
> as the total number of bits in the operands.  You can always toss any
> bits you choose, but that is not inherent in the multiply in any way.
>
>
>> The question is about the Forth word *, which by definition takes two
>> cell-size numbers and multiplies them together, producing a product of
>> cell size.  The question is not about any other definition of
>> multiplication, especially not one which has a double-length product.
>>
>> Mixed-precision multiplication needs M* and UM*, obviously.
>
> Ok, if you limit multiplication to results that fit in the same word as
> the operands signed and unsigned may be the same.

All of this points up why some of Forth's unique arithmetic operators 
are so valuable, such as M*/ which multiplies two singles giving a 
double-length product, which is then divided by a single. This takes 
advantage of the fact that MUL operators on virtually all processors 
leave a DP product, and DIV operators divide a double by a single, so 
combining these into one mixed operator gives you a more precise result 
in many cases than using * followed by /.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#55989

On Monday, March 20, 2017 at 5:40:29 PM UTC-7, Elizabeth D. Rather wrote:
> All of this points up why some of Forth's unique arithmetic operators 
> are so valuable, such as M*/ which multiplies two singles giving a 
> double-length product, which is then divided by a single. This takes 
> advantage of the fact that MUL operators on virtually all processors 
> leave a DP product, and DIV operators divide a double by a single, so 
> combining these into one mixed operator gives you a more precise result 
> in many cases than using * followed by /.

You have said this before. When I needed D/ (a function to divide one double by another) for my continued fractions program you said:

On Friday, November 20, 2009 at 12:07:12 AM UTC-7, Elizabeth D Rather wrote:
> Hugh Aguilar wrote:
> ...
> > The problem is the ANS-Forth standard. Really, how obvious was the
> > need for double-precision arithmetic? This could have been an
> > extension to the language similar to floating-point. Compiler-writers
> > working on small microprocessors could decline to implement it if they
> > didn't want to.
> > 
> > I am frustrated with the ANS-Forth standard because I believe that the
> > bad design of the standard is the #1 reason for the failure of Forth
> > to become an important language. Forth was doing pretty well in the
> > 1980s, but we needed a standard. What we got was Forth-83, and then
> > ANS-Forth-94, both of which were badly designed. With some more
> > thoughtful leadership we could have succeeded.
> 
> There are D+, D-, M*, M/, and M*/ (and the unsigned operators).  These 
> were adequate in a very wide variety of projects over a 30 year period, 
> many of which were extremely computation-intensive and running on slow 
> 16-bit processors.
> 
> Forth's design is pragmatic: it has functions that have been needed and 
> that have proven their usefulness *in Forth*, not necessarily those that 
> have been required in other languages.  Generally speaking, Forth has 
> the most flexible set of *integer* arithmetic operators of any language. 
>   In particular, M*/ was one of Chuck's most brilliant innovations.  I'm 
> sure if Chuck were trying to do your continued fractions that is what he 
> would rely on.  Yes, that sometimes requires thinking differently, like 
> many other things in Forth.
> 
> Cheers,
> Elizabeth

This was my first contact with you. This was in this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/BcWvGxFFuzA%5B1-25%5D

My interpretation of this was that you are telling me I can't be an ANS-Forth programmer --- you expect me to apologize for saying that I need D/ for my continued fractions program --- you want me to tell you that you are the "leading expert" on writing a continued fraction program.

BTW: I have continued fractions in the novice-package in the CF.4TH file --- this includes D/ written in high-level Forth --- this was written by Nathaniel Grosman in 16-bit Forth-83 originally, and then upgraded by me to work under 32-bit ANS-Forth.

You also said this:

On Friday, November 20, 2009 at 6:12:36 PM UTC-7, Elizabeth D Rather wrote:
> The major reason Forth hasn't been accepted is lack of marketing, either 
> in the form of adoption by major companies or organizations or papers in 
> various publications, meetings, etc.  The vast majority of programmers 
> out there haven't considered Forth and rejected it for some reason 
> (although some have heard -- and passed on -- rumors about 
> unreadability, etc.), they simply never heard of it.

[toc] | [prev] | [next] | [standalone]

#56024

"Elizabeth D. Rather" <erather@forth.com> writes:
>This takes 
>advantage of the fact that MUL operators on virtually all processors 
>leave a DP product, and DIV operators divide a double by a single,

A collegue of mine once said that "virtually" is a synonym for "not".

And that is true in this case, too.  IA-32/AMD64 and MIPS have double
results for multiplication, and double-by-single division, but
otherwise?  And even on AMD64 single multiplication results and
single-by-single division is faster.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#55966

rickman <gnuarm@gmail.com> writes:
>   0101  (5)  multiplicand
>x 1010  (-6) multiplier
...
[unsigned 4x4->8 multiplication)
>Result is 0x32 or 50.

The 4x4->4 result is 2

[signed 4x4->8 multiplication]
>Result is 0xE2 or -30.

The 4x4->4 result is 2.

I.e., same result.  That's why we have only one *, but both M* and
UM*.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#55938

On Sunday, March 19, 2017 at 10:41:06 AM UTC-7, Michael Barry wrote:
> Hello all.  Linking to this document:
>  (hopefully safe to post without getting decapitated)
> 
> http://www.forth200x.org/documents/forth-2012.pdf
> 
> I find the spec for *
> 
> 6.1.0090 * "star" CORE
>  ( n1 | u1 n2 | u2 –– n3 | u3 )
>  Multiply n1 | u1 by n2 | u2 giving the product n3 | u3
> 
> This seems to imply that * can handle signed or unsigned integers
>  equally well, but in my experience this is not possible.  My
>  natural impulse would be to implement * for signed integers and
>  U* for unsigned integers, but I see no mention of U* in the
>  above-referenced document.
> 
> What simple detail am I missing in my attempt to understand this?
> 
> Mike B.

You aren't missing any detail --- you are right! --- * only works for signed numbers, not unsigned.

Note that processors have different instructions for signed and unsigned multiplication. On the x86 with have MUL and IMUL. I assume that you are designing your 65m32 processor and have gotten to the point of designing the multiplication instructions, which is why you noticed this problem in ANS-Forth. 

Good eye! I have read through the ANS-Forth document multiple times and never noticed that mistake. I never bothered to read the definition of * because it is such a simple word I hadn't expected Elizabeth Rather to have screwed it up.

Anyway --- if want an unsigned multiplication, you have to use UM* and get a double-precision result --- I agree that a U* would be useful though.

On a related note, I'm not going to support unsigned numbers in Straight Forth. I will only have signed numbers. Addresses will be signed too --- the heap is in the negative part, and the dictionary is in the positive part --- this is a useful distinction because FREE will know if its address is actually in the heap, but will do nothing if it is in the dictionary.

[toc] | [prev] | [next] | [standalone]

#55944

On Sunday, March 19, 2017 at 12:32:52 PM UTC-7, hughag...@gmail.com wrote:
> Anyway --- if want an unsigned multiplication, you have to use UM* and get a double-precision result --- I agree that a U* would be useful though.

I was mistaken when I said that U* would be useful --- such a function can't exist.

* only works on signed numbers. If any unsigned number is big enough to have its high bit set, then it is a signed number --- it can't be treated as an unsigned number unless you are going to overflow into a high word, which is what UM* does --- M* also overflows into a high word, but it treats the numbers as signed.

The ANS-Forth document shouldn't have described * as being for both signed and unsigned --- that is very confusing --- it only works for signed numbers, but any unsigned number that is big enough to have its high-bit set will overflow and give an incorrect result (when you consider the result to be unsigned).

[toc] | [prev] | [next] | [standalone]

#55941

In article <788f5318-e6c4-499d-838a-89c45a917142@googlegroups.com>,
Michael Barry  <barrym95838@yahoo.com> wrote:
>Hello all.  Linking to this document:
> (hopefully safe to post without getting decapitated)
>
>http://www.forth200x.org/documents/forth-2012.pdf
>
>I find the spec for *
>
>6.1.0090 * "star" CORE
> ( n1 | u1 n2 | u2 =E2=80=93=E2=80=93 n3 | u3 )
> Multiply n1 | u1 by n2 | u2 giving the product n3 | u3
>
>This seems to imply that * can handle signed or unsigned integers
> equally well, but in my experience this is not possible.  My
> natural impulse would be to implement * for signed integers and
> U* for unsigned integers, but I see no mention of U* in the
> above-referenced document.
>
>What simple detail am I missing in my attempt to understand this?

If you multiply two 10 digit numbers you get a 20 digit number.

The following example illustrates why the standard works:

-1 -1 M* DH.
0000,0000,0000,0000,0000,0000,0000,0001 OK
-1 -1 UM* DH.
FFFF,FFFF,FFFF,FFFE,0000,0000,0000,0001 OK
-1 H.
FFFF,FFFF,FFFF,FFFF OK
-1 U.
18446744073709551615  OK
-1 -1 * .
1  OK
18446744073709551615 DUP *  U.
1  OK

You may think that is incorrect because overflow occurred,
but interpreted as modulo 2^64 numbers it is correct and it is
the accepted result in Forth.
If the product of unsigned numbers doesn't overflow,
* gives the correct result.
Note that the programmer interprets the number on the stack by using
either . and U. . The number remains the same.

>
>Mike B.

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

[toc] | [prev] | [next] | [standalone]

#55951

On Sunday, March 19, 2017 at 1:21:47 PM UTC-7, Albert van der Horst wrote:
> If you multiply two 10 digit numbers you get a 20 digit number.
> 
> The following example illustrates why the standard works:
> 
> -1 -1 M* DH.
> 0000,0000,0000,0000,0000,0000,0000,0001 OK
> -1 -1 UM* DH.
> FFFF,FFFF,FFFF,FFFE,0000,0000,0000,0001 OK
> -1 H.
> FFFF,FFFF,FFFF,FFFF OK
> -1 U.
> 18446744073709551615  OK
> -1 -1 * .
> 1  OK
> 18446744073709551615 DUP *  U.
> 1  OK
> 
> You may think that is incorrect because overflow occurred,
> but interpreted as modulo 2^64 numbers it is correct and it is
> the accepted result in Forth.
> If the product of unsigned numbers doesn't overflow,
> * gives the correct result.
> Note that the programmer interprets the number on the stack by using
> either . and U. . The number remains the same.
> 
> Groetjes Albert

Thank you, Albert.  I haven't fully digested your explanation,
 but I have some confidence in it.  My 65m32 has a machine
 instruction that acts kind of like something the fictitious
 Forth word UM*+ would do.  I can use it for * if I just pre-
 load the addend to zero and DROP the high half of the result,
 I think.  For M* it looks like I would have to do a bit more
 pre- and post-processing if the multiplicand and/or the
 multiplier are negative.  I'll get to work checking it out.

Thanks to all,

Mike B.

[toc] | [prev] | [next] | [standalone]

#56028

Michael Barry <barrym95838@yahoo.com> writes:
> For M* it looks like I would have to do a bit more
> pre- and post-processing if the multiplicand and/or the
> multiplier are negative.

Gforth contains

: m*  ( n1 n2 -- d )
 2dup      0< and >r
 2dup swap 0< and >r
 um* r> - r> - ;

Based on an explanation that Andrew Haley posted many years ago.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#55960

Michael Barry <barrym95838@yahoo.com> writes:
>Hello all.  Linking to this document:
> (hopefully safe to post without getting decapitated)
>
>http://www.forth200x.org/documents/forth-2012.pdf
>
>I find the spec for *
>
>6.1.0090 * "star" CORE
> ( n1 | u1 n2 | u2 =E2=80=93=E2=80=93 n3 | u3 )
> Multiply n1 | u1 by n2 | u2 giving the product n3 | u3
>
>This seems to imply that * can handle signed or unsigned integers
> equally well, but in my experience this is not possible.  My
> natural impulse would be to implement * for signed integers and
> U* for unsigned integers, but I see no mention of U* in the
> above-referenced document.
>
>What simple detail am I missing in my attempt to understand this?

On twos-complement hardware, * gives the same result as U*, for all
inputs.

Why is that?  A negative number n is represented by the same bit
pattern as the unsigned number 2^w+n; we are only having w-bit
results, so that's the same as n (mod 2^w).

Now multiply n1 by n2 (mod 2^w): We get n1*n2 (mod 2^w).  There may be
funky things going on in the high cell of a singlexsingle->double
multiplication (that's why we have both M* and UM*), but the low cell
is always the same.

You can play it through for all four quadrants, but I'll give only one
as example:

Let's multiply a positive n1 with a negative n2, and look at it as an
unsigned operation:

n1 * (2^w+n2) = n1*2^w + (2^w+n1*n2) = 2^w+n1*n2 (mod 2^w)

So unless there is an overflow, the result is a negative number
represented by 2^w+n1*n2; n1*2^w=0 (mod 2^w), so it does not appear in
the final view.  If there is an overflow, you still get n1*n2 (mod
2^n), but the canonical representation of that is then c*2^w+n1*n2,
with a fitting c.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web