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

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

Forth without integer data stack. It is even better!

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

Contents

  Forth without integer data stack. It is even better! "Ilya V. Vasilyev" <arvi1973@gmail.com> - 2015-08-15 19:22 -0700
    Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-15 20:42 -0700
      Re: Forth without integer data stack. It is even better! "Ilya V. Vasilyev" <arvi1973@gmail.com> - 2015-08-16 02:13 -0700
        Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-18 12:09 -0700
          Re: Forth without integer data stack. It is even better! Michael Barry <barrym95838@yahoo.com> - 2015-08-18 15:33 -0700
            Re: Forth without integer data stack. It is even better! Michael Barry <barrym95838@yahoo.com> - 2015-08-18 16:18 -0700
              Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-19 08:22 +0000
          Re: Forth without integer data stack. It is even better! "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-19 03:38 -0400
          Re: Forth without integer data stack. It is even better! "Ilya V. Vasilyev" <arvi1973@gmail.com> - 2015-09-19 17:21 -0700
            Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-09-19 21:07 -0700
    Re: Forth without integer data stack. It is even better! "WJ" <w_a_x_man@yahoo.com> - 2015-08-16 06:52 +0000
    Re: Forth without integer data stack. It is even better! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-08-16 14:19 +0200
      Re: Forth without integer data stack. It is even better! Mark Wills <markwills1970@gmail.com> - 2015-08-16 05:52 -0700
        Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-16 14:42 -0700
          Re: Forth without integer data stack. It is even better! dylan.mcnamee@gmail.com - 2015-09-21 12:02 -0700
            Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-22 00:34 +0200
        Re: Forth without integer data stack. It is even better! "WJ" <w_a_x_man@yahoo.com> - 2015-09-26 19:18 +0000
      Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-16 12:08 -0700
        Re: Forth without integer data stack. It is even better! rickman <gnuarm@gmail.com> - 2015-08-16 15:17 -0400
    Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 13:47 +0000
      Re: Forth without integer data stack. It is even better! Paul Rubin <no.email@nospam.invalid> - 2015-08-16 07:54 -0700
        Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 15:04 +0000
          Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-16 23:56 +0200
            Re: Forth without integer data stack. It is even better! Richard Owlett <rowlett@cloud85.net> - 2015-08-17 05:57 -0500
              Re: Forth without integer data stack. It is even better! Coos Haak <chforth@hccnet.nl> - 2015-08-17 13:52 +0200
                Re: Forth without integer data stack. It is even better! Mark Wills <markwills1970@gmail.com> - 2015-08-17 05:00 -0700
              Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-17 12:03 +0000
                Re: Forth without integer data stack. It is even better! Mark Wills <markwills1970@gmail.com> - 2015-08-17 05:29 -0700
                  Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 09:10 +0000
            Re: Forth without integer data stack. It is even better! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-08-17 14:50 +0200
              Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-17 19:42 +0200
                Re: Forth without integer data stack. It is even better! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-08-17 23:16 +0200
                  Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-18 01:00 +0200
                    Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-18 01:17 +0200
                      Re: Forth without integer data stack. It is even better! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-08-18 10:12 +0200
                Re: Forth without integer data stack. It is even better! Александр Стадниченко <stadnichenko.a.s@gmail.com> - 2015-09-26 08:12 -0700
                Re: Forth without integer data stack. It is even better! Александр Стадниченко <stadnichenko.a.s@gmail.com> - 2015-09-26 08:35 -0700
                  Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-26 21:23 +0200
                    Re: Forth without integer data stack. It is even better! Александр Стадниченко <stadnichenko.a.s@gmail.com> - 2015-09-27 09:55 -0700
                    Re: Forth without integer data stack. It is even better! Александр Стадниченко <stadnichenko.a.s@gmail.com> - 2015-09-27 10:00 -0700
      Re: Forth without integer data stack. It is even better! mhx@iae.nl - 2015-08-16 08:37 -0700
    Re: Forth without integer data stack. It is even better! Michael Barry <barrym95838@yahoo.com> - 2015-08-17 18:28 -0700
      Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-17 20:17 -0700
        Re: Forth without integer data stack. It is even better! rickman <gnuarm@gmail.com> - 2015-08-18 00:49 -0400
          Re: Forth without integer data stack. It is even better! Michael Barry <barrym95838@yahoo.com> - 2015-08-17 23:00 -0700
            Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 06:25 +0000
              Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-18 08:39 -0700
                Re: Forth without integer data stack. It is even better! rickman <gnuarm@gmail.com> - 2015-08-18 12:09 -0400
    Re: Forth without integer data stack. It is even better! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-08-18 01:31 -0700
      Re: Forth without integer data stack. It is even better! "Ilya V. Vasilyev" <arvi1973@gmail.com> - 2015-09-12 17:47 -0700
        Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-09-12 18:06 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#41339

