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

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

Forth for a balanced ternary machine

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

Contents

  Forth for a balanced ternary machine Matthias Koch <m.cook@gmx.net> - 2026-05-25 14:58 +0200
    Re: Forth for a balanced ternary machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-25 18:10 +0000
      Re: Forth for a balanced ternary machine dxf <dxforth@gmail.com> - 2026-05-26 15:53 +1000
        Re: Forth for a balanced ternary machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-26 07:46 +0000
          Re: Forth for a balanced ternary machine dxf <dxforth@gmail.com> - 2026-05-27 00:52 +1000
            Teaching Scenarios [Re: Forth for a balanced ternary machine] Buzz McCool <buzz_mccool@yahoo.com> - 2026-05-26 08:52 -0700
              Re: Teaching Scenarios [Re: Forth for a balanced ternary machine] dxf <dxforth@gmail.com> - 2026-05-28 21:03 +1000
              Re: Teaching Scenarios [Re: Forth for a balanced ternary machine] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-30 20:16 +0000
                Re: Teaching Scenarios [Re: Forth for a balanced ternary machine] minforth <minforth@gmx.net> - 2026-05-31 11:02 +0200
                  Re: Teaching Scenarios [Re: Forth for a balanced ternary machine] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-31 14:13 +0000
            Division (was: Forth for a balanced ternary machine) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-30 18:23 +0000
              Re: Division dxf <dxforth@gmail.com> - 2026-05-31 12:49 +1000
                Re: Division anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-31 14:20 +0000
                  Re: Division dxf <dxforth@gmail.com> - 2026-06-01 12:47 +1000
                arithmetic shift right (was: Division) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-31 14:43 +0000
                  Re: arithmetic shift right dxf <dxforth@gmail.com> - 2026-06-01 18:18 +1000
        Re: Forth for a balanced ternary machine Hans Bezemer <the.beez.speaks@gmail.com> - 2026-06-01 23:23 +0200
          Re: Forth for a balanced ternary machine dxf <dxforth@gmail.com> - 2026-06-03 13:30 +1000
            Re: Forth for a balanced ternary machine Hans Bezemer <the.beez.speaks@gmail.com> - 2026-06-04 11:59 +0200
              Re: Forth for a balanced ternary machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-04 12:15 +0000
            Re: Forth for a balanced ternary machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-04 12:08 +0000
              Re: Forth for a balanced ternary machine dxf <dxforth@gmail.com> - 2026-06-05 17:37 +1000
                Re: Forth for a balanced ternary machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-05 09:22 +0000
      Re: Forth for a balanced ternary machine Matthias Koch <m.cook@gmx.net> - 2026-05-28 13:36 +0200

Page 1 of 2  [1] 2  Next page →

#135095 — Forth for a balanced ternary machine

A few days ago, I released an experiment on how Forth might adapt to a balanced ternary architecture, with an instruction set emulator and a native FPGA implementation included. In balanced ternary, all numbers are signed with low-level arithmetic being quite elegant, and there are new logic operators to explore. If you like to dive in: https://codeberg.org/Mecrisp/mecrisp-ternary

[toc] | [next] | [standalone]

#135097

Matthias Koch <m.cook@gmx.net> writes:
[reformatted to follow line length conventions:]
>A few days ago, I released an experiment on how Forth might adapt to
>a balanced ternary architecture, with an instruction set emulator and
>a native FPGA implementation included. In balanced ternary, all
>numbers are signed with low-level arithmetic being quite elegant, and
>there are new logic operators to explore. If you like to dive in:
>https://codeberg.org/Mecrisp/mecrisp-ternary

Quite interesting.

A note on:

|In balanced ternary, a right shift is exactly the same as symmetric
|division by powers of three, unlike binary in which right-shifting
|negative two-complement numbers to divide by powers of two gives
|rounding artifacts.

Floored division is not any more a rounding artifact than symmetric
division is.  Whether to use floored or symmetric division depends on
the application.  That's why we have FM/MOD and SM/REM in the
standard.  The Forth-83 committee was so strongly in favour of floored
that they broke compatibility with Forth-79 because of that.

