With the x86_64 (and ppc64) we see 64bit platforms to become
commonplace - simply recompiling a portable forth environment
yields 128bit values for the doublecell items. Yet, hmmm,
what would it be useful for? Or would it be good to just redefine
the doublecell words to be aliases for the cell-based words? It
seems to depend on how doublecells are currently used in
applications, I guess. WDYT?

-- guido http://PFE.sf.net
P.S. I did modify the fpnostack implementation for floating-ext
to occupy a single cell per float on the parameter stack
when sizeof(double) == sizeof(cell), i.e. 64bit platforms.

From:	Brad Eckert
Subject:	Re: doublecell usage on 64bit platforms
Date:	21 Jan 2005 15:36:29 -0800

I should have read the thread more closely -- we're talking about
entirely different things.

The thread is about whether or not to bother with certain double
operations on a 64-bit implementation. A 128/64 division is a little
excessive, I suppose, for #. 64/32 division would be faster but not
strictly ANS. The same reasoning goes for input conversion.

If I were the user, I'd want a switch. Standard mode uses the slower
ANS version. Gosh, that sounds ugly. Maybe that should just be an
option available when you metacompile.

--
Brad

From:	Elizabeth D. Rather
Subject:	Re: doublecell usage on 64bit platforms
Date:	Fri, 21 Jan 2005 16:13:29 -0800

"Brad Eckert" wrote in message
news:1106350589.079353.163940@f14g2000cwb.googlegroups.com...
> I should have read the thread more closely -- we're talking about
> entirely different things.
>
> The thread is about whether or not to bother with certain double
> operations on a 64-bit implementation. A 128/64 division is a little
> excessive, I suppose, for #. 64/32 division would be faster but not
> strictly ANS. The same reasoning goes for input conversion.
>
> If I were the user, I'd want a switch. Standard mode uses the slower
> ANS version. Gosh, that sounds ugly. Maybe that should just be an
> option available when you metacompile.

I'm not sure it's worth worrying about cycles here, any platform that size
is likely to be goshawful fast as well, and formatting numbers isn't going
to be in someone's time-critical inner loop.

Having it changable means your code is dependent on switch setting. I'd
rather make the choice as a programmer, using (for example) the 'u' prefix
words from Open Firmware if I didn't want to bother with doubles.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

From:	Albert van der Horst
Subject:	Re: doublecell usage on 64bit platforms
Date:	22 Jan 2005 14:07:38 GMT

In article <1106350589.079353.163940@f14g2000cwb.googlegroups.com>,
Brad Eckert wrote:
>I should have read the thread more closely -- we're talking about
>entirely different things.
>
>The thread is about whether or not to bother with certain double
>operations on a 64-bit implementation. A 128/64 division is a little
>excessive, I suppose, for #. 64/32 division would be faster but not
>strictly ANS. The same reasoning goes for input conversion.

Well, these might be occasionally valuable. And as Anton
Ertl has pointed out, scaling operators require a larger
intermediate precision.
What about special provisions in 64 bit looping, just in case
someone crosses the $7FFF,FFFF,FFFF,FFFF $8000,0000,0000,0000
address boundary? Now *that* is absurd.

>If I were the user, I'd want a switch. Standard mode uses the slower
>ANS version. Gosh, that sounds ugly. Maybe that should just be an
>option available when you metacompile.

<# just expects a double, and it is right there in the middle
of the CORE wordset. I don't think there is much to do really.

I have been thinking to allow standard conforming "sloppy" systems.
These systems would only guarantee that results where correct
if the input is restricted to 16 bits values. Then there
would be a list of words this applies to.
If this were done carefully, an application for a 16 bits Forth
would port to a standard conforming "sloppy" system.
The advantage would be that on top of the speed up of 100
in going to a modern 32 bits forth, one would gain an
additional 30% over running the software on a non-sloppy
system.
I decided that this idea is not worth pursuing.

The looping in DEC Alpha lina is sloppy. I take the Microsoft
attitude here. It is no problem until the users complain
in great numbers. Probably there aren't that many with more than
8 billion Gigabytes of RAM.

>--
>Brad
>

--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

From:	Krishna Myneni
Subject:	Re: doublecell usage on 64bit platforms
Date:	Tue, 18 Jan 2005 21:22:31 -0800