On Sunday, August 16, 2015 at 4:19:48 PM UTC+2, Anton Ertl wrote:
> "Ilya V. Vasilyev" <arvi1973@gmail.com> writes:
> > At my opinion, integer stack is obsole=
> >te in 2015 and the future of Forth is with floating point. Modern computers=
> > are fast enough to make floating point the main data type.
> 
> I did a little experiment for evaluating the performance impact.  The
> idea is that the worst case for this kind of design is probably a
> chain of dependent @s, i.e., something like this microbenchmark:
> 
> perf stat gforth-fast -e "variable x x x ! \
> : foo x 100000000 0 do @ @ @ @ @ loop drop ; \
> foo bye"
> 
> On a Core i3--3227U (Ivy Bridge) this takes 2G cycles, i.e., 4 cycles
> per @ (this agrees with the D-cache latency of 4 cycles on the Ivy
> Bridge).
> 
> So let's do a variant that goes through FP values: @ would expand to
> f>s f@, etc.  To make this compile to good code, I have added a static
> superinstruction for f>s f@ for this experiment.  The benchmark code
> now is:
> 
> perf stat gforth-fast -e "fvariable x x s>f x f! \
> : foo x s>f 100000000 0 do f>s f@ f>s f@ f>s f@ f>s f@ f>s f@ loop fdrop ; \
> foo bye"
> 
> This takes 5G cycles, i.e., 10 cycles per @ replacement.  I.e., a
> slowdown factor of 2.5 for this microbenchmark.  I guess that the
> slowdown will be less for most applications (dependent adds could be
> worse).  The code for each @ (or its replacement looks as follows):
> 
> @                      f>s f@
> mov    (%r14),%r14     cvttsd2si %xmm15,%rax
> add    $0x8,%rbx       add    $0x10,%rbx
>                        movsd  (%rax),%xmm15
> 
> The adds to rbx keep the VM instruction pointer up-to-date, but are
> performed in parallel with the other stuff and therfore don't cost
> performance in this latency-measuring benchmarks.
> 
> So if you can live with a Forth system that's slower by a factor of 2
> or so, this is certainly an interesting variant.

It might be a little worse on other systems and of course
depending on the type of float (I map F@ to extended-float).

-marcel

FORTH> anew -floap  ok
FORTH>   ok
FORTH> variable x x x !    ok
FORTH> : foo1 x #100000000 0 do @ @ @ @ @ loop drop ;    ok
FORTH> TICKS-RESET CR foo1 TICKS? (n,3)
2,056,549,550  ok
FORTH>   ok
FORTH> fvariable y y s>f y f!    ok
FORTH> : foo2 y s>f #100000000 0 do  f>s f@ f>s f@ f>s f@ f>s f@ f>s f@  loop fdrop ;  ok
FORTH> TICKS-RESET CR foo2 TICKS? (n,3)
7,534,275,676  ok
FORTH>   ok
FORTH> dfvariable z z s>f z df!    ok
FORTH> : foo3 z s>f #100000000 0 do  f>s df@ f>s df@ f>s df@ f>s df@ f>s df@  loop fdrop ;  ok
FORTH> TICKS-RESET CR foo3 TICKS? (n,3)
5,891,734,234  ok

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

#41361

On Saturday, August 15, 2015 at 7:22:05 PM UTC-7, Ilya V. Vasilyev wrote:
> I made Forth implementation without integer data stack. Main data
> stack contains float values.
> 
> Here is the summary:
> http://the-hacker.ru/2015/ForthWithoutIntegerDataStack.pdf
> 
It is possible that I missed this detail in your .pdf, but my main
 concern would be that cells used as pointers would be subject to
 normalization, meaning that floats would have to be translated to
 address units before being used as memory addresses, in order to
 prevent chaos, overlap and discontinuity in words that directly
 accessed data structures.