Gforth since 0.7 implements / and other division words where Forth-94
allows the system to choose as floored division words.  This means
that in Gforth, "2 /" is equivalent to 2/ (which is defined as a shift
right by 1 bit):

-3 2 / . \ prints -2
-3 2/ .  \ prints -2

- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/

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

#135098

On 26/05/2026 4:10 am, Anton Ertl wrote:
> Matthias Koch <m.cook@gmx.net> writes:
> ... 
> |In balanced ternary, a right shift is exactly the same as symmetric
> |division by powers of three, unlike binary in which right-shifting
> |negative two-complement numbers to divide by powers of two gives
> |rounding artifacts.
> 
> Floored division is not any more a rounding artifact than symmetric
> division is.  Whether to use floored or symmetric division depends on
> the application.  That's why we have FM/MOD and SM/REM in the
> standard.  The Forth-83 committee was so strongly in favour of floored
> that they broke compatibility with Forth-79 because of that.
> 
> Gforth since 0.7 implements / and other division words where Forth-94
> allows the system to choose as floored division words.  This means
> that in Gforth, "2 /" is equivalent to 2/ (which is defined as a shift
> right by 1 bit):
> 
> -3 2 / . \ prints -2
> -3 2/ .  \ prints -2

Which is all very nice until beginners ask how that makes any sense ;-)

ANS at least tells you 2* 2/ are bit-shifters with historic, albeit misleading,
names.

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

#135099

dxf <dxforth@gmail.com> writes:
>On 26/05/2026 4:10 am, Anton Ertl wrote:
>> Gforth since 0.7 implements / and other division words where Forth-94
>> allows the system to choose as floored division words.  This means
>> that in Gforth, "2 /" is equivalent to 2/ (which is defined as a shift
>> right by 1 bit):
>> 
>> -3 2 / . \ prints -2
>> -3 2/ .  \ prints -2
>
>Which is all very nice until beginners ask how that makes any sense ;-)

They don't (I know because I have been teaching Forth beginners for
three decades).  That's because negative dividends are rare, and
negative divisors are even rarer.  But in those cases where negative
dividends occur, floored division usually makes sense, and users
encountering it don't ask.

>ANS at least tells you 2* 2/ are bit-shifters with historic, albeit misleading,
>names.

The name of 2* is not misleading on architectures with 2s-complement
arithmetic.  I.e., every architecture designed in the last
half-century (the IBM S/360 is actually 62 years old), and everything
that any existing standard system (for any Forth standard) runs on.

And the name 2/ is not misleading on Forth systems where / is floored,
such as Gforth.

Here's what the Forth-94 rationale says:

|A.6.1.0320 2*
|
|Historically, 2* has been implemented on two's-complement machines as
|a logical left-shift instruction. Multiplication by two is an
|efficient side-effect on these machines. However, shifting implies a
|knowledge of the significance and position of bits in a cell. While
|the name implies multiplication, most implementors have used a
|hardware left shift to implement 2*.
|
|A.6.1.0330 2/
|
|This word has the same common usage and misnaming implications as
|2*. It is often implemented on two's-complement machines with a
|hardware right shift that propagates the sign bit.

These sections may mislead the reader into believing that 2* and 2/
actually mean something different than

|6.1.0320 2* two-star CORE
|	( x1 -- x2 )
|
|x2 is the result of shifting x1 one bit toward the most-significant
|bit, filling the vacated least-significant bit with zero.
|
|6.1.0330 2/ two-slash CORE
|	( x1 -- x2 )
|
|x2 is the result of shifting x1 one bit toward the least-significant
|bit, leaving the most-significant bit unchanged.

The rationale sections above were deleted in an editorial change in
2012, but I don't know why.  Anyway, given the obvious difference
between the name and the specification of the behaviour, does it need
a rationale to explain that there may be a difference?

However, with the acceptance of the 2s-complement proposal, there no
longer is a difference for 2*, and one might specify it as multiplying
by 2.

- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/

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

#135100

