On Friday, March 18, 2022 at 8:25:47 AM UTC+1, dxforth wrote:
> M/MOD ud1 u2 --- u3 ud4
> An unsigned mixed magnitude math operation which leaves a
> double quotient ud4 and remainder u3, from a double
> dividend ud1 and single divisor u2.
>
> Other names for it include MU/MOD (F83, F-PC). In all cases it was used
> to implement (not surprisingly) # .

I know it by the name of MU/MOD too - and in 4tH it is used to define
the double word version of # (like ESP32-Forth, 4tH's # is single word).

4tH's (library) version of UD/MOD is much more elaborate and has this
stack diagram: ( ud1 ud2 -- ud3 ud4)

It is also used in D/MOD ( d1 d2 -- d3 d4).

Hans Bezemer

On Saturday, March 19, 2022 at 2:07:31 PM UTC+1, Heinrich Hohl wrote:
> : D* ( d1 n+ -- d2) DUP ROT * ROT ROT UM* ROT + ;

I know that thingy as:

: mu* swap over * >r um* r> + ;

Which is just about the same thing ;-)

Hans Bezemer

On Saturday, March 19, 2022 at 2:07:31 PM UTC+1, Heinrich Hohl wrote:
> : D* ( d1 n+ -- d2) DUP ROT * ROT ROT UM* ROT + ;
BTW, I know this one as:

( d1 d2 -- d3)
: d* >r swap >r over over um* rot r> * + rot r> * + ;

HB

On 20/03/2022 00:07, Heinrich Hohl wrote:
> On Saturday, March 19, 2022 at 1:54:57 AM UTC+1, dxforth wrote:
>> While most, if not all, systems today use the function in '#' it seems
>> evenly divided whether it's provided as a discrete word to users and
>> under what name.
>
> It seems that the word ud/mod ( ud1 u2 -- urem udquot ) is not needed often.
>
> In the gforth source files (*.fs), it is only used in the number i/o file (nio.fs) in order to
> define #, and in the cross compiler (cross.fs) where it is used to define two words named
> DS! and Sc!
>
> ud/mod itself is defined in kernel.fs
>
> I also searched for the phrase "um/mod r>" but could not find any additional matches.
>
> SwiftForth does not provide a separate word for the UD/MOD routine. This makes the
> related code for # hard to read. In this case I would have preferred a version that
> factors UD/MOD out, even if this word is only used once in the entire system.
> Factoring can improve clarity of code considerably.

Looking further I find FlashForth and AMForth both have UD/MOD. Until now
I wasn't aware of this name being used. Wonder what the history of that was.

While SwiftX doesn't offer such an operator, its # checks to see whether it
needs to do a double division or can get away with a single (at an increase
in code size). Another thing I've not seen before.

On 20/03/2022 00:31, Heinrich Hohl wrote:
> On Saturday, March 19, 2022 at 2:07:31 PM UTC+1, Heinrich Hohl wrote:
>> : D/ ( d1 n+ -- d2) SWAP OVER /MOD >R SWAP UM/MOD SWAP DROP R> ;
>
> Note that PC/FORTH uses floored division. The D/ code shown above will crash ANS systems.
> In ANS compatible systems you can use the following definition:
>
> : D/ ( d1 n+ -- d2) >R S>D R@ FM/MOD R> SWAP >R UM/MOD NIP R> ;
>
> Henry

Thanks. Wonder why it wasn't

: D/MOD ( d1 n+ -- rem d2) >R S>D R@ FM/MOD R> SWAP >R UM/MOD R> ;

which also works AFAIK. A positive modulus being one of the reasons
for using floored division.

