In
----------------------
\ Arithmetic on big signed-magnitude numbers.

\ Forth Scientific Library Algorithm #47

\ Copyright 1996 by Leonard Francis Zettel, Jr.
\ Released to the Forth Scientific Library. -------------------------------------

I see the following code:

-------------------------------
CREATE MAX-N CHAR M C, CHAR A C, CHAR X C, CHAR - C, CHAR N C,
\ Yes, this is clumsy, but it avoids making it necessary to specify
\ the use of S" from the File word set.

MAX-N 5 ENVIRONMENT? [IF] [ELSE] 32767 [THEN]

CONSTANT biggest \ Largest representable signed number -------------------------------

This relies on ENVIRONMENT? and defines clumsy auxiliary definitions.
In view of the requirement in ISO that the number be represented
in 2-complements that can be replaced by

-------------------------------
0 INVERT 1 RSHIFT CONSTANT biggest
-------------------------------

The advantage is if you are on a non-dancing, non-singing 64 bit
system that you don't have to throttle 48 bits from your
precision. No need to S" or ENVIRONMENT fully available.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make
spring. You must not say "hey" before you have crossed the bridge.
Don't sell the hide of the bear until you shot it. Better one bird in
the hand than ten in the air. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

albert@cherry.(none) (albert) writes:

In view of the requirement in ISO that the number be represented
in 2-complements

The proposal <http://www.forth200x.org/twos-complement.html> has been
accepted at the 2015 meeting. Neither Forth-94 (aka ANS Forth aka ISO
Forth) nor Forth-2012 have that requirement.

However, the FSL could declare an environmental restriction on having twos-complement signed numbers, and all standard systems known to me
satisfy the requirement (that's one reason why we eventually agreed on
the proposal above). By contrast, not all systems implement
ENVIRONMENT? in a useful way (I have not checked how well the MAX-N
query is supported by various systems, though).

- 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 2022: https://euro.theforth.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

none albert schrieb am Sonntag, 1. Januar 2023 um 15:04:15 UTC+1:

In
----------------------
\ Arithmetic on big signed-magnitude numbers.

\ Forth Scientific Library Algorithm #47

\ Copyright 1996 by Leonard Francis Zettel, Jr.
\ Released to the Forth Scientific Library. -------------------------------------

I see the following code:

-------------------------------
CREATE MAX-N CHAR M C, CHAR A C, CHAR X C, CHAR - C, CHAR N C,
\ Yes, this is clumsy, but it avoids making it necessary to specify
\ the use of S" from the File word set.

MAX-N 5 ENVIRONMENT? [IF] [ELSE] 32767 [THEN]

CONSTANT biggest \ Largest representable signed number -------------------------------

This relies on ENVIRONMENT? and defines clumsy auxiliary definitions.
In view of the requirement in ISO that the number be represented
in 2-complements that can be replaced by

-------------------------------
0 INVERT 1 RSHIFT CONSTANT biggest
-------------------------------

The advantage is if you are on a non-dancing, non-singing 64 bit
system that you don't have to throttle 48 bits from your
precision. No need to S" or ENVIRONMENT fully available.

Groetjes Albert

Looks like you're right. But I still wonder if this is universally true,
given the many possible combinations of pointer and integer sizes
between different CPUs, like eg LP64I32 LLP64 and what you have
(how about 16 or 8 bitters?)

AFAIU a Forth cell should match the pointer size, not the integer size.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/01/2023 5:52 am, minf...@arcor.de wrote:

Looks like you're right. But I still wonder if this is universally true, given the many possible combinations of pointer and integer sizes
between different CPUs, like eg LP64I32 LLP64 and what you have
(how about 16 or 8 bitters?)

AFAIU a Forth cell should match the pointer size, not the integer size.

ANS isn't universal. It specified its datatypes and if any system fell outside, it wasn't covered. 200x has become more conservative reducing
what ANS was prepared to support on the basis it was a burden to programmers.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"minf...@arcor.de" <minforth@arcor.de> writes:

Looks like you're right. But I still wonder if this is universally true, >given the many possible combinations of pointer and integer sizes
between different CPUs

Forth has no pointers and not separate integers. Forth has cells.

like eg LP64I32 LLP64 and what you have

These are terms from the C world: L for long, P for pointer, I for
int, LL for long long. They have nothing to do with "different CPUs"
and nothing to do with Forth.

(how about 16 or 8 bitters?)

What about them? On machines with 16-bit addresses cells are 16 bits
wide.

AFAIU a Forth cell should match the pointer size, not the integer size.

That makes no sense. A cell contains an address or a single-cell
integer, so obviously they are the same size in Forth.

- 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 2022: https://euro.theforth.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl schrieb am Montag, 2. Januar 2023 um 08:14:41 UTC+1:

"minf...@arcor.de" <minf...@arcor.de> writes:

Looks like you're right. But I still wonder if this is universally true, >given the many possible combinations of pointer and integer sizes
between different CPUs

Forth has no pointers and not separate integers. Forth has cells.

like eg LP64I32 LLP64 and what you have