On 26/05/2026 5:46 pm, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> On 26/05/2026 4:10 am, Anton Ertl wrote:
>>> Gforth since 0.7 implements / and other division words where Forth-94
>>> allows the system to choose as floored division words.  This means
>>> that in Gforth, "2 /" is equivalent to 2/ (which is defined as a shift
>>> right by 1 bit):
>>>
>>> -3 2 / . \ prints -2
>>> -3 2/ .  \ prints -2
>>
>> Which is all very nice until beginners ask how that makes any sense ;-)
> 
> They don't (I know because I have been teaching Forth beginners for
> three decades).  That's because negative dividends are rare, and
> negative divisors are even rarer.  But in those cases where negative
> dividends occur, floored division usually makes sense, and users
> encountering it don't ask.

In a teaching scenario I wouldn't necessarily expect questions either.
Importantly it didn't make sense to forth vendors to make breaking
changes for something that was occasionally useful.

>> ANS at least tells you 2* 2/ are bit-shifters with historic, albeit misleading,
>> names.
> 
> The name of 2* is not misleading on architectures with 2s-complement
> arithmetic.  I.e., every architecture designed in the last
> half-century (the IBM S/360 is actually 62 years old), and everything
> that any existing standard system (for any Forth standard) runs on.

And it's on such machines that one finds symmetric hardware division
co-existing with arithmetic right shift instructions and coders not
getting freaked out by it.

> ...

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

#135101 — Teaching Scenarios [Re: Forth for a balanced ternary machine]

On 5/26/2026 12:46 AM, Anton Ertl wrote:
> ... I have been teaching Forth beginners for three decades. ... 

Does your university offer a class on Forth?

https://dl.acm.org/doi/pdf/10.1145/165628.165632
https://www.cs.uaf.edu/~chappell/class/2023_spr/cs331/read/forth_quick.html

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

#135103 — Re: Teaching Scenarios [Re: Forth for a balanced ternary machine]

On 27/05/2026 1:52 am, Buzz McCool wrote:
> On 5/26/2026 12:46 AM, Anton Ertl wrote:
>> ... I have been teaching Forth beginners for three decades. ... 
> 
> Does your university offer a class on Forth?
> 
> https://dl.acm.org/doi/pdf/10.1145/165628.165632
> https://www.cs.uaf.edu/~chappell/class/2023_spr/cs331/read/forth_quick.html
> 

Forth is like 60's music.  You had to be there.

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

#135109 — Re: Teaching Scenarios [Re: Forth for a balanced ternary machine]

Buzz McCool <buzz_mccool@yahoo.com> writes:
>On 5/26/2026 12:46 AM, Anton Ertl wrote:
>> ... I have been teaching Forth beginners for three decades. ... 
>
>Does your university offer a class on Forth?

I have had a course "Stack-based languages" from the late 1990s to
2024.  I taught Forth and Postscript.  Students did projects in Forth
or Postscript.  In recent years it has had few students and most of
them did projects in Forth.

We were tasked with changing the courses to 6 ECTS (credits);
Stack-based Languages had 3 ECTS.  I decided to replace Stack-based
Languages with a new course "Low-Level Languages", where I teach Forth
and Rust to students.  I did this course the first time last semester.
This course attracted a lot more students.  The students surprised me
by often using neither language for the project, but instead, e.g.,
C++ (which is also acceptable).

>https://www.cs.uaf.edu/~chappell/class/2023_spr/cs331/read/forth_quick.html

Looking at <https://www.cs.uaf.edu/~chappell/class/2026_spr/cs331/>,
the course covers several programming languages (which explains the
shortness of the introduction), but in 2026 the course no longer
includes Forth.  Anyway, good to see that in 2023 there was at least
one other course that taught Forth, and that course used Gforth.

- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/

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

#135113 — Re: Teaching Scenarios [Re: Forth for a balanced ternary machine]

