Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Extended version of ESP32forth v 7.0.7.5

226 views
Skip to first unread message

Marc Petremann

unread,
Jan 10, 2023, 4:50:47 AM1/10/23
to
Hello,
Check out my ESP32forth 7.0.7.5 extended version.
This version includes:
- SPI port command
- management of "STRING"s
- Improved DUMP
Link: https://esp32.arduino-forth.com/article/extendedESP32forth

dxforth

unread,
Jan 10, 2023, 6:09:02 AM1/10/23
to
Improved BETWEEN

: BETWEEN ( n1|u1 n2|u2 n3|u3 -- flag ) OVER - -ROT - U< 0= ;

none albert

unread,
Jan 10, 2023, 6:33:37 AM1/10/23
to
That is related to my post on comparision of times.
You will find that
MIN-INT MAX-INT whatever
don't leaves true most of the time, as you might expect.
The mixing of signed numbers and unsigned numbers has to be left
to special occasions, (things that wrap around as hands on a clock).

This is best
: BETWEEN ( n1 n2 n3 -- flag ) >R R@ < SWAP R> >= AND ;
Don't cater for unsigned numbers.

Use those only for masks or in the unlikely
case your memory extend beyond 0x7FFF,FFFF,FFFF,FFFF
and you have to compare negative and positive memory addresses.

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 -

dxforth

unread,
Jan 10, 2023, 7:12:18 PM1/10/23
to
On 10/01/2023 10:33 pm, albert wrote:
> In article <tpjh0b$vlr$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>> On 10/01/2023 8:50 pm, Marc Petremann wrote:
>>> Hello,
>>> Check out my ESP32forth 7.0.7.5 extended version.
>>> This version includes:
>>> - SPI port command
>>> - management of "STRING"s
>>> - Improved DUMP
>>> Link: https://esp32.arduino-forth.com/article/extendedESP32forth
>>
>> Improved BETWEEN
>>
>> : BETWEEN ( n1|u1 n2|u2 n3|u3 -- flag ) OVER - -ROT - U< 0= ;
>>
>
> That is related to my post on comparision of times.
> You will find that
> MIN-INT MAX-INT whatever
> don't leaves true most of the time, as you might expect.
> The mixing of signed numbers and unsigned numbers has to be left
> to special occasions, (things that wrap around as hands on a clock).
>
> This is best
> : BETWEEN ( n1 n2 n3 -- flag ) >R R@ < SWAP R> >= AND ;
> Don't cater for unsigned numbers.

It's no BETWEEN I'm familiar with under that name. It tests:

n2 < n3 <= n1

corresponding to the stack diagram:

( hi lo n -- flag )

5 -5 0 between . -1 ok
5 -5 -5 between . 0 ok
5 -5 5 between . -1 ok



Zbig

unread,
Jan 10, 2023, 7:31:55 PM1/10/23
to
> It's no BETWEEN I'm familiar with under that name. It tests:
>
> n2 < n3 <= n1
>
> corresponding to the stack diagram:
>
> ( hi lo n -- flag )
>
> 5 -5 0 between . -1 ok
> 5 -5 -5 between . 0 ok
> 5 -5 5 between . -1 ok

Looks rather good to me. If one looks at number line, zero indeed has its place between -5 and 5.

dxforth

unread,
Jan 10, 2023, 8:19:02 PM1/10/23
to
Historically definitions of BETWEEN have included both limits e.g. A-Z

Zbig

unread,
Jan 10, 2023, 8:39:16 PM1/10/23
to
> Historically definitions of BETWEEN have included both limits e.g. A-Z

Oh, so just there's a need to replace '<' by '<=' in Albert's definition.

dxforth

unread,
Jan 10, 2023, 9:46:41 PM1/10/23
to
On 11/01/2023 12:39 pm, Zbig wrote:
>> Historically definitions of BETWEEN have included both limits e.g. A-Z
>
> Oh, so just there's a need to replace '<' by '<=' in Albert's definition.