From:	Elizabeth D. Rather
Subject:	Re: doublecell usage on 64bit platforms
Date:	Tue, 18 Jan 2005 20:09:04 -0800

"Krishna Myneni" wrote in message
news:tfkHd.7768$vh.7699@bignews4.bellsouth.net....
> ...
> For a 64-bit system, the right answer is
>
> single cell = 64 bits
> double cell = 128 bits
>
> :) Anything else would lead to confusion. It's hard for me
> to imagine applications for counting beyond 64 bits, but
> that's my limited thinking. There are undoubtedly applications
> for such data types, and one should not restrict a Forth system
> from using them.

I agree that is the right answer. Practically speaking, if you're writing a
program for such a platform, you're very unlikely to be using
double-precision numbers, but if you're porting a program from a smaller
cell-size machine you might be very grateful that it works without your
having to re-examine all your numbers. Your double-precision numbers may
not use all those bits, but it'll still work fine.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

From:	Bernd Paysan
Subject:	Re: doublecell usage on 64bit platforms
Date:	Wed, 19 Jan 2005 10:43:20 +0100

Elizabeth D. Rather wrote:
> I agree that is the right answer. Practically speaking, if you're writing
> a program for such a platform, you're very unlikely to be using
> double-precision numbers [snip]

.... except if you are doing something like public key cryptography, where
128 bit is a bit on the low side (though not as low as 64 bit), i.e. bignum
stuff.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

From:	rickman
Subject:	Re: doublecell usage on 64bit platforms
Date:	Tue, 18 Jan 2005 14:02:38 -0500

Guido Draheim wrote:

> With the x86_64 (and ppc64) we see 64bit platforms to become
> commonplace - simply recompiling a portable forth environment
> yields 128bit values for the doublecell items. Yet, hmmm,
> what would it be useful for? Or would it be good to just redefine
> the doublecell words to be aliases for the cell-based words? It
> seems to depend on how doublecells are currently used in
> applications, I guess. WDYT?
>
> -- guido http://PFE.sf.net
> P.S. I did modify the fpnostack implementation for floating-ext
> to occupy a single cell per float on the parameter stack
> when sizeof(double) == sizeof(cell), i.e. 64bit platforms.

I would expect treating double cell words the same as single cell words
would cause many problems. Although double cell integer arithmetic may
transparently map to 64 bits the same as single cell arithmetic, the
double cell stack manipulations would not work as expected. Double cell
stack manipulations would be expected to work with double precision
arithmetic operands and at the same time manipulate the stack two single
precision operands at a time. Also, I believe the standard defines
double precision numbers as two cells with the MSW on the top of the
stack. It even says you can convert a single precision unsigned number
to a double by pushing a single precision 0.

Rather than use 64 bit singles and 128 bit doubles, it might be better
to keep single precision operands as 32 bit. This would support
existing code and still provide the full capabilities of the 64 bit
processor using the double precision functions. As you say, who really
needs 128 bit integers?

--

Rick Collins

rick.collins@XYarius.com

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design http://www.arius.com
4 King Ave. 301-682-7772 Voice
Frederick, MD 21701-3110 GNU tools for the ARM http://www.gnuarm.com

From:	Jerry Avins
Subject:	Re: doublecell usage on 64bit platforms
Date:	Tue, 18 Jan 2005 14:55:10 -0500

rickman wrote:

...

> It [the standard] even says you can convert a single precision unsigned
> number to a double by pushing a single precision 0.

For unsigned or non-negative numbers. In general, you need to sign extend.

When all ones id TRUE and the system is two's complement, use
: >double ( n -- d ) dup 0< ;

...

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	Anton Ertl
Subject:	Re: doublecell usage on 64bit platforms
Date:	Wed, 19 Jan 2005 18:19:57 GMT

Jerry Avins writes:
>rickman wrote:
>
> ...
>
>> It [the standard] even says you can convert a single precision unsigned
>> number to a double by pushing a single precision 0.
>
>For unsigned or non-negative numbers. In general, you need to sign extend.
>
>When all ones id TRUE and the system is two's complement, use
>: >double ( n -- d ) dup 0< ;

What's wrong with