It does open up an interesting possibility for a certain 32-bit
 processor that can't directly access individual bytes:  a word
 dealing with packed byte-grained string data could just increase
 the pointer by multiples of 0.25 to traverse the string and keep
 track of its length and starting address.

Mike B.

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

#41363

On Monday, August 17, 2015 at 6:28:18 PM UTC-7, Michael Barry wrote:
> On Saturday, August 15, 2015 at 7:22:05 PM UTC-7, Ilya V. Vasilyev wrote:
> > I made Forth implementation without integer data stack. Main data
> > stack contains float values.
> > 
> > Here is the summary:
> > http://the-hacker.ru/2015/ForthWithoutIntegerDataStack.pdf
> > 
> It is possible that I missed this detail in your .pdf, but my main
>  concern would be that cells used as pointers would be subject to
>  normalization, meaning that floats would have to be translated to
>  address units before being used as memory addresses, in order to
>  prevent chaos, overlap and discontinuity in words that directly
>  accessed data structures.

I don't think this is a problem.

In the Lua book, it was mentioned that a lot of people think that floats are "fuzzy" and that an integer stored in a float will somehow pick up a fractional part when other integers stored in floats are added to it. This isn't true. There is no theoretical basis for this belief, and the Lua guys have never run into any problems in practice.

You do have to use FSCALE to convert between integers and floats, and this is definitely necessary when the "integer" is an address that you are going to fetch or store to. I was told on comp.lang.asm.x86 that FSCALE is very slow, but nobody knows why --- this is a quirk of the x86 (at least, the current models). This shouldn't be much of a problem though, unless the compiler is very dumb and isn't able to keep values as integers if they are being used as indices or whatever, and it is clear at compile-time that they will never have a fractional part.

> It does open up an interesting possibility for a certain 32-bit
>  processor that can't directly access individual bytes:  a word
>  dealing with packed byte-grained string data could just increase
>  the pointer by multiples of 0.25 to traverse the string and keep
>  track of its length and starting address.

Your "certain 32-bit processor" is your own design, isn't it? ;-)

Your fractional addresses are a possibility, but they seem confusing to me. 

Your processor presumably doesn't have a floating-point coprocessor built-in like on the x86, so it is a non-issue anyway. For a processor like the x86 that does floating-point fast, I think Ilya has a good idea --- especially for applications such as CAM that do a lot of floating-point computation.

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

#41364

On 8/17/2015 11:17 PM, hughaguilar96@gmail.com wrote:
> On Monday, August 17, 2015 at 6:28:18 PM UTC-7, Michael Barry wrote:
>> On Saturday, August 15, 2015 at 7:22:05 PM UTC-7, Ilya V. Vasilyev
>> wrote:
>>> I made Forth implementation without integer data stack. Main
>>> data stack contains float values.
>>>
>>> Here is the summary:
>>> http://the-hacker.ru/2015/ForthWithoutIntegerDataStack.pdf
>>>
>> It is possible that I missed this detail in your .pdf, but my main
>> concern would be that cells used as pointers would be subject to
>> normalization, meaning that floats would have to be translated to
>> address units before being used as memory addresses, in order to
>> prevent chaos, overlap and discontinuity in words that directly
>> accessed data structures.
>
> I don't think this is a problem.
>
> In the Lua book, it was mentioned that a lot of people think that
> floats are "fuzzy" and that an integer stored in a float will somehow
> pick up a fractional part when other integers stored in floats are
> added to it. This isn't true. There is no theoretical basis for this
> belief, and the Lua guys have never run into any problems in
> practice.

That is not strictly true.  As long as you don't exceed the range of the 
mantissa, integers in floating point are exact.  But given that an 
integer can be larger than can be represented in the mantissa (plus the 
hidden bit if used) the floating point number then the low order bits of 
the integer is lost.  This is a fair comparison in that the larger 
integer could be represented exactly in the same number of bits as the 
floating point number.

-- 

Rick

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

#41365

On Monday, August 17, 2015 at 9:49:09 PM UTC-7, rickman wrote:
>
> That is not strictly true.  As long as you don't exceed the range of the 
> mantissa, integers in floating point are exact.  But given that an 
> integer can be larger than can be represented in the mantissa (plus the 
> hidden bit if used) the floating point number then the low order bits of 
> the integer is lost.  This is a fair comparison in that the larger 
> integer could be represented exactly in the same number of bits as the 
> floating point number.
> 