Why use a definition that's longer and doesn't handle unsigned?

Jach Feng

unread,
Jan 10, 2023, 10:01:16 PM1/10/23
to
dxforth 在 2023年1月11日 星期三上午9:19:02 [UTC+8] 的信中寫道:
It's a much reasonable decision of this historical definition of BETWEEN to avoid the following ridiculous result which makes laugh of other programming languages.

-5 5 5 between . 0 ok

dxforth

unread,
Jan 11, 2023, 1:52:28 AM1/11/23
to
On 11/01/2023 2:01 pm, Jach Feng wrote:
> dxforth 在 2023年1月11日 星期三上午9:19:02 [UTC+8] 的信中寫道:
>> Historically definitions of BETWEEN have included both limits e.g. A-Z
> It's a much reasonable decision of this historical definition of BETWEEN to avoid the following ridiculous result which makes laugh of other programming languages.
>
> -5 5 5 between . 0 ok

Admittedly it isn't expected and where 1+ WITHIN would have been better.
I had BETWEEN in my kernel in addition to WITHIN but I may now reconsider
that. Thanks.


dxforth

unread,
Jan 11, 2023, 3:15:08 AM1/11/23
to
Ignore my response above. Assuming parameter order ( n lo hi ) -5 does
not lie within the range 5 to 5 and therefore returns false.

>> 5 -5 5 between . -1 ok

That too is correct.

Jach Feng

unread,
Jan 11, 2023, 3:59:54 AM1/11/23
to
dxforth 在 2023年1月11日 星期三下午4:15:08 [UTC+8] 的信中寫道:
Sure, they are both correct. But the problem is not the result, the problem is the definition of the BETWEEN.

none albert

unread,
Jan 11, 2023, 4:53:27 AM1/11/23
to
Because it is easier to understand.
And because we must exterminate the incessant use of unsigned of
the 16 bit era. If you want more than 32 kbyte of memory switch to
a bigger processor.

dxforth

unread,
Jan 11, 2023, 5:00:43 AM1/11/23
to
Can you be more specific?

dxforth

unread,
Jan 11, 2023, 5:10:56 AM1/11/23
to
On 11/01/2023 8:53 pm, albert wrote:
> In article <tpl7ue$vka$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>> On 11/01/2023 12:39 pm, Zbig wrote:
>>>> Historically definitions of BETWEEN have included both limits e.g. A-Z
>>>
>>> Oh, so just there's a need to replace '<' by '<=' in Albert's definition.
>>
>> Why use a definition that's longer and doesn't handle unsigned?
>
> Because it is easier to understand.
> And because we must exterminate the incessant use of unsigned of
> the 16 bit era. If you want more than 32 kbyte of memory switch to
> a bigger processor.

I'm too lazy to use the correct cpu instruction so I should shift to
a bigger cpu?


Zbig

unread,
Jan 11, 2023, 6:02:09 AM1/11/23
to
> And because we must exterminate the incessant use of unsigned of
> the 16 bit era. If you want more than 32 kbyte of memory switch to
> a bigger processor.

But even on that bigger processor unsigned can be used to handle even
larger numbers. Although personally I don't feel (at least at the moment)
any particular need to use unsigned on 64-bit — still maybe it can be useful
for specific purposes (some astronomical calculations etc.)?
Is it good idea to get rid of unsigned „just like that”, totally?

dxforth

unread,
Jan 11, 2023, 6:49:21 PM1/11/23
to
I'll take objectors seriously when they get rid of WITHIN.

none albert

unread,
Jan 12, 2023, 4:19:16 AM1/12/23
to
In article <16764445-4c34-4643...@googlegroups.com>,
The difference between 63 and 64 bit of precision is astronomically low,
if that is what you mean.

Zbig

unread,
Jan 12, 2023, 5:24:55 AM1/12/23
to
> The difference between 63 and 64 bit of precision is astronomically low,
> if that is what you mean.