On 11/03/2022 23:09, Anton Ertl wrote:
> The folloing description applies to Gforth, but I think that it
> applies to many Forth systems, because this aspect is derived from a
> common ancestor (probably one of Forth, Inc.'s early systems):
>
> The word # (used in, e.g., ".") internally calls UD/MOD, which
> requires two double-by-single divisions:
>
> : ud/mod ( ud1 u2 -- urem udquot ) \ gforth
> \G divide unsigned double @i{ud1} by @i{u2}, resulting in a unsigned double
> \G quotient @i{udquot} and a single remainder @i{urem}.
> >r 0 r@ um/mod r> swap >r
> um/mod r> ;
>
> : # ( ud1 -- ud2 )
> base @ ud/mod rot dup 9 u>
> [ char A char 9 1+ - ] Literal and +
> '0' + hold ;
>
> Division is slow on many CPUs, and many architectures don't have a
> double-by-single division instruction. So I had the idea that we
> could optimize # by
>
> 1) Dealing with the case where the high word is 0 as a special case.
>
> 2) Dealing with the case where BASE contains #10 as a special case.
> ...

Perhaps already mentioned (tl;dr) but inspired by SwiftX' attempt at 1) ...

A typical definition of # looks something like:

: # ( ud -- ud' )
0 base @ um/mod >r base @ um/mod r>
rot dup 9 > 7 and + hold ;

which invokes UM/MOD twice whether needed or not. At the cost of an 'OVER IF'
it can be reduced to one when high word = 0

: # ( ud -- ud' )
0 over if base @ um/mod then >r base @ um/mod r>
rot dup 9 > 7 and + hold ;

: ud. ( ud -- ) <# #s #> type space ;

-1 -1 cr ud.
-1 0 cr ud.

dxforth <dxforth@gmail.com> writes:
>On 11/03/2022 23:09, Anton Ertl wrote:
>> The folloing description applies to Gforth, but I think that it
>> applies to many Forth systems, because this aspect is derived from a
>> common ancestor (probably one of Forth, Inc.'s early systems):
>>
>> The word # (used in, e.g., ".") internally calls UD/MOD, which
>> requires two double-by-single divisions:
>>
>> : ud/mod ( ud1 u2 -- urem udquot ) \ gforth
>> \G divide unsigned double @i{ud1} by @i{u2}, resulting in a unsigned double
>> \G quotient @i{udquot} and a single remainder @i{urem}.
>> >r 0 r@ um/mod r> swap >r
>> um/mod r> ;
>>
>> : # ( ud1 -- ud2 )
>> base @ ud/mod rot dup 9 u>
>> [ char A char 9 1+ - ] Literal and +
>> '0' + hold ;
>>
>> Division is slow on many CPUs, and many architectures don't have a
>> double-by-single division instruction. So I had the idea that we
>> could optimize # by
>>
>> 1) Dealing with the case where the high word is 0 as a special case.
>>
>> 2) Dealing with the case where BASE contains #10 as a special case.
>> ...
>
>Perhaps already mentioned (tl;dr)

It's right behind the stuff you cited.

>A typical definition of # looks something like:
>
> : # ( ud -- ud' )
> 0 base @ um/mod >r base @ um/mod r>
> rot dup 9 > 7 and + hold ;
>
>which invokes UM/MOD twice whether needed or not. At the cost of an 'OVER IF'
>it can be reduced to one when high word = 0
>
> : # ( ud -- ud' )
> 0 over if base @ um/mod then >r base @ um/mod r>
> rot dup 9 > 7 and + hold ;

This invokes um/mod at least once even when the high word=0. Many
architectures have only single-by-single division instructions, and
the solution you snipped is significantly more efficient there:

: # ( ud1 -- ud2 )
?dup-if
base @ ud/mod
else
base @ u/mod 0
then
rot dup 9 u>
[ char A char 9 1+ - ] Literal and +
'0' + hold ;

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

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Many
>architectures have only single-by-single division instructions, and
[single-by-single U/MOD is more efficient than double-by-single UM/MOD]

Thinking about it, maybe not. The typical way that double-by-single
division is implemented on such architectures is to shift the leading
0s away, perform single-by-single division, then clean up the
imprecision. But that routine itself may special-case the high=0
case. In that case the only cost of using UM/MOD in place of U/MOD is
the additional check for high=0 (which will be perfectly predicted,
because it correlates perfectly with the earlier check). So the cost
may be small.