|6.1.2170 S>D
|s-to-d CORE
|
| ( n -- d )
|
|Convert the number n to the double-cell number d with the same
|numerical value.

- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html

From:	rickman
Subject:	Re: doublecell usage on 64bit platforms
Date:	Wed, 19 Jan 2005 14:26:59 -0500

Jerry Avins wrote:

> rickman wrote:
>
> ...
>
>
>>It [the standard] even says you can convert a single precision unsigned
>>number to a double by pushing a single precision 0.
>
>
> For unsigned or non-negative numbers. In general, you need to sign extend.
>
> When all ones id TRUE and the system is two's complement, use
> : >double ( n -- d ) dup 0< ;

Do you see that this is not related to my point?

--

Rick Collins

rick.collins@XYarius.com

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design http://www.arius.com
4 King Ave. 301-682-7772 Voice
Frederick, MD 21701-3110 GNU tools for the ARM http://www.gnuarm.com

From:	Jerry Avins
Subject:	Re: doublecell usage on 64bit platforms
Date:	Wed, 19 Jan 2005 17:36:06 -0500

rickman wrote:

> Jerry Avins wrote:
>
>> rickman wrote:
>>
>> ...
>>
>>
>>> It [the standard] even says you can convert a single precision unsigned
>>> number to a double by pushing a single precision 0.
>>
>>
>>
>> For unsigned or non-negative numbers. In general, you need to sign
>> extend.
>>
>> When all ones is TRUE and the system is two's complement, use
>> : >double ( n -- d ) dup 0< ;
>
>
> Do you see that this is not related to my point?

Certainly, but these messages are archived, so I think it's important to
keep the record straight as a service to those who might unearth one
without context. One needn't be complete, but I think it's important not
to mislead. Am I too anal retentive?

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	Albert van der Horst
Subject:	Re: doublecell usage on 64bit platforms
Date:	19 Jan 2005 17:21:39 GMT

In article ,
rickman wrote:
>
>Rather than use 64 bit singles and 128 bit doubles, it might be better
>to keep single precision operands as 32 bit. This would support
>existing code and still provide the full capabilities of the 64 bit
>processor using the double precision functions. As you say, who really
>needs 128 bit integers?

I did a straight port of lina to the DEC Alpha in tens days flat.
The result is that the maximum length of a definition name is
18446744073709551615 characters (memory permitting).

Disallowing these things would have taken me much more than ten
days, and the frustration to decide where to stick arbitrary restrictions
to annoy the inadvertant user.

(High quality Forth's may warn about 32 character names:
"I will do what you intend, but your program is not ISO conforming.")

>--
>
>Rick Collins
>
>rick.collins@XYarius.com
>
>Arius - A Signal Processing Solutions Company
>Specializing in DSP and FPGA design http://www.arius.com
>4 King Ave. 301-682-7772 Voice
>Frederick, MD 21701-3110 GNU tools for the ARM http://www.gnuarm.com

--

--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

From:	Guido Draheim
Subject:	Re: doublecell usage on 64bit platforms
Date:	Tue, 18 Jan 2005 20:19:05 +0100

rickman wrote:
> Guido Draheim wrote:
> [..]
> precision operands at a time. Also, I believe the standard defines
> double precision numbers as two cells with the MSW on the top of the
> stack. It even says you can convert a single precision unsigned number
> to a double by pushing a single precision 0.
>
> Rather than use 64 bit singles and 128 bit doubles, it might be better
> to keep single precision operands as 32 bit. This would support
> existing code and still provide the full capabilities of the 64 bit
> processor using the double precision functions. As you say, who really
> needs 128 bit integers?
>

Exactly, the standard does even define the order of the two cells
which has made it so that on some platforms you can not (!!) use the
native longword arithmetics of the processor (unless swapping first)
- however you and Anton have a nice hint, as one may as well choose
to implement the doublecell arithmetics restricted to singlecell
precision. That leaves the twocell detail and allows to use 64bit
native processing of the platform while most applications would not
care.

Yet, it's not that easy - surely I could make it to be yet-another
build-option for PFE but I wonder if it would really bring about
much of a benefit - I am thinking of the need to update the upper
cell with the sign extension in twos complement. Everybody has been
given the knowledge where the upper cell is in the stack so that one
may think app writers can check the upper cell directly - even though
I am quite unsure what that would be good for.