Am 30.05.2026 um 22:16 schrieb Anton Ertl:
> Buzz McCool <buzz_mccool@yahoo.com> writes:
>> On 5/26/2026 12:46 AM, Anton Ertl wrote:
>>> ... I have been teaching Forth beginners for three decades. ...
>>
>> Does your university offer a class on Forth?
> 
> I have had a course "Stack-based languages" from the late 1990s to
> 2024.  I taught Forth and Postscript.  Students did projects in Forth
> or Postscript.  In recent years it has had few students and most of
> them did projects in Forth.
> 
> We were tasked with changing the courses to 6 ECTS (credits);
> Stack-based Languages had 3 ECTS.  I decided to replace Stack-based
> Languages with a new course "Low-Level Languages", where I teach Forth
> and Rust to students.  I did this course the first time last semester.
> This course attracted a lot more students.  The students surprised me
> by often using neither language for the project, but instead, e.g.,
> C++ (which is also acceptable).
> 
>> https://www.cs.uaf.edu/~chappell/class/2023_spr/cs331/read/forth_quick.html
> 
> Looking at <https://www.cs.uaf.edu/~chappell/class/2026_spr/cs331/>,
> the course covers several programming languages (which explains the
> shortness of the introduction), but in 2026 the course no longer
> includes Forth.  Anyway, good to see that in 2023 there was at least
> one other course that taught Forth, and that course used Gforth.
> 
We are living in the times of agentic software management using LLMs.
Nevertheless I am surprised to read that Rust and C++ have become
low-level languages. Times are achanging....

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

#135114 — Re: Teaching Scenarios [Re: Forth for a balanced ternary machine]

minforth <minforth@gmx.net> writes:
>Nevertheless I am surprised to read that Rust and C++ have become
>low-level languages.

It is, according to my definition, where a high-level language
requires automatic storage reclamation.  Now you can say that Rust has
no explicit storage reclamation, but Rust requires programmers to
organize their programs with at least as much thought given to storage
reclamation as any of the languages with explicit storage reclamation.
E.g., in Forth I can decide not to worry about FREEing ALLOCATEd
memory, because the resulting memory leakage is acceptable (and that's
what I did for Gray), but I cannot do that in (safe) Rust.

- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/

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

#135108 — Division (was: Forth for a balanced ternary machine)

dxf <dxforth@gmail.com> writes:
>Importantly it didn't make sense to forth vendors to make breaking
>changes for something that was occasionally useful.

Experience: Gforth used to do for /, MOD, and a number of other
division words what the C compiler does, i.e., symmetric division,
before Gforth 0.7.  After a discussion Bernd Paysan switched these
words to floored division for Gforth 0.7.  I was not particularly
happy, because I worried about "breaking changes".  However, we got 0
complaints about this change, which indicates that these words are not
used with operands with different signs, at least not where the
remainder is different from 0, or that the users are not particularly
picky about the result in those cases.

Anyway, in development Gforth you can now choose for every word
explicitly, with /S or /F.  / is a synonym of /F, but if somebody is
really into symmetric division, they can define

SYNONYM / /S

and likewise for the other words.

>And it's on such machines that one finds symmetric hardware division
>co-existing with arithmetic right shift instructions and coders not
>getting freaked out by it.

If all you ever divide are positive numbers, you don't notice the
difference.

- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/

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

#135111 — Re: Division

On 31/05/2026 4:23 am, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> Importantly it didn't make sense to forth vendors to make breaking
>> changes for something that was occasionally useful.
> 
> Experience: Gforth used to do for /, MOD, and a number of other
> division words what the C compiler does, i.e., symmetric division,
> before Gforth 0.7.  After a discussion Bernd Paysan switched these
> words to floored division for Gforth 0.7.  I was not particularly
> happy, because I worried about "breaking changes".  However, we got 0
> complaints about this change, which indicates that these words are not
> used with operands with different signs, at least not where the
> remainder is different from 0, or that the users are not particularly
> picky about the result in those cases.
> 
> Anyway, in development Gforth you can now choose for every word
> explicitly, with /S or /F.  / is a synonym of /F, but if somebody is
> really into symmetric division, they can define
> 
> SYNONYM / /S
> 
> and likewise for the other words.

As a non-vendor with no paying customers, no warranty, no obligations,
I too feel I can make changes without expecting much, if any, flack.