However, at least __udiv_qrnnd_c() (the generic implementation of
UM/MOD that Gforth falls back to if no more architecture-specific code
is present) does not special-case high=0.

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

On 20/03/2022 19:07, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>On 11/03/2022 23:09, Anton Ertl wrote:
>>> The folloing description applies to Gforth, but I think that it
>>> applies to many Forth systems, because this aspect is derived from a
>>> common ancestor (probably one of Forth, Inc.'s early systems):
>>>
>>> The word # (used in, e.g., ".") internally calls UD/MOD, which
>>> requires two double-by-single divisions:
>>>
>>> : ud/mod ( ud1 u2 -- urem udquot ) \ gforth
>>> \G divide unsigned double @i{ud1} by @i{u2}, resulting in a unsigned double
>>> \G quotient @i{udquot} and a single remainder @i{urem}.
>>> >r 0 r@ um/mod r> swap >r
>>> um/mod r> ;
>>>
>>> : # ( ud1 -- ud2 )
>>> base @ ud/mod rot dup 9 u>
>>> [ char A char 9 1+ - ] Literal and +
>>> '0' + hold ;
>>>
>>> Division is slow on many CPUs, and many architectures don't have a
>>> double-by-single division instruction. So I had the idea that we
>>> could optimize # by
>>>
>>> 1) Dealing with the case where the high word is 0 as a special case.
>>>
>>> 2) Dealing with the case where BASE contains #10 as a special case.
>>> ...
>>
>>Perhaps already mentioned (tl;dr)
>
> It's right behind the stuff you cited.
>
>>A typical definition of # looks something like:
>>
>> : # ( ud -- ud' )
>> 0 base @ um/mod >r base @ um/mod r>
>> rot dup 9 > 7 and + hold ;
>>
>>which invokes UM/MOD twice whether needed or not. At the cost of an 'OVER IF'
>>it can be reduced to one when high word = 0
>>
>> : # ( ud -- ud' )
>> 0 over if base @ um/mod then >r base @ um/mod r>
>> rot dup 9 > 7 and + hold ;
>
> This invokes um/mod at least once even when the high word=0. Many
> architectures have only single-by-single division instructions, and
> the solution you snipped is significantly more efficient there:
>
> : # ( ud1 -- ud2 )
> ?dup-if
> base @ ud/mod
> else
> base @ u/mod 0
> then
> rot dup 9 u>
> [ char A char 9 1+ - ] Literal and +
> '0' + hold ;

The above tells the reader ud/mod has a problem and should be avoided.
ISTM if there's an opportunity to optimize ud/mod directly that would
be the better option:

: ud/mod ( ud -- urem udquot )
>r 0 over if r@ um/mod then r> swap >r um/mod r> ;

dxforth <dxforth@gmail.com> writes:
>On 20/03/2022 19:07, Anton Ertl wrote:
>> : # ( ud1 -- ud2 )
>> ?dup-if
>> base @ ud/mod
>> else
>> base @ u/mod 0
>> then
>> rot dup 9 u>
>> [ char A char 9 1+ - ] Literal and +
>> '0' + hold ;
>
>The above tells the reader ud/mod has a problem and should be avoided.

It certainly has a performance problem.

>ISTM if there's an opportunity to optimize ud/mod directly that would
>be the better option:
>
>: ud/mod ( ud -- urem udquot )
> >r 0 over if r@ um/mod then r> swap >r um/mod r> ;

Yes, if we assume that the high=0 case is frequent in general usage of
UD/MOD, it's better to put the special-casing there. But of course
UM/MOD also has performance problems on many architectures, so better
use single-by-single division where possible:

: ud/mod ( ud1 u2 -- urem udquot ) \ gforth
\G divide unsigned double @i{ud1} by @i{u2}, resulting in a unsigned double
\G quotient @i{udquot} and a single remainder @i{urem}.
over 0= if nip u/mod 0 exit then
dup >r u/mod r> swap >r um/mod r> ;

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

On 20/03/2022 23:05, Anton Ertl wrote:
>
> But of course
> UM/MOD also has performance problems on many architectures, so better
> use single-by-single division where possible:

UM/MOD isn't the problem. It's architectures that only provide single-by-
single division. For the same cycles they could have had double-by-single
as iterations is determined by divisor - not dividend - width.

On Sunday, March 20, 2022 at 7:23:45 PM UTC-4, dxforth wrote:
> On 20/03/2022 23:05, Anton Ertl wrote:
> >
> > But of course
> > UM/MOD also has performance problems on many architectures, so better
> > use single-by-single division where possible:
> UM/MOD isn't the problem. It's architectures that only provide single-by-
> single division. For the same cycles they could have had double-by-single
> as iterations is determined by divisor - not dividend - width.

TMS9900 has double by single division.
But not many care... :-)

BTW
I tested your code to speed up for # in Camel Forth and it was almost a wash.
The tiniest bit of a speed improvement counting 1 to 2000 on the screen.

On 21/03/2022 10:48, Brian Fox wrote:
> On Sunday, March 20, 2022 at 7:23:45 PM UTC-4, dxforth wrote:
>> On 20/03/2022 23:05, Anton Ertl wrote:
>> >
>> > But of course
>> > UM/MOD also has performance problems on many architectures, so better
>> > use single-by-single division where possible:
>> UM/MOD isn't the problem. It's architectures that only provide single-by-
>> single division. For the same cycles they could have had double-by-single
>> as iterations is determined by divisor - not dividend - width.
>
> TMS9900 has double by single division.
> But not many care... :-)

Were they to use a language that took advantage of mixed-math they
just might care :)

>
> BTW
> I tested your code to speed up for # in Camel Forth and it was almost a wash.
> The tiniest bit of a speed improvement counting 1 to 2000 on the screen.

I've not done any speed tests but given it's possible to hand-code a version
with optimization in less than a machine-coded version without, what's not to
like? :)

see mu/mod
MU/MOD
( 00408ADC 53 ) PUSH EBX
( 00408ADD 8B1C24 ) MOV EBX, [ESP]
( 00408AE0 8B4500 ) MOV EAX, [EBP]
( 00408AE3 BA00000000 ) MOV EDX, 00000000
( 00408AE8 F7F3 ) DIV EBX
( 00408AEA 5B ) POP EBX
( 00408AEB 50 ) PUSH EAX
( 00408AEC 8B4504 ) MOV EAX, [EBP+04]
( 00408AEF F7F3 ) DIV EBX
( 00408AF1 5B ) POP EBX
( 00408AF2 894500 ) MOV [EBP], EAX
( 00408AF5 895504 ) MOV [EBP+04], EDX
( 00408AF8 C3 ) NEXT,
( 29 bytes, 13 instructions )
ok

see ud/mod
UD/MOD
( 004F08A0 8B4500 ) MOV EAX, [EBP]
( 004F08A3 33D2 ) XOR EDX, EDX
( 004F08A5 0BC0 ) OR EAX, EAX
( 004F08A7 7402 ) JZ/E 004F08AB
( 004F08A9 F7F3 ) DIV EBX
( 004F08AB 8BC8 ) MOV ECX, EAX
( 004F08AD 8B4504 ) MOV EAX, [EBP+04]
( 004F08B0 F7F3 ) DIV EBX
( 004F08B2 8BD9 ) MOV EBX, ECX
( 004F08B4 894500 ) MOV [EBP], EAX
( 004F08B7 895504 ) MOV [EBP+04], EDX
( 004F08BA C3 ) NEXT,
( 27 bytes, 12 instructions )
ok

It looks like Intel wanted a faster number conversion too.

https://lemire.me/blog/2022/03/28/converting-integers-to-decimal-strings-faster-with-avx-512/

Maybe GForth for Intel could use this new instruction?

Brian Fox <brian.fox@brianfox.ca> writes:
>It looks like Intel wanted a faster number conversion too.
>
>https://lemire.me/blog/2022/03/28/converting-integers-to-decimal-strings-faster-with-avx-512/
>
>Maybe GForth for Intel could use this new instruction?