It's actually still the same, as between 15 and
16 bit of precision: ~100% of the range.

Heinrich Hohl

unread,
Jan 12, 2023, 6:26:34 AM1/12/23
to
On Wednesday, January 11, 2023 at 10:53:27 AM UTC+1, none albert wrote:
> And because we must exterminate the incessant use of unsigned of
> the 16 bit era. If you want more than 32 kbyte of memory switch to
> a bigger processor.
> Groetjes Albert

Even in the 64 bit era, unsigned numbers are still required.

Unsigned numbers offer twice the range in case a sign bit is not required.
But this is not the only reason why we need them.

The other reason is math and algorithms. There are algorithms that only work
with unsigned numbers, e.g. pseudo random number generators. We will always
need unsigned multiplication and division for certain algorithms, no matter how
large the word size is.

Henry

none albert

unread,
Jan 12, 2023, 6:36:59 AM1/12/23
to
In article <8fc349ed-3924-4cb5...@googlegroups.com>,
Precision is logaritmic. It was 0.03% to begin with,
now it is astronomically low.
I cannot be bother to calculate it.

none albert

unread,
Jan 12, 2023, 6:39:56 AM1/12/23
to
In article <4a429d24-89c6-4489...@googlegroups.com>,
It is good to realize that most unsigned numbers are not numbers but bitmaps.
Only in a rare case, multiple precisions arithmetic, you need them.

>
>Henry

Zbig

unread,
Jan 12, 2023, 6:50:02 AM1/12/23
to
> Precision is logaritmic. It was 0.03% to begin with,
> now it is astronomically low.
> I cannot be bother to calculate it.

Indeed I confused precision with range.

You wrote: „we must exterminate the incessant use of unsigned”.
Actually why we have to do that? What makes us do it?

dxforth

unread,
Jan 13, 2023, 6:31:02 AM1/13/23
to
On 12/01/2023 10:49 am, dxforth wrote:
> ...
> I'll take objectors seriously when they get rid of WITHIN.

Speaking of which ...

WITHIN may be used to create BETWEEN. The temptation is to write:

: BETWEEN 1+ WITHIN ;

and some implementations do that e.g. Win32Forth. But the proper way is:

: BETWEEN 1+ SWAP WITHIN 0= ;

which has the same characteristics as the implementation I posted earlier.

The formal definition is:

BETWEEN

( n1|u1 n2|u2 n3|u3 -- flag )

Perform a comparison of a test value n1|u1 with a lower limit n2|u2 and an upper
limit n3|u3, returning true if either (n2|u2 <= n3|u3 and (n2|u2 <= n1|u1 and
n1|u1 <= n3|u3)) or (n2|u2 > n3|u3 and (n2|u2 < n1|u1 or n1|u1 < n3|u3)) is true,
returning false otherwise. An ambiguous condition exists if n1|u1, n2|u2, and
n3|u3 are not all the same type.

The rationale follows that of A.6.2.2440 WITHIN with the difference the limits are
inclusive. If n2|u2 and n3|u3 are reversed, then the limits become exclusive.

If Forth is about getting more bang for your buck, then these two functions have that.

none albert

unread,
Jan 13, 2023, 7:32:33 AM1/13/23
to
You call that "two for the price of one".
I call that "confusion, to the point of unusable".

none albert

unread,
Jan 13, 2023, 7:59:17 AM1/13/23
to
In article <c1877a10-dc20-4070...@googlegroups.com>,
I forgive Willem Ouwerkerk who is working with 16 bit embedded micro's.

Who is working on a 64 bit system, can use normal integers.
It is bad to have a definition like TYPE (adr u -- ).
Really? Print more that 100 gazillion characters in one go?
Make an implementation of TYPE portable:
: TYPE DUP 0< ABORT" Have you tried walking to China too, on foot?"
.... ;