The point I was clumsily trying to make is that the physical address
 sent to access RAM can't be just the mantissa, because normalization
 would cause many different float values to have the same mantissa but
 a different exponent.  So some translation would be required rather
 than just slapping the mantissa on the address bus.  Just slapping the
 full-width float on the address bus would probably guarantee that
 every float address was unique, at least in one direction, but would
 be non-linear, so I don't think that would be a satisfactory technique
 either.

Mike B.

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

#41366

Michael Barry <barrym95838@yahoo.com> writes:
>The point I was clumsily trying to make is that the physical address
> sent to access RAM can't be just the mantissa, because normalization
> would cause many different float values to have the same mantissa but
> a different exponent.  So some translation would be required rather
> than just slapping the mantissa on the address bus.  Just slapping the
> full-width float on the address bus would probably guarantee that
> every float address was unique, at least in one direction, but would
> be non-linear, so I don't think that would be a satisfactory technique
> either.

One could require IEEE FP numbers, and then represent addresses with
denormal numbers, and then we can use the FP number directly as
address without conversion to integer first.  However, then CHAR+
would not be 1 +, but ULP +; finally it would make sense that we have
CHARS and CHAR+, but a lot of existing code would not work (but most
of that probably would not work with the other option, either).

The other big disadvantage is that denormals are reportedly slow or
very slow (as in, causing a trap and performing the computation in
software) on a number of machines; not sure how the performance on
currently popular hardware is, though.

Even on hardware with fast denormals, the advantage of this scheme
would not be as big as one may think, though.  The slow thing is not
the conversion from FP to integers itself, but getting the datum from
the FP registers in the FP unit to the integer registers in the
integer unit.  In the old Pentium 4 (Williamette) times, integer
shifts were expensive, because the integers were shipped over to the
FPU, then shifted, and then shipped back; the shipping crossed several
clock domains, losing a cycle at every border.  This was at 2000MHz,
now we are at 4000MHz, and the clock domains are probably even smaller
than then.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#41371

On Monday, August 17, 2015 at 11:45:11 PM UTC-7, Anton Ertl wrote:
> Michael Barry <barrym95838@yahoo.com> writes:
> >The point I was clumsily trying to make is that the physical address
> > sent to access RAM can't be just the mantissa, because normalization
> > would cause many different float values to have the same mantissa but
> > a different exponent.  So some translation would be required rather
> > than just slapping the mantissa on the address bus.  Just slapping the
> > full-width float on the address bus would probably guarantee that
> > every float address was unique, at least in one direction, but would
> > be non-linear, so I don't think that would be a satisfactory technique
> > either.
> 
> One could require IEEE FP numbers, and then represent addresses with
> denormal numbers, and then we can use the FP number directly as
> address without conversion to integer first.  However, then CHAR+
> would not be 1 +, but ULP +; finally it would make sense that we have
> CHARS and CHAR+, but a lot of existing code would not work (but most
> of that probably would not work with the other option, either).
> 
> The other big disadvantage is that denormals are reportedly slow or
> very slow (as in, causing a trap and performing the computation in
> software) on a number of machines; not sure how the performance on
> currently popular hardware is, though.
> 
> Even on hardware with fast denormals, the advantage of this scheme
> would not be as big as one may think, though.  The slow thing is not
> the conversion from FP to integers itself, but getting the datum from
> the FP registers in the FP unit to the integer registers in the
> integer unit.  In the old Pentium 4 (Williamette) times, integer
> shifts were expensive, because the integers were shipped over to the
> FPU, then shifted, and then shipped back; the shipping crossed several
> clock domains, losing a cycle at every border.  This was at 2000MHz,
> now we are at 4000MHz, and the clock domains are probably even smaller
> than then.

I don't like denormals at all --- that is highly non-standard --- it is not going to always work, and if it does work it might be "very slow" because it is a screwy idea supported as an after-thought.

I think that a smart compiler should be able to determine at compile-time which parameters are going to be integers throughout and just hold them in registers or in local variables as integers --- Lua does that.

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

#41374

On 8/18/2015 11:39 AM, hughaguilar96@gmail.com wrote:
>
> I don't like denormals at all --- that is highly non-standard --- it
> is not going to always work, and if it does work it might be "very
> slow" because it is a screwy idea supported as an after-thought.