Why Gforth with its portability goals and not some Intel-specific
Forth system? We do have two IA-32/AMD64-specific optimizations
though: a) we use explicit register allocation for IA-32/AMD64 (gcc's
register allocation has not been good enough for many years; this has
recently changed for AMD64 (I have not checked IA-32); b) we use the
IA-32/AMD64 instructions for um/mod, sm/rem and fm/mod, because you
cannot express double/single division in C.

We are unlikely to use the

1) AVX-512 is not universally available even on recent Intel CPUs, and
Intel is doing everything they can to avoid AVX-512 becoming
universally available. But at least they changed their approach for
AVX/AVX2 now, 11 years after AVX was introduced with Sandy Bridge, 9
years after AVX2 was introduced with Haswell: their most recent
Celeron G CPUs support AVX2 (and I guess this includes AVX), so maybe
in ten years we can consider AVX2 to be universally available.

2) It does not fit in with the existing infrastructure for
number->string conversion.

3) This conversion rarely is a significant contributor to the
execution time.

At least 1) and 2) were not problems for the # optimizations discussed
in this thread, and I was interested in how much benefit they could
buy in the occasional cases where # is a significant contributor, so
3) was not a problem, either.

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

"minf...@arcor.de" <minforth@arcor.de> writes:
>> b) we use the=20
>> IA-32/AMD64 instructions for um/mod, sm/rem and fm/mod, because you=20
>> cannot express double/single division in C.=20
>
>Huh? What's wrong with gcc compiling
>
>#include <stdint.h>
>#include <stdio.h>
>
>int main(void) {
>__int128 a=3D10, c;
>int64_t b=3D3;
>c=3Da/b;
>printf("Division : %d",(int)c);
>}

Try it.

For your example, the compiler performs __int128/__int128 division at
compile time, produces the result (__int128)3, converts that it
(int64_t)3 and later (int)3, all at compile time, so in the compiled
code I see

movl $3, %esi

and no division operation of any kind.

A more general example is:

int64_t foo(__int128 a, int64_t b)
{ return a/b;
}

and here's the assembly code that gcc -O3 -S produces:

movq %rdx, %rcx
subq $8, %rsp
sarq $63, %rcx
call __divti3@PLT
addq $8, %rsp
ret

So this sign-extends b into an __int128, and then calls
__int128/__int128 division. Why does gcc do this? Because the C
standard says that both operands have to be converted to a common type
(typically the longer or unsigned type) and then the operation has to
be performed on these types, with a result of that type.

Can a C compiler, knowing that b is in the int64_t range, and that the
result will be converted to int64_t, optimize this division to use
idiv (the signed double/single division instruction)? No, it cannot,
because idiv produces an exception if the result does not fit into a
single machine word, while the compiled C code has to produce an
__int128 result.

The case is different for implementing M* and UM*. You can encode
this in C as

((__int128)a)*b

producing an __int128 result. According to the C standard all
operands have to be converted to __int128, then the operation has to
be performed. However, in this case using the imul instruction for
signed single*single->double multiplication produces the same result
if a and b are originally int64_t, so a C compiler can optimize the C
code to use this instruction, and gcc does that (and has done it for a
long time).

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