-- cheers, guido http://PFE.sf.net

From:	Anton Ertl
Subject:	Re: doublecell usage on 64bit platforms
Date:	Wed, 19 Jan 2005 18:04:36 GMT

Guido Draheim writes:
>Exactly, the standard does even define the order of the two cells
>which has made it so that on some platforms you can not (!!) use the
>native longword arithmetics of the processor (unless swapping first)

I don't know any processor that has native 128-bit integers. But even
if there is, you are allowed to arrange the stack items in memory or
in registers in any way you want.

E.g., for a simple memory-based stack representation on a
little-endian machine, you could let the stack grow towards higher
addresses (and on a big-endian machine, let it grow towards lower
addresses), and use the native 128-bit load and store instructions to
access doubles, if they can handle unaligned accesses.

>- however you and Anton have a nice hint, as one may as well choose
>to implement the doublecell arithmetics restricted to singlecell
>precision. That leaves the twocell detail and allows to use 64bit
>native processing of the platform while most applications would not
>care.

It's a bad idea. If you don't want to support doubles, just don't do
the doubles wordset (ok, there are still some core words that deal
with doubles).

But why would you want to eliminate proper doubles from PFE?

>Yet, it's not that easy - surely I could make it to be yet-another
>build-option for PFE but I wonder if it would really bring about
>much of a benefit - I am thinking of the need to update the upper
>cell with the sign extension in twos complement. Everybody has been
>given the knowledge where the upper cell is in the stack so that one
>may think app writers can check the upper cell directly - even though
>I am quite unsure what that would be good for.

Well, one of those programmers who want to do with the core wordset
only could write SWAP DROP 0< instead of D0<.

Also, consider fixed-point arithmetic with numbers in the range 0..1:

: fix* ( fix1 fix2 -- fix )
um* nip ;

For that to work, you need proper doubles.

- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html

From:	Guido Draheim
Subject:	Re: doublecell usage on 64bit platforms
Date:	Wed, 19 Jan 2005 23:25:29 +0100

Anton Ertl wrote:
> Guido Draheim writes:
>
>>Exactly, the standard does even define the order of the two cells
>>which has made it so that on some platforms you can not (!!) use the
>>native longword arithmetics of the processor (unless swapping first)
>
>
> I don't know any processor that has native 128-bit integers. But even
> if there is, you are allowed to arrange the stack items in memory or
> in registers in any way you want.
>
> E.g., for a simple memory-based stack representation on a
> little-endian machine, you could let the stack grow towards higher
> addresses (and on a big-endian machine, let it grow towards lower
> addresses), and use the native 128-bit load and store instructions to
> access doubles, if they can handle unaligned accesses.

No, it would not be the traditional direction, using SP@ tricks
and such. I have seen those in real code quite a time (and I have
been trying to let old tricks to continue to work in pfe after
mapping the obvious word names to their ans forth cousin words).

>
>
>>- however you and Anton have a nice hint, as one may as well choose
>>to implement the doublecell arithmetics restricted to singlecell
>>precision. That leaves the twocell detail and allows to use 64bit
>>native processing of the platform while most applications would not
>>care.
>
>
> It's a bad idea. If you don't want to support doubles, just don't do
> the doubles wordset (ok, there are still some core words that deal
> with doubles).
>
> But why would you want to eliminate proper doubles from PFE?

There is no immediate intention behind my question - it's just that
I remember that dcells were used heavily in 16bit code to get
around the numeric limitations - and such programs would be running
unnecessarily on emulated 128bit arithmetic operations when being
put into forth on a 64bit platform. - That's why I did want to ask
what applications are there. Using dcells for 128bit cryptography
is fine but I'd expect that cryptographic applications do already
use their own words to ensure the bitlength - i.e. they emulate
which would be done with the dcell system implementation as well.