I don't envy the vendors who saw following a standard as a commercial
selling point; who then found themselves sold out by a TC that felt it
could do as it pleased.  To be fair, not all TC members ratified the
83-standard with some voting against.  Those were the days...

>> And it's on such machines that one finds symmetric hardware division
>> co-existing with arithmetic right shift instructions and coders not
>> getting freaked out by it.
> 
> If all you ever divide are positive numbers, you don't notice the
> difference.

Plainly it wasn't the case then or now.  Only reason to support an ASR
instruction is division of negative numbers.

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

#135115 — Re: Division

dxf <dxforth@gmail.com> writes:
>As a non-vendor with no paying customers, no warranty, no obligations,
>I too feel I can make changes without expecting much, if any, flack.

We do get feedback on some changes in Gforth.  In the case of the
switch to floored division, we did not.  We were prepared for a quick
fix by having symmetric division as a configuration option.  Maybe the
people who prefer symmetric division rebuilt Gforth with that option,
but my impression is that most Gforth users use a binary package, and
do not rebuild Gforth from source.

- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/

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

#135119 — Re: Division

On 1/06/2026 12:20 am, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> As a non-vendor with no paying customers, no warranty, no obligations,
>> I too feel I can make changes without expecting much, if any, flack.
> 
> We do get feedback on some changes in Gforth.  In the case of the
> switch to floored division, we did not.  We were prepared for a quick
> fix by having symmetric division as a configuration option.  Maybe the
> people who prefer symmetric division rebuilt Gforth with that option,
> but my impression is that most Gforth users use a binary package, and
> do not rebuild Gforth from source.

ISTM vendors saw ANS-Forth as a new era and took the opportunity to return
to symmetric.  This in contrast to a TC that was bending over backwards to
allow vendors to retain what they previously had.

DX-Forth followed a similar trajectory beginning as a Forth-83 system
with floored division in the early 90's.  By 1997 I had dropped CP/M and
potentially forth too.  I flirted with Pascal and Delphi but quickly
realized such things were no longer for me.  I missed the joy and
frustration of developing my own tools.  DX-Forth was ported to DOS in
early 2000's.  Most Intel based forths were by then symmetric and it
was simpler.  The choice was clear.  When a decade later DX-Forth for
CP/M was dusted off and brought up to spec, it was made symmetric too.
There was never any regret.  Indeed it was relief.  In hindsight floored
looked like a cult that had lost its following.  In 83 I had drunk the
kool-aid along with everyone else...

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

#135116 — arithmetic shift right (was: Division)

dxf <dxforth@gmail.com> writes:
>Only reason to support an ASR
>instruction is division of negative numbers.

Another common use is sign extension in cases where no more
specialized sign-extension instruction exists; e.g., if you want to
sign-extend an 11-bit field.

- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/

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

#135120 — Re: arithmetic shift right

On 1/06/2026 12:43 am, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> Only reason to support an ASR
>> instruction is division of negative numbers.
> 
> Another common use is sign extension in cases where no more
> specialized sign-extension instruction exists; e.g., if you want to
> sign-extend an 11-bit field.

Interesting.  Of the classic 8-bit micros I believe only the 6800 had
an ASR instruction and that 1 bit at a time.  Sign extension on those
would have required some effort.  In the Forth-79 Reference Word Set
(Kitt Peak Forth stuff that didn't make it in?) there is:

  ASHIFT         n1 n2 -- n3

  Shift  the  value  n1 arithmetically n2 bits left  if  n2  is
  positive,  shifting  zeros  into  the  least-significant   bit
  positions.   If  n2 is negative, n1 is  shifted  right.   Sign
  extension is to be consistent with the processor's  arithmetic
  shift.

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

#135122

On 26-05-2026 07:53, dxf wrote:
 > ANS at least tells you 2* 2/ are bit-shifters with historic, albeit 
misleading,
 > names.
You know I'm a pragmatic guy. Back in the 32 bit era, I tested every 
single value with both 2* and "2 *" - no difference. So, 2* essentially 
became "2 *".

Very different story with 2/. So, there is a unique opcode 2/ in 4tH - 
but not a true 2*. ;-)

Hans Bezemer

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

#135124