Anton Ertl schrieb am Mittwoch, 30. März 2022 um 12:54:08 UTC+2:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >> b) we use the=20
> >> IA-32/AMD64 instructions for um/mod, sm/rem and fm/mod, because you=20
> >> cannot express double/single division in C.=20
> >
> >Huh? What's wrong with gcc compiling
> >
> >#include <stdint.h>
> >#include <stdio.h>
> >
> >int main(void) {
> >__int128 a=3D10, c;
> >int64_t b=3D3;
> >c=3Da/b;
> >printf("Division : %d",(int)c);
> >}
>
> Try it.
>
> For your example, the compiler performs __int128/__int128 division at
> compile time, produces the result (__int128)3, converts that it
> (int64_t)3 and later (int)3, all at compile time, so in the compiled
> code I see
>
> movl $3, %esi
>
> and no division operation of any kind.
>
> A more general example is:
>
> int64_t foo(__int128 a, int64_t b)
> {
> return a/b;
> }
>
> and here's the assembly code that gcc -O3 -S produces:
>
> movq %rdx, %rcx
> subq $8, %rsp
> sarq $63, %rcx
> call __divti3@PLT
> addq $8, %rsp
> ret
>
> So this sign-extends b into an __int128, and then calls
> __int128/__int128 division. Why does gcc do this? Because the C
> standard says that both operands have to be converted to a common type
> (typically the longer or unsigned type) and then the operation has to
> be performed on these types, with a result of that type.
>
> Can a C compiler, knowing that b is in the int64_t range, and that the
> result will be converted to int64_t, optimize this division to use
> idiv (the signed double/single division instruction)? No, it cannot,
> because idiv produces an exception if the result does not fit into a
> single machine word, while the compiled C code has to produce an
> __int128 result.
>
> The case is different for implementing M* and UM*. You can encode
> this in C as
>
> ((__int128)a)*b
>
> producing an __int128 result. According to the C standard all
> operands have to be converted to __int128, then the operation has to
> be performed. However, in this case using the imul instruction for
> signed single*single->double multiplication produces the same result
> if a and b are originally int64_t, so a C compiler can optimize the C
> code to use this instruction, and gcc does that (and has done it for a
> long time).

Thank you for the good explanations !!!

On Wednesday, March 30, 2022 at 2:23:24 PM UTC+2, minf...@arcor.de wrote:
> Thank you for the good explanations !!!
I can second that motion - well done, Anton.

However, this is something I always found a weakness in C. Let me begin by saying I don't like compilers doing things behind my back.
Some think that begin able to write:

a := "1" + 1

Is cool. I think it doesn't. As a matter of fact - it makes no sense to me. The most logical thing that I can imagine which happens here
is that "a" contains the address of the "1" string + 1.

This makes as little sense to me:

char a = 15;
long b = 25L;
float c = 0.0;
int d;

d = a + b + c;

The only sensible code IMHO is:

d = (int) a + (int) b + (int) c;

Why? I don't like compilers doing things behind my back, so if not ALL operands are designated the same type - that's an error to me.

It's bad enough operators are overloaded (I like the way Forth thinks), but allowing this leaves to way to much leeway to the compiler
to do whatever it likes. Yes, I know it's all documented - but how many of us are looking in the standard to see whether this thing is
allowed or not - and what the documented behavior of (in this case) C is?

I once had to write my own strtol(), because I found out that under TurboC v2, trap values were converted UNSIGNED - instead of
triggering an error.

So yes - I'm not a big fan of Python or javascript. And I'd rather have a C-- than C++ - where C-- would be a lot dumber and more pedantic
than vanilla C.

Hans Bezemer

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>And I'd rather have a C-- than C++ - where C-- would be a lot dumber and more pedantic
>than vanilla C.

Maybe Rust is to your taste.

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

On 31/03/2022 00:26, Hans Bezemer wrote:
>
> Why? I don't like compilers doing things behind my back, so if not ALL operands are designated the same type - that's an error to me.
>
> It's bad enough operators are overloaded (I like the way Forth thinks), but allowing this leaves to way to much leeway to the compiler
> to do whatever it likes. Yes, I know it's all documented - but how many of us are looking in the standard to see whether this thing is
> allowed or not - and what the documented behavior of (in this case) C is?
>
> I once had to write my own strtol(), because I found out that under TurboC v2, trap values were converted UNSIGNED - instead of
> triggering an error.
>
> So yes - I'm not a big fan of Python or javascript. And I'd rather have a C-- than C++ - where C-- would be a lot dumber and more pedantic
> than vanilla C.

Are you trying to put compiler writers out of business? But no fear of that.
Who can resist when the Serpent whispers 'All these things I can give you'.