Make a distinction between mask and integers.
shifting works on masks, inverting works on mask.
It has been pointed out that multiple precision is the one exception
that really need unsigned numbers.

dxforth

unread,
Jan 13, 2023, 8:22:23 PM1/13/23
to
I make no apology for providing a full definition of what BETWEEN does. It's
what I would like to see were I a user.

Zbig

unread,
Jan 13, 2023, 8:53:59 PM1/13/23
to
> Who is working on a 64 bit system, can use normal integers.
> It is bad to have a definition like TYPE (adr u -- ).
> Really? Print more that 100 gazillion characters in one go?
> Make an implementation of TYPE portable:
> : TYPE DUP 0< ABORT" Have you tried walking to China too, on foot?"
> .... ;

You mean printing „only” 50 gazillion characters in one go makes any
practical difference?

> Make a distinction between mask and integers.
> shifting works on masks, inverting works on mask.
> It has been pointed out that multiple precision is the one exception
> that really need unsigned numbers.

In Forth that distinction is a matter of interpretation.

dxforth

unread,
Jan 14, 2023, 8:25:04 PM1/14/23
to
On 14/01/2023 12:53 pm, Zbig wrote:
>> Who is working on a 64 bit system, can use normal integers.
>> It is bad to have a definition like TYPE (adr u -- ).
>> Really? Print more that 100 gazillion characters in one go?
>> Make an implementation of TYPE portable:
>> : TYPE DUP 0< ABORT" Have you tried walking to China too, on foot?"
>> .... ;

Forth-79/83 TYPE uses a signed count and prints nothing in the case of 0< .
Presumably this was to handle computed counts - rather than '+n should be
enough for anyone'.

> You mean printing „only” 50 gazillion characters in one go makes any
> practical difference?
>
>> Make a distinction between mask and integers.
>> shifting works on masks, inverting works on mask.
>> It has been pointed out that multiple precision is the one exception
>> that really need unsigned numbers.
>
> In Forth that distinction is a matter of interpretation.

When I see forth code in which addresses are compared using signed operators
it raises a red flag.

none albert

unread,
Jan 15, 2023, 5:59:53 AM1/15/23
to
Me too. In the circumstance that I sit on a 16 bit Forth where the memory is
fully occupied and I'm using a largish arrays.
On all other cases I'll rather keep my red flags dry for if it really matters.

dxforth

unread,
Jan 15, 2023, 7:37:30 AM1/15/23
to
On 15/01/2023 9:59 pm, albert wrote:
> In article <tpvkld$1r7m$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>> On 14/01/2023 12:53 pm, Zbig wrote:
>>>> Who is working on a 64 bit system, can use normal integers.
>>>> It is bad to have a definition like TYPE (adr u -- ).
>>>> Really? Print more that 100 gazillion characters in one go?
>>>> Make an implementation of TYPE portable:
>>>> : TYPE DUP 0< ABORT" Have you tried walking to China too, on foot?"
>>>> .... ;
>>
>> Forth-79/83 TYPE uses a signed count and prints nothing in the case of 0< .
>> Presumably this was to handle computed counts - rather than '+n should be
>> enough for anyone'.
>>
>>> You mean printing „only” 50 gazillion characters in one go makes any
>>> practical difference?
>>>
>>>> Make a distinction between mask and integers.
>>>> shifting works on masks, inverting works on mask.
>>>> It has been pointed out that multiple precision is the one exception
>>>> that really need unsigned numbers.
>>>
>>> In Forth that distinction is a matter of interpretation.
>>
>> When I see forth code in which addresses are compared using signed operators
>> it raises a red flag.
>>
>
> Me too. In the circumstance that I sit on a 16 bit Forth where the memory is
> fully occupied and I'm using a largish arrays.
> On all other cases I'll rather keep my red flags dry for if it really matters.

Unsigned numbers and operators didn't vanish when 32-bit systems arrived. All
other things being equal, it means there's a right operator to use and a wrong
operator.

0 new messages