These are terms from the C world: L for long, P for pointer, I for
int, LL for long long. They have nothing to do with "different CPUs"
and nothing to do with Forth.

(how about 16 or 8 bitters?)

What about them? On machines with 16-bit addresses cells are 16 bits
wide.

AFAIU a Forth cell should match the pointer size, not the integer size.

That makes no sense. A cell contains an address or a single-cell
integer, so obviously they are the same size in Forth.

Yes, of course, it is C lingo. But still, looking at some meanwhile archaic Intel
CPUs you had 16 bit registers but addresses calculated through an additional segment register. In DOS times there were Forths with different segments for different purposes like for code and for headers. IIRC FPC had even more.

The notion of a modern Forth cell does not really match the CPU there. So
0 INVERT 1 RSHIFT CONSTANT biggest
works different for numbers or addresses (if you shun the word pointers).

But of course Forth like C silently implies a certain machine abstraction, carried to the max if there is an underlying VM, where you work on an explicit and visual hardware abstraction layer.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <2023Jan2.080430@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

"minf...@arcor.de" <minforth@arcor.de> writes:

Looks like you're right. But I still wonder if this is universally true, >>given the many possible combinations of pointer and integer sizes
between different CPUs

Forth has no pointers and not separate integers. Forth has cells.

like eg LP64I32 LLP64 and what you have

These are terms from the C world: L for long, P for pointer, I for
int, LL for long long. They have nothing to do with "different CPUs"
and nothing to do with Forth.

(how about 16 or 8 bitters?)

What about them? On machines with 16-bit addresses cells are 16 bits
wide.

AFAIU a Forth cell should match the pointer size, not the integer size.

That makes no sense. A cell contains an address or a single-cell
integer, so obviously they are the same size in Forth.

I can imagine (implement) an i386 Forth with 64 bits cell size.
Addressing beyond 32 bits gives an error.
However this situation does not make an address a separate data type.

- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make
spring. You must not say "hey" before you have crossed the bridge.
Don't sell the hide of the bear until you shot it. Better one bird in
the hand than ten in the air. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <nnd$56f23731$6d61fd55@fff886c4d4684e06>,
none) (albert <albert@cherry.> wrote:

In
----------------------
\ Arithmetic on big signed-magnitude numbers.

\ Forth Scientific Library Algorithm #47

\ Copyright 1996 by Leonard Francis Zettel, Jr.
\ Released to the Forth Scientific Library. >-------------------------------------

I see the following code:

-------------------------------
CREATE MAX-N CHAR M C, CHAR A C, CHAR X C, CHAR - C, CHAR N C,
\ Yes, this is clumsy, but it avoids making it necessary to specify
\ the use of S" from the File word set.

MAX-N 5 ENVIRONMENT? [IF] [ELSE] 32767 [THEN]

CONSTANT biggest \ Largest representable signed number >-------------------------------

This relies on ENVIRONMENT? and defines clumsy auxiliary definitions.

In view of the requirement in ISO that the number be represented
in 2-complements that can be replaced by

I stand corrected.
As Anton Ertl pointed out in the ansi 93 document paragraph 3.2.1.1
it specifically states that other number representation are allowed.

So replace these line with

"
If you conform to 2015 standards, or are willing to declare an environmental dependancy on 2's complement you can replace this by
"

-------------------------------
0 INVERT 1 RSHIFT CONSTANT biggest
-------------------------------

The advantage is if you are on a non-dancing, non-singing 64 bit
system that you don't have to throttle 48 bits from your
precision. No need to S" or ENVIRONMENT fully available.

Loosing that much precision make the package portable
but not particularly attractive.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make
spring. You must not say "hey" before you have crossed the bridge.
Don't sell the hide of the bear until you shot it. Better one bird in
the hand than ten in the air. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <75355ecf-f38f-4e01-a49b-9dc9918b1441n@googlegroups.com>, minf...@arcor.de <minforth@arcor.de> wrote:

Anton Ertl schrieb am Montag, 2. Januar 2023 um 08:14:41 UTC+1:

<SNIP>

AFAIU a Forth cell should match the pointer size, not the integer size.

That makes no sense. A cell contains an address or a single-cell
integer, so obviously they are the same size in Forth.

Yes, of course, it is C lingo.

No it is not. It is the basic idea of computers that you control storages
that later is interpreted as executable code.

Bt still, looking at some meanwhile archaic Intel
CPUs you had 16 bit registers but addresses calculated through an additional >segment register. In DOS times there were Forths with different segments for >different purposes like for code and for headers. IIRC FPC had even more.

And is not DOS times. It is as recently as Pentium times.
That is Intel 386 architecture.
You could be running in a segment with 32 code and 16 bit data and vice versa. And then you have instruction-overrides to change code and data sizes separately, and must be in combination.
You can have 6 different segments where you have to keep track of those sizes. You can have overrides to use each of the different segments.
You must be aware of instructions that use the stack segment that may be of different size. (And 3 levels of privilege ...).
The segments could switch upon a far jump.
Also the extra segments could be loaded pointing to gods knows what.

You should thank AMD to define 64 bit architecture that does end this nightmare.

The notion of a modern Forth cell does not really match the CPU there. So
0 INVERT 1 RSHIFT CONSTANT biggest
works different for numbers or addresses (if you shun the word pointers).

You must be kidding. My code does one thing. It can be different for
you to influence however psychic you are.

But of course Forth like C silently implies a certain machine abstraction, >carried to the max if there is an underlying VM, where you work on an explicit >and visual hardware abstraction layer.

The basic machine abstraction is this.
Numbers can represent addresses.
You can store anything at addresses, what ever you choose to represent.
A particular interesting one is code. That instructs the computer to do
things, whatever is specified in the so called instruction sets.

That is universal, not C, not Forth.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make
spring. You must not say "hey" before you have crossed the bridge.
Don't sell the hide of the bear until you shot it. Better one bird in
the hand than ten in the air. - the Wise from Antrim -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"minf...@arcor.de" <minforth@arcor.de> writes:

Anton Ertl schrieb am Montag, 2. Januar 2023 um 08:14:41 UTC+1:

"minf...@arcor.de" <minf...@arcor.de> writes:

Looks like you're right. But I still wonder if this is universally true,
given the many possible combinations of pointer and integer sizes
between different CPUs

Forth has no pointers and not separate integers. Forth has cells.

like eg LP64I32 LLP64 and what you have

These are terms from the C world: L for long, P for pointer, I for
int, LL for long long. They have nothing to do with "different CPUs"
and nothing to do with Forth.

(how about 16 or 8 bitters?)

What about them? On machines with 16-bit addresses cells are 16 bits
wide.

AFAIU a Forth cell should match the pointer size, not the integer size.

That makes no sense. A cell contains an address or a single-cell
integer, so obviously they are the same size in Forth.

Yes, of course, it is C lingo. But still, looking at some meanwhile archaic Intel
CPUs you had 16 bit registers but addresses calculated through an additional >segment register. In DOS times there were Forths with different segments for >different purposes like for code and for headers. IIRC FPC had even more.

So what? F-PC has 16-bit cells, and as a result @, !, C@ and C! can
access 64KB. That the headers and the code are not in those 64KB and
have to be written using other words is a deviation from earlier Forth
systems, but not particularly burdensome for most applications. F-PC
also has @L !L etc. that allow to access beyond the 64KB data segment
(no idea how often that was used), and also words like Y@ for
accessing "Head" space. In F-PC NEST (aka DOCOL) pushes ES and "IP"
(I think it's not the IP register of the 8086, but a name of some
other register), i.e., two cells. Interestingly, EXECUTE is:

CODE EXECUTE ( cfa -- ) \ Execute the word whose CFA is on the stack.
POP AX JMP AX END-CODE

so a CFA (aka execution token) is one cell.

The F-PC experience had a strong influence on Forth-94: "name space"
for headers (an unfortunate name, because "name space" has a different
meaning in other programming languages), "code space" for code, "data
space" for stuff accessible with @; the return address became the
nest-sys, with implementation-dependent size. Forth-94 did not pick
up @L etc., however.

If you wanted a Forth system where @ and ! can access all memory, you
could write one with, e.g., 32-bit cells. I dimly remember discussing
such things in clf in the 1990s, but if anybody wrote such a system,
it never took off.

The notion of a modern Forth cell does not really match the CPU there. So
0 INVERT 1 RSHIFT CONSTANT biggest
works different for numbers or addresses (if you shun the word pointers).

First of all, the intention was to define MAX-N, the biggest signed
integer representable in a cell. On F-PC it gives you 32767 (if F-PC
has INVERT and RSHIFT).

I have no idea what you mean when you claim that it works different
for addresses.

- 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 2022: https://euro.theforth.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

albert@cherry.(none) (albert) writes:

In article <2023Jan2.080430@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

"minf...@arcor.de" <minforth@arcor.de> writes:

AFAIU a Forth cell should match the pointer size, not the integer size.

That makes no sense. A cell contains an address or a single-cell
integer, so obviously they are the same size in Forth.

I can imagine (implement) an i386 Forth with 64 bits cell size.
Addressing beyond 32 bits gives an error.
However this situation does not make an address a separate data type.

Sure one can imagine a Forth with a larger cell size than the natural
address size of the architecture on which it is implemented. The fact
that people have not actually implemented such systems, or if they
have, they have remained obscure, tells us that the benefits of this
idea don't outweigh the costs.

A more interesting scenario is Forth on a machine like the IBM 704,
the PDP-10, or the CDC 6600: The IBM 704 has 36-bit words and 15-bit
addresses, the PDP-10 36-bit words and 18-bit addresses, and the CDC
6600 has 60-bit words and 18-bit addresses. AFAIK they also did not
have 2s-complement operations for words (but for addresses).

But this style of machines has died out. AFAIK Forth was never ported
to such a machine when Forth was young and such machines still existed
(barely) outside museums, and in the unlikely case that anybody does
it now, I leave it to them to work out how they want to do it.

- 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 2022: https://euro.theforth.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)