On Wednesday, March 30, 2022 at 6:51:46 PM UTC+2, Anton Ertl wrote:
> Hans Bezemer <the.bee...@gmail.com> writes:
> >And I'd rather have a C-- than C++ - where C-- would be a lot dumber and more pedantic
> >than vanilla C.
> Maybe Rust is to your taste.
> - 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 2021: https://euro.theforth.net/2021
Rust is as much removed from portable assembly as a microbe is removed from a fighter pilot.
Not to mention its butt ugly syntax. What I want is an unabstracted language - not an overly
abstracted one. It's just nice to know when you're doing something stupid - something that simply
doesn't compile. Like adding an integer to a float.

HB

On Thursday, March 31, 2022 at 1:55:06 AM UTC+2, dxforth wrote:
> On 31/03/2022 00:26, Hans Bezemer wrote:
> >
> > Why? I don't like compilers doing things behind my back, so if not ALL operands are designated the same type - that's an error to me.
> >
> > It's bad enough operators are overloaded (I like the way Forth thinks), but allowing this leaves to way to much leeway to the compiler
> > to do whatever it likes. Yes, I know it's all documented - but how many of us are looking in the standard to see whether this thing is
> > allowed or not - and what the documented behavior of (in this case) C is?
> >
> > I once had to write my own strtol(), because I found out that under TurboC v2, trap values were converted UNSIGNED - instead of
> > triggering an error.
> >
> > So yes - I'm not a big fan of Python or javascript. And I'd rather have a C-- than C++ - where C-- would be a lot dumber and more pedantic
> > than vanilla C.
> Are you trying to put compiler writers out of business? But no fear of that.
> Who can resist when the Serpent whispers 'All these things I can give you'.

Yeah - but I'm not biting. Best thing so far is still C. Although I'm quite worried about the developments there.
If those continue I fear what I have to do to keep my compiler running predictably.

And since I like it to be running on every platform, any niche or fringe language will not do.

Hans Bezemer

the.bee...@gmail.com schrieb am Donnerstag, 31. März 2022 um 11:18:17 UTC+2:
> On Thursday, March 31, 2022 at 1:55:06 AM UTC+2, dxforth wrote:
> > On 31/03/2022 00:26, Hans Bezemer wrote:
> > >
> > > Why? I don't like compilers doing things behind my back, so if not ALL operands are designated the same type - that's an error to me.
> > >
> > > It's bad enough operators are overloaded (I like the way Forth thinks), but allowing this leaves to way to much leeway to the compiler
> > > to do whatever it likes. Yes, I know it's all documented - but how many of us are looking in the standard to see whether this thing is
> > > allowed or not - and what the documented behavior of (in this case) C is?
> > >
> > > I once had to write my own strtol(), because I found out that under TurboC v2, trap values were converted UNSIGNED - instead of
> > > triggering an error.
> > >
> > > So yes - I'm not a big fan of Python or javascript. And I'd rather have a C-- than C++ - where C-- would be a lot dumber and more pedantic
> > > than vanilla C.
> > Are you trying to put compiler writers out of business? But no fear of that.
> > Who can resist when the Serpent whispers 'All these things I can give you'.
> Yeah - but I'm not biting. Best thing so far is still C. Although I'm quite worried about the developments there.
> If those continue I fear what I have to do to keep my compiler running predictably.
>
> And since I like it to be running on every platform, any niche or fringe language will not do.
>

AFAIK your 4th is more geared for desktops than for microcontrollers
(I may be wrong here). There AMD64 assembly covers 90% of the "market"
and is no niche language.

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> It's just nice to know when you're doing something stupid - something
> that simply doesn't compile. Like adding an integer to a float.

Those automatic conversions seem to have gone out of style in recent
decades, and a good thing too. I guess you don't like Ada though.

On Friday, April 1, 2022 at 3:02:18 AM UTC+2, Paul Rubin wrote:
> Hans Bezemer <the.bee...@gmail.com> writes:
> > It's just nice to know when you're doing something stupid - something
> > that simply doesn't compile. Like adding an integer to a float.
> Those automatic conversions seem to have gone out of style in recent
> decades, and a good thing too. I guess you don't like Ada though.

I would be worried more about adding a float to an integer.

-marcel