On 2/06/2026 7:23 am, Hans Bezemer wrote:
> On 26-05-2026 07:53, dxf wrote:
>> ANS at least tells you 2* 2/ are bit-shifters with historic, albeit misleading,
>> names.
> You know I'm a pragmatic guy. Back in the 32 bit era, I tested every single value with both 2* and "2 *" - no difference. So, 2* essentially became "2 *".
> 
> Very different story with 2/. So, there is a unique opcode 2/ in 4tH - but not a true 2*. ;-)

In eForth one finds:

  : 2*  2 * ;
  : 2/  2 / ;

which rather defeats the purpose of the functions which is speed.
As to what is returned by a bit-shifting 2/ depends on the hardware.
For 2's complement it's floored.  For 1's complement it's symmetric.
For signed-magnitude it's ...

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

#135125

On 03-06-2026 05:30, dxf wrote:
> On 2/06/2026 7:23 am, Hans Bezemer wrote:
>> On 26-05-2026 07:53, dxf wrote:
>>> ANS at least tells you 2* 2/ are bit-shifters with historic, albeit misleading,
>>> names.
>> You know I'm a pragmatic guy. Back in the 32 bit era, I tested every single value with both 2* and "2 *" - no difference. So, 2* essentially became "2 *".
>>
>> Very different story with 2/. So, there is a unique opcode 2/ in 4tH - but not a true 2*. ;-)
> 
> In eForth one finds:
> 
>    : 2*  2 * ;
>    : 2/  2 / ;
> 
> which rather defeats the purpose of the functions which is speed.
> As to what is returned by a bit-shifting 2/ depends on the hardware.
> For 2's complement it's floored.  For 1's complement it's symmetric.
> For signed-magnitude it's ...
> 

True. "2 /" is twice as slow. I needed about a billion iterations to 
reliably measure that.

Small detail - first I thought "2 /" was faster. That was because the 
optimizer was able to fold the value and consequently create a constant.

Sooo -- in some cases "2 /" will actually be faster (in 4tH) because of 
that. Given that you will need millions of iterations to get *any* 
measurable benefit of 2/ and 2* I think I made the right trade-off.

The more since hardware 1's complement and signed-magnitude are so rare 
(as integer system) that I can safely ignore them. I've long given up 
catering for such systems.

And - the reason for this all - tokens are a precious resource in 4tH. 
I'd rather use it for something else.

Hans Bezemer

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

#135127

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>True. "2 /" is twice as slow.

That depends very much on the actual CPU.  E.g., Skylake (up to Coffee
Lake Refresh in 2020) is much slower at division than period AMD
processors and Skylakes successors.

Anyway, Zen4 is not particularly slow at integer division.  Let's se
how it fares for:

lxf ": foo 10000000 0 do 99999999 + 2 / 2 / 2 / 2 / 2 / 2 / 2 / 2 / 2 / 2 / loop ;
lxf ": foo 10000000 0 do 99999999 + 2/ 2/ 2/ 2/ 2/ 2/ 2/ 2/ 2/ 2/ loop ; 1 foo drop bye"

cycles per "2 /" or per "2/":
10.9  2 /
 1.1  2/

So 2/ is roughly 10 times faster than 2 /.  Note that division costs
around 10 cycles on Zen4.  IIRC the number on Skylake is 26 cycles or
so (and more if the dividend does not fit in 64 bits).

>Small detail - first I thought "2 /" was faster. That was because the 
>optimizer was able to fold the value and consequently create a constant.

And why does it not do that for "2/"?

In Gforth:

: foo -5 2/ . -5 2 / . ;

SEE FOO shows:

: foo  
  #-3 . #-3 . ;

Gforth also performs the following optimization (based on Matthias
Koch's constant stack that was originally only used for constant
folding):

Given

: bar 2 / ;

SEE BAR shows:

: bar  
  #1 arshift ;

Yes, it would be even cooler to generate 2/ in this case.  Maybe in
the future.

>And - the reason for this all - tokens are a precious resource in 4tH. 
>I'd rather use it for something else.

What are tokens in 4tH, and why are they a precious resource?

- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web