From Newsgroup: comp.lang.forth


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

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Matthias Koch <[email protected]> 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/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 26/05/2026 4:10 am, Anton Ertl wrote:

Matthias Koch <[email protected]> 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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <[email protected]> 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/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 26/05/2026 5:46 pm, Anton Ertl wrote:

dxf <[email protected]> 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.

...

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Thank you for the insight into the symmetric vs. floored decision!

I changed my documentation accordingly:

In balanced ternary, a right shift is the same as symmetric division
by powers of three, whereas in two-complement binary an arithmetic
right shift is equivalent to floored division by powers of two.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <[email protected]> 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/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Buzz McCool <[email protected]> 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/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 31/05/2026 4:23 am, Anton Ertl wrote:

dxf <[email protected]> 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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Am 30.05.2026 um 22:16 schrieb Anton Ertl:

Buzz McCool <[email protected]> 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....
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

minforth <[email protected]> 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/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <[email protected]> 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/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <[email protected]> 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/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 1/06/2026 12:20 am, Anton Ertl wrote:

dxf <[email protected]> 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...

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 1/06/2026 12:43 am, Anton Ertl wrote:

dxf <[email protected]> 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.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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 ...

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <[email protected]> writes:

On 2/06/2026 7:23 am, Hans Bezemer wrote:
In eForth one finds:

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

which rather defeats the purpose of the functions which is speed.

But eForth's purpose is not 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 ...

For sign-magnitude an arithmetic interpretation is that, for positive
numbers, it's division by 2, while for negative numbers, it's the
average between the number and -2^(n-1) (where n is the number of bits
in a cell). It's not very useful for sign-magnitude, but given that sign-magnitude and ones-complement have died out long ago and never
had Forth systems, who cares.

- 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/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Hans Bezemer <[email protected]> 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/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 4/06/2026 10:08 pm, Anton Ertl wrote:

dxf <[email protected]> writes:

On 2/06/2026 7:23 am, Hans Bezemer wrote:
In eForth one finds:

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

which rather defeats the purpose of the functions which is speed.

But eForth's purpose is not speed.

Wondering if there was a rationale for eForth, I found this from Bill
Muench's old webpage:

"I wrote eForth so that it would be easier for me to develop Forth
systems for many processors. Processors included 56000, 6502, 68332,
68HC11, 8051, 8080, 80C166, 80C196, 80x86, RTX2000, RTX2001, RTX2010,
SC32, StrongARM, TMS320, Z80, and I may have forgotten some.

eForth allows me to make a complete Forth system with about 30 very
simple machine code routines. With so few words to code, I could do
the coding by hand, that is, without the need to write an assembler
first. After this simple model is running, it is desirable to code
much of the rest in assembly."

That "30" figure perhaps explains why 1+ 1- 2+ 2- 2* 2/ were excluded
from the kernel and provided as high-level definitions. The idea being
users would eventually 'code' them.

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 ...

For sign-magnitude an arithmetic interpretation is that, for positive numbers, it's division by 2, while for negative numbers, it's the
average between the number and -2^(n-1) (where n is the number of bits
in a cell). It's not very useful for sign-magnitude, but given that sign-magnitude and ones-complement have died out long ago and never
had Forth systems, who cares.

Thanks. Not dead enough for Forth-94 which was the first standard to
expressly mention and support them. For that reason I was curious what
2/ would do on these. As the effect does vary, I would expect '94 to
have documented it. But then the same happened with other words.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <[email protected]> writes:

On 4/06/2026 10:08 pm, Anton Ertl wrote:

[On 2/:]

It's not very useful for sign-magnitude, but given that
sign-magnitude and ones-complement have died out long ago and never
had Forth systems, who cares.

Thanks. Not dead enough for Forth-94 which was the first standard to >expressly mention and support them.

I think that's a reaction to the fact that Forth-83 limited itself to
16-bit cells and 8-bit chars. They wanted to lift those limitations,
and while they were at it, they apparently also wanted to eliminate
the limitation to 2s-complement representation of negative numbers.
Of these three, their cell size answer turned out to be right on spot,
while the char size answer turned out to be the wrong one (but it's in
the same spirit as the Windows NT (1993) and Java (1995) answers to
the same issue, so it's excusable that they did not see the right
answer in 1994. OTOH, the X/Open committee XoJIG, Dave Prosser and
Ken Thompson saw in 1992 that this answer was not the right one, and
designed UTF-8 in 1992.)

As for sign-magnitude and ones-complement, these are basically
remnants from the 1950s and 1960s, and I am not aware of a new
sign-magnitude or ones-complement architecture designed after the
1960s, except for followons to machines from the 1950s and 1960s.
These machines were in decline by the 1970s and the decline had
progressed pretty far by the time Forth-94 was developed.

Forth-94 gives lip service to these other representations, but does
not support them properly, especially not in a backwards-compatible
way. E.g., with ones complement code that uses 0= on the results of comparisons (a common-usage way to negate the result) would not work
as intended.

And the treatment of 2/ is similar:

For that reason I was curious what
2/ would do on these. As the effect does vary, I would expect '94 to
have documented it.

The effect of 2/ on the bits is documented. Given the different
results when applied to negative numbers, the use as arithmetic
operation on negative numbers is obviously not Forth-94 conforming.

All this is fixed by standardizing 2s-complent (already accepted into
the upcoming standard).

- 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/
--- Synchronet 3.22a-Linux NewsLink 1.2