>
>
>>Yet, it's not that easy - surely I could make it to be yet-another
>>build-option for PFE but I wonder if it would really bring about
>>much of a benefit - I am thinking of the need to update the upper
>>cell with the sign extension in twos complement. Everybody has been
>>given the knowledge where the upper cell is in the stack so that one
>>may think app writers can check the upper cell directly - even though
>>I am quite unsure what that would be good for.
>
>
> Well, one of those programmers who want to do with the core wordset
> only could write SWAP DROP 0< instead of D0<.
>
> Also, consider fixed-point arithmetic with numbers in the range 0..1:
>
> : fix* ( fix1 fix2 -- fix )
> um* nip ;
>
> For that to work, you need proper doubles.
>

uhhhh, fixed point, I have to think that over a minute... ;-)

From:	Anton Ertl
Subject:	Re: doublecell usage on 64bit platforms
Date:	Fri, 21 Jan 2005 10:51:41 GMT

Guido Draheim writes:
>
>
>Anton Ertl wrote:
>> Guido Draheim writes:
>>
>>>Exactly, the standard does even define the order of the two cells
>>>which has made it so that on some platforms you can not (!!) use the
>>>native longword arithmetics of the processor (unless swapping first)
>>
>>
>> I don't know any processor that has native 128-bit integers. But even
>> if there is, you are allowed to arrange the stack items in memory or
>> in registers in any way you want.
>>
>> E.g., for a simple memory-based stack representation on a
>> little-endian machine, you could let the stack grow towards higher
>> addresses (and on a big-endian machine, let it grow towards lower
>> addresses), and use the native 128-bit load and store instructions to
>> access doubles, if they can handle unaligned accesses.
>
>No, it would not be the traditional direction, using SP@ tricks
>and such.

Sure, but that's your choice, that does not come from ANS Forth.

> I have seen those in real code quite a time (and I have
>been trying to let old tricks to continue to work in pfe after
>mapping the obvious word names to their ans forth cousin words).

Well, I guess then you would have chosen to let code work as well that
assumes that the most significant cell is on top, even if that
requirement was not in ANS Forth.

Anyway, these are not issues with 128-bit doubles on 64-bit machines,
these are issues with a 32-bit implementation and 64-bit doubles on
machines that support 64-bit integers (basically with 32-bit Forth
implementations on 64-bit machines).

>> But why would you want to eliminate proper doubles from PFE?
>
>There is no immediate intention behind my question - it's just that
>I remember that dcells were used heavily in 16bit code to get
>around the numeric limitations - and such programs would be running
>unnecessarily on emulated 128bit arithmetic operations when being
>put into forth on a 64bit platform. - That's why I did want to ask
>what applications are there. Using dcells for 128bit cryptography
>is fine but I'd expect that cryptographic applications do already
>use their own words to ensure the bitlength - i.e. they emulate
>which would be done with the dcell system implementation as well.

I don't know what you have in mind, but using the widest
multiplication supported by the CPU is essential for good performance
of such algorithms. So in Forth I would expect them to use M* or UM*;
on many Forth systems this will use the widening multiplication
available on most architectures; and on the rest the result usually
won't be slower than whatever one could do in Forth without M* or UM*.

E.g., Bernd recently did some work on getting gcc to provide 128bit
integers on AMD64, and he reports big speedups for RSA code (which
means that he has RSA code that uses doubles).

- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html

From:	Elizabeth D. Rather
Subject:	Re: doublecell usage on 64bit platforms
Date:	Wed, 19 Jan 2005 10:38:01 -0800

"Anton Ertl" wrote in message
news:2005Jan19.190436@mips.complang.tuwien.ac.at...
> ...
> It's a bad idea. If you don't want to support doubles, just don't do
> the doubles wordset (ok, there are still some core words that deal
> with doubles).

The '2'-prefix words (2DUP, etc.) have nothing to do with doubles per se,
they work with pairs of cells which may or may not have a relationship to
each other. These words are commonly used for things like string arguments
(addr len), 2-vectors, loop ranges, and other things which will be just as
common in large cell-size platforms as on smaller ones.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

From:	Anton Ertl
Subject:	Re: doublecell usage on 64bit platforms
Date:	Wed, 19 Jan 2005 18:45:31 GMT

"Elizabeth D. Rather" writes:
>"Anton Ertl" wrote in message
>news:2005Jan19.190436@mips.complang.tuwien.ac.at...
>> ...
>> It's a bad idea. If you don't want to support doubles, just don't do
>> the doubles wordset (ok, there are still some core words that deal
>> with doubles).
>
>The '2'-prefix words (2DUP, etc.) have nothing to do with doubles per se,
>they work with pairs of cells which may or may not have a relationship to
>each other.