Whose standard doesn't include denormal numbers?  IEEE754 does, they 
just call them "subnormal numbers".  With denormals you can represent 
numbers closer to zero.

-- 

Rick

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

#41368

> My Russian MK-161 machine is unique. 

From the datasheet: based on the 77e58.
http://mk.semico.ru/dokum.htm 

From Google: '77e58 - 89c51 Compatible 40-pin 24mhz 32kb 8-bit Microcontroller'

Unique russuan machine? Just an emulating program running on 8-bit MCU. You can use integer number if you need...

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

#41979

On Tuesday, August 18, 2015 at 7:49:09 AM UTC+3, rickman wrote:

> > I don't think this is a problem.
> >
> > In the Lua book, it was mentioned that a lot of people think that
> > floats are "fuzzy" and that an integer stored in a float will somehow
> > pick up a fractional part when other integers stored in floats are
> > added to it. This isn't true. There is no theoretical basis for this
> > belief, and the Lua guys have never run into any problems in
> > practice.
> 
> That is not strictly true.  As long as you don't exceed the range of the 
> mantissa, integers in floating point are exact.  But given that an 
> integer can be larger than can be represented in the mantissa (plus the 
> hidden bit if used) the floating point number then the low order bits of 
> the integer is lost.  This is a fair comparison in that the larger 

Thats why one should use the largest FP type available for the main data stack. Mantissa should have more bits than regular integer types.

The cell type of main floating-only stack should be superset of all other standard data types and + * operations work on those super large cells.

/ should be integer division, so we lose bits no more than on integer stack.

F/ should be separate operation for those, who aware that stack is FP.

Software, that doesn't need FP, can't notice it runs on FP stack. The only difference is the speed. It's like running on a computer, that is two (or more) years older.

When new generation of computers arrive to run the same software on FP stack, there should be no difference at all.


On Tuesday, August 18, 2015 at 11:31:09 AM UTC+3, Ilya Tarasov wrote:
> > My Russian MK-161 machine is unique. 
> 
> From the datasheet: based on the 77e58.
> http://mk.semico.ru/dokum.htm 
> 
> From Google: '77e58 - 89c51 Compatible 40-pin 24mhz 32kb 8-bit Microcontroller'
> 
> Unique russuan machine? Just an emulating program running on 8-bit MCU. You can use integer number if you need...

Yes, the lowest level is integer only CPU. But this level is hidden and unavailable to owners of MK-161.

The only layer, available for Forth implementation, is on the top of floating point only machine. In my case, I had no choice but to use floats.

--
Ilya V. Vasilyev
Moscow, Russia

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

#41980

On Saturday, September 12, 2015 at 5:47:45 PM UTC-7, Ilya V. Vasilyev wrote:
> On Tuesday, August 18, 2015 at 7:49:09 AM UTC+3, rickman wrote:
> 
> > > I don't think this is a problem.
> > >
> > > In the Lua book, it was mentioned that a lot of people think that
> > > floats are "fuzzy" and that an integer stored in a float will somehow
> > > pick up a fractional part when other integers stored in floats are
> > > added to it. This isn't true. There is no theoretical basis for this
> > > belief, and the Lua guys have never run into any problems in
> > > practice.
> > 
> > That is not strictly true.  As long as you don't exceed the range of the 
> > mantissa, integers in floating point are exact.  But given that an 
> > integer can be larger than can be represented in the mantissa (plus the 
> > hidden bit if used) the floating point number then the low order bits of 
> > the integer is lost.  This is a fair comparison in that the larger 
> 
> Thats why one should use the largest FP type available for the main data stack. Mantissa should have more bits than regular integer types.

Strictly speaking, it is called a "significand," not a "mantissa" --- also, it can have the same number of bits as the regular integer types (it doesn't need more bits) --- for example, 32 bits is fine (this is common in software floating-point, although it is not IEEE-754 standard).

> The cell type of main floating-only stack should be superset of all other standard data types and + * operations work on those super large cells.
> 
> / should be integer division, so we lose bits no more than on integer stack.
> 
> F/ should be separate operation for those, who aware that stack is FP.
> 
> Software, that doesn't need FP, can't notice it runs on FP stack. The only difference is the speed. It's like running on a computer, that is two (or more) years older.
> 
> When new generation of computers arrive to run the same software on FP stack, there should be no difference at all.

All in all, I think that Ilya Vasilyev's idea is good --- I'm going to adopt this in my language.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web