I was referring to words that deal with doubles, not with cell-pairs,
e.g., # #S >NUMBER M* UM* FM/MOD SM/REM UM/MOD S>D.

- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html

From:	Elizabeth D. Rather
Subject:	Re: doublecell usage on 64bit platforms
Date:	Wed, 19 Jan 2005 11:23:31 -0800

"Anton Ertl" wrote in message
news:2005Jan19.194531@mips.complang.tuwien.ac.at...
> "Elizabeth D. Rather" writes:
> >"Anton Ertl" wrote in message
> >news:2005Jan19.190436@mips.complang.tuwien.ac.at...
> >> ...
> >> It's a bad idea. If you don't want to support doubles, just don't do
> >> the doubles wordset (ok, there are still some core words that deal
> >> with doubles).
> >
> >The '2'-prefix words (2DUP, etc.) have nothing to do with doubles per se,
> >they work with pairs of cells which may or may not have a relationship to
> >each other.
>
> I was referring to words that deal with doubles, not with cell-pairs,
> e.g., # #S >NUMBER M* UM* FM/MOD SM/REM UM/MOD S>D.

Ah, yes, the #-words are problematic, because it's inconvenient to provide
synthetic double numbers for those on a large-cell platform. Open Firmware
has added a set of 'u'-prefix words to provide for this: u#, u#s, and u#>
specifically. The others are harmless enough... an implementor might well
take advantage of being able to provide these in an off-line form.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

From:	Anton Ertl
Subject:	Re: doublecell usage on 64bit platforms
Date:	Wed, 19 Jan 2005 21:51:48 GMT

"Elizabeth D. Rather" writes:
>Ah, yes, the #-words are problematic, because it's inconvenient to provide
>synthetic double numbers for those on a large-cell platform.

I don't see it as more inconvenient than on small-cell platforms.

>The others are harmless enough...

In assembly language, yes. We define primitives in C, and we had to
work around the fact that the common 64-bit implementations of C don't
give use 128-bit integers, so we have to do them ourselves. Once we
have done that, we actually have everything needed for # (it is based
on um/mod).

> an implementor might well
>take advantage of being able to provide these in an off-line form.

I don't think 64-bit machines are so memory-starved that that is necessary.

- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html

From:	Elizabeth D. Rather
Subject:	Re: doublecell usage on 64bit platforms
Date:	Wed, 19 Jan 2005 15:04:09 -0800

"Anton Ertl" wrote in message
news:2005Jan19.225148@mips.complang.tuwien.ac.at...
> "Elizabeth D. Rather" writes:
> >Ah, yes, the #-words are problematic, because it's inconvenient to
provide
> >synthetic double numbers for those on a large-cell platform.
>
> I don't see it as more inconvenient than on small-cell platforms.

It isn't really more inconvenient, but the advantage of having these words
work that way is clearer. On a 16-bit platform, you have a lot of double
numbers, and they're often not synthetic at all. With 32 bits and up,
real-world double numbers almost vanish, so folks (particularly newbies) are
wondering why they need to allow for doubles.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

From:	Anton Ertl
Subject:	Re: doublecell usage on 64bit platforms
Date:	Fri, 21 Jan 2005 12:51:40 GMT

"Elizabeth D. Rather" writes:
>With 32 bits and up,
>real-world double numbers almost vanish,

I run into situations where integers exceed 2G and 4G frequently enough
(e.g., execution counts, clock ticks, file sizes).

> so folks (particularly newbies) are
>wondering why they need to allow for doubles.

For programmers the answer is simple: If they don't need them, they
don't need them, and they don't need to worry about them. I don't
know what "allow for" would mean for programmers.

For system implementors, the answer is simple, too: Because there are
programs that need them.

- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html

From:	Stephen Pelc
Subject:	Re: doublecell usage on 64bit platforms
Date:	Thu, 20 Jan 2005 11:08:22 GMT

On Wed, 19 Jan 2005 15:04:09 -0800, "Elizabeth D. Rather"
wrote:

>It isn't really more inconvenient, but the advantage of having these words
>work that way is clearer. On a 16-bit platform, you have a lot of double
>numbers, and they're often not synthetic at all. With 32 bits and up,
>real-world double numbers almost vanish, so folks (particularly newbies) are
>wondering why they need to allow for doubles.

Try calculating a 100 billion US dollar project with Turkish
subcontractors operating in old-style Turkish currency. On the
Hong Kong airport project, the savings caused by the use of
large integers were in excess of US$10,000,000 for the concrete
at the top of the piling alone.

Our clients with big project and financial calculations regularly
need up to 128 bit integers. One may well ask whether these
should be a structure in memory, but ... and Forth is a stack
language.

Stephen

--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

From:	Brad Eckert
Subject:	Re: doublecell usage on 64bit platforms
Date:	19 Jan 2005 15:55:25 -0800

I wouldn't miss double numbers even on 16-bit systems. A state-smart
word like ## can be defined to get a double number from the input
stream. The same goes for any other number type, like floats (use F#)
or strings (use C" or S").

Sure it would break my 16-bit code, but how hard is it to search files
for double numbers and automatically fix the appropriate text?

Brad

From:	Elizabeth D. Rather
Subject:	Re: doublecell usage on 64bit platforms
Date:	Wed, 19 Jan 2005 18:27:09 -0800

"Brad Eckert" wrote in message
news:1106178925.270536.119360@z14g2000cwz.googlegroups.com...
> I wouldn't miss double numbers even on 16-bit systems. A state-smart
> word like ## can be defined to get a double number from the input
> stream. The same goes for any other number type, like floats (use F#)
> or strings (use C" or S").

But in my experience, double numbers that you're about to format for output
come from anywhere BUT the input stream -- results of calculations,
integrated data, all kinds of processes that leave a double on the stack all
ready to feed to a word that will format it. And usually every bit counts,
too.

> Sure it would break my 16-bit code, but how hard is it to search files
> for double numbers and automatically fix the appropriate text?

Virtually impossible, since they result from processes which may be complex.
There's no way you can find them by scanning source except with some very
fancy software that's modeling stack effects somehow.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

From:	Jorge Acereda
Subject:	Re: doublecell usage on 64bit platforms
Date:	Tue, 18 Jan 2005 23:39:05 +0100

On Tue, 18 Jan 2005 19:10:08 +0100, Guido Draheim wrote:
> With the x86_64 (and ppc64) we see 64bit platforms to become
> commonplace - simply recompiling a portable forth environment
> yields 128bit values for the doublecell items. Yet, hmmm,
> what would it be useful for? Or would it be good to just redefine
> the doublecell words to be aliases for the cell-based words? It
> seems to depend on how doublecells are currently used in
> applications, I guess. WDYT?

The aliases would be a very bad idea (what would 2@ do?). OTOH you can
be sure someone will find an interesting use for 128 bit values.

See you,
Jorge Acereda

From:	Anton Ertl
Subject:	Re: doublecell usage on 64bit platforms
Date:	Tue, 18 Jan 2005 18:49:09 GMT

Guido Draheim writes:
>With the x86_64 (and ppc64) we see 64bit platforms to become
>commonplace - simply recompiling a portable forth environment
>yields 128bit values for the doublecell items. Yet, hmmm,
>what would it be useful for?

Really big numbers. Cryptography. Whatever. If somebody uses them,
they hopefully know what they are doing.

> Or would it be good to just redefine
>the doublecell words to be aliases for the cell-based words?

Not sure what you mean here, but simple aliases will break a lot of
things (e.g., the stack effects will be wrong).

Even if you mean that you just implement double-cell words as using
64-bit operations (leaving the upper half unused), I guess that will
break a number of things.

And why would you do that? PFE could do proper doubles on 64-bit
platforms 10 years ago. Why retract now?

[mips:~/tmp:1449] pfe
A portable Forth environment written in C. Version 0.9.14 of 01-November-95
Copyright Dirk Uwe Zoller 1995. Please enter LICENSE and WARRANTY.

To quit say BYE.

Hi there, enjoy Forth!

-1. ud. 340282366920938463463374607431768211455 ok
bye
Goodbye!

- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html