A useful program, watdoido

[none albert]

Often time you are interested how long some task takes.
It is intended to answer the question " "how have I
wasted my time."
The idea is to have a timer program.
If it finishes it tells you how much time has elapsed.
It is cumbersome to grab your smart phone, start the timer,
then stop the timer and read it back.
Once more the terminal interface is superior.

START: timer
STOP: BYE

~:timer
2000 MS BYE
~:you spend 0 minutes 6 seconds

In ciforth it is easy because TIME&DATE is exposed, and you
can inspect factors, in particular SSE SPLIT-OFF-TIME
This for linux 32/64 i86/arm/riscv

/-------- timer.frt ------8< ---------------------

WANT TIME&DATE
VARIABLE START

: BYE SSE START @ - SPLIT-OFF-TIME DROP
"You spent " TYPE DUP IF . "hours " TYPE ELSE DROP THEN
. "minutes " TYPE . "seconds " TYPE CR BYE ;
'ERROR RESTORED
: doit SSE START ! QUIT ;
/-------------------------8< ---------------------

lina -c timer.frt

You must restore error, else typing `` bye '' terminates
the program with a fatal error, instead of executing BYE.

SSE is very useful and is attainable in any Forth
that can execute system calls.

For inspiration I include the TIME&DATE block for
Linux.
/-------------------------8< ---------------------
( TIME&DATE ) CF: ?LI \ AH B30423
"-syscalls-" WANTED : SSE 0 0 0 __NR_time XOS ; ( 1970/1/1)
: | OVER , + ; : 5m 31 | 30 | 31 | 30 | 31 | ;
DATA TABLE ( start of month within leap period) -1
31 | 28 | 5m 5m 31 | 28 | 5m 5m 31 | 29 | 5m 5m
31 | 28 | 5m 5m , : T[] CELLS TABLE + @ ;
\ For DAYS within leap return MONTHS
: MONTHS >R 0 BEGIN R@ OVER T[] > WHILE 1+ REPEAT 1- RDROP ;
\ For DAYS within leap period return DAY MONTH YEARS
: SPLIT-LEAP DUP MONTHS DUP >R T[] - R> 12 /MOD >R 1+ R> ;
\ For TIME return SEC MIN HOUR DAYS
: SPLIT-OFF-TIME 0 60 UM/MOD 60 /MOD 24 /MOD ;
\ For DAYS return DAY MONTH YEAR
: SPLIT-OFF-DATE 1461 /MOD >R SPLIT-LEAP R> 4 * + 1970 + ;
\ Return current SEC MIN HOUR DAY MONTH YEAR
: TIME&DATE SSE SPLIT-OFF-TIME SPLIT-OFF-DATE ;

/-------------------------8< ---------------------
Note this TIME&DATE is only valid between 1900 and 2100,
because it doesn't do the century exception.

You can use the timer also for timing the real time of your
programs.
timer
INCLUDE sieve1G.frt
dosieve
BYE

You spend 10 hours 23 minutes 13 seconds

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. First gain is a cat spinning. - the Wise from Antrim -

[sjack]

looks good.

[Hans Bezemer]

On Saturday, December 23, 2023 at 3:33:47 PM UTC+1, none albert wrote:
> DATA TABLE ( start of month within leap period) -1
> 31 | 28 | 5m 5m 31 | 28 | 5m 5m 31 | 29 | 5m 5m
> 31 | 28 | 5m 5m , : T[] CELLS TABLE + @ ;
> \ For DAYS within leap return MONTHS
> : MONTHS >R 0 BEGIN R@ OVER T[] > WHILE 1+ REPEAT 1- RDROP ;

All days per month in a single line:
: days/month 15662003 swap 1- 2* rshift 3 and 28 or ;

Hans Bezemer

[Paul Rubin]

Hans Bezemer <the.bee...@gmail.com> writes:
> : days/month 15662003 swap 1- 2* rshift 3 and 28 or ;

;-)

[Kerr-Mudd, John]

BTDT in asm
leap years are a pain.
--
Bah, and indeed Humbug.

[minforth]

Kerr-Mudd, John wrote:

> On Mon, 29 Jan 2024 15:04:16 -0800
> Paul Rubin <no.e...@nospam.invalid> wrote:

>> Hans Bezemer <the.bee...@gmail.com> writes:
>> > : days/month 15662003 swap 1- 2* rshift 3 and 28 or ;
>>
>> ;-)

> BTDT in asm
> leap years are a pain.

ASM might be better, but probably not worth the pain.

Even my dumb compiler (TOS cached) already translates this to:

┌────────────────────────┐
│ MinForth V3.6 - 64 bit │
└────────────────────────┘
Stacks: d:1024 r:512 f:128
Unused: 199M
# see days/month
C DAYS/MONTH <799>
0000000000406242 <mf_DAYSslashMONTH>:
406242: 4c 89 e0 mov %r12,%rax
406245: 41 bc b3 fb ee 00 mov $0xeefbb3,%r12d
40624b: 48 8d 44 00 fe lea -0x2(%rax,%rax,1),%rax
406250: 49 89 c4 mov %rax,%r12
406253: 41 bc b3 fb ee 00 mov $0xeefbb3,%r12d
406259: c4 42 fb f7 e4 shrx %rax,%r12,%r12
40625e: 4d 89 27 mov %r12,(%r15)
406261: 41 bc 03 00 00 00 mov $0x3,%r12d
406267: 49 8b 07 mov (%r15),%rax
40626a: 83 e0 03 and $0x3,%eax
40626d: 49 89 07 mov %rax,(%r15)
406270: 41 bc 1c 00 00 00 mov $0x1c,%r12d
406276: 49 89 c4 mov %rax,%r12
406279: 49 83 cc 1c or $0x1c,%r12
40627d: c3 retq

[Kerr-Mudd, John]

On Tue, 30 Jan 2024 13:33:44 +0000
minf...@gmx.net (minforth) wrote:

> Kerr-Mudd, John wrote:
>
> > On Mon, 29 Jan 2024 15:04:16 -0800
> > Paul Rubin <no.e...@nospam.invalid> wrote:
>
> >> Hans Bezemer <the.bee...@gmail.com> writes:
> >> > : days/month 15662003 swap 1- 2* rshift 3 and 28 or ;
> >>
> >> ;-)
>
> > BTDT in asm
> > leap years are a pain.
>
> ASM might be better, but probably not worth the pain.

I'm more comfortable in asm than forth!
The pain is taking care to deal with leap centuries.

> Even my dumb compiler (TOS cached) already translates this to:
>
> ┌────────────────────────┐
> │ MinForth V3.6 - 64 bit │
> └────────────────────────┘
> Stacks: d:1024 r:512 f:128
> Unused: 199M
> # see days/month
> C DAYS/MONTH <799>
> 0000000000406242 <mf_DAYSslashMONTH>:
> 406242: 4c 89 e0 mov %r12,%rax
> 406245: 41 bc b3 fb ee 00 mov $0xeefbb3,%r12d
> 40624b: 48 8d 44 00 fe lea -0x2(%rax,%rax,1),%rax
> 406250: 49 89 c4 mov %rax,%r12
> 406253: 41 bc b3 fb ee 00 mov $0xeefbb3,%r12d
> 406259: c4 42 fb f7 e4 shrx %rax,%r12,%r12
> 40625e: 4d 89 27 mov %r12,(%r15)
> 406261: 41 bc 03 00 00 00 mov $0x3,%r12d
> 406267: 49 8b 07 mov (%r15),%rax
> 40626a: 83 e0 03 and $0x3,%eax
> 40626d: 49 89 07 mov %rax,(%r15)
> 406270: 41 bc 1c 00 00 00 mov $0x1c,%r12d
> 406276: 49 89 c4 mov %rax,%r12
> 406279: 49 83 cc 1c or $0x1c,%r12
> 40627d: c3 retq

[dxf]

On 31/01/2024 8:40 pm, Kerr-Mudd, John wrote:
> On Tue, 30 Jan 2024 13:33:44 +0000
> minf...@gmx.net (minforth) wrote:
>
>> Kerr-Mudd, John wrote:
>>
>>> On Mon, 29 Jan 2024 15:04:16 -0800
>>> Paul Rubin <no.e...@nospam.invalid> wrote:
>>
>>>> Hans Bezemer <the.bee...@gmail.com> writes:
>>>>> : days/month 15662003 swap 1- 2* rshift 3 and 28 or ;
>>>>
>>>> ;-)
>>
>>> BTDT in asm
>>> leap years are a pain.
>>
>> ASM might be better, but probably not worth the pain.
>
>
> I'm more comfortable in asm than forth!

> ...

Wasn't it the idea that Forth was easier than assembler?
I can see how ANS-Forth turned that around :)

[Anton Ertl]

minf...@gmx.net (minforth) writes:
>>> Hans Bezemer <the.bee...@gmail.com> writes:
>>> > : days/month 15662003 swap 1- 2* rshift 3 and 28 or ;

...

>Even my dumb compiler (TOS cached) already translates this to:

...

>0000000000406242 <mf_DAYSslashMONTH>:
> 406242: 4c 89 e0 mov %r12,%rax
> 406245: 41 bc b3 fb ee 00 mov $0xeefbb3,%r12d
> 40624b: 48 8d 44 00 fe lea -0x2(%rax,%rax,1),%rax
> 406250: 49 89 c4 mov %rax,%r12
> 406253: 41 bc b3 fb ee 00 mov $0xeefbb3,%r12d
> 406259: c4 42 fb f7 e4 shrx %rax,%r12,%r12
> 40625e: 4d 89 27 mov %r12,(%r15)
> 406261: 41 bc 03 00 00 00 mov $0x3,%r12d
> 406267: 49 8b 07 mov (%r15),%rax
> 40626a: 83 e0 03 and $0x3,%eax
> 40626d: 49 89 07 mov %rax,(%r15)
> 406270: 41 bc 1c 00 00 00 mov $0x1c,%r12d
> 406276: 49 89 c4 mov %rax,%r12
> 406279: 49 83 cc 1c or $0x1c,%r12
> 40627d: c3 retq

Yes, this is a case (straight-line code) where existing Forth systems
do well. Let's see:

gforth-fast (development):
$7FA5FDC99158 lit 1->2
$7FA5FDC99160 #15662003
7FA5FD93F812: mov r15,$08[rbx]
$7FA5FDC99168 swap 2->1
7FA5FD93F816: mov $00[r13],r15
7FA5FD93F81A: sub r13,$08
$7FA5FDC99170 1- 1->1
7FA5FD93F81E: sub r8,$01
$7FA5FDC99178 2* 1->1
7FA5FD93F822: add r8,r8
$7FA5FDC99180 rshift 1->1
7FA5FD93F825: mov rax,$08[r13]
7FA5FD93F829: mov ecx,r8d
7FA5FD93F82C: add r13,$08
7FA5FD93F830: shr rax,CL
7FA5FD93F833: mov r8,rax
$7FA5FDC99188 lit and 1->1
$7FA5FDC99190 #3
$7FA5FDC99198 and
7FA5FD93F836: add rbx,$48
7FA5FD93F83A: and r8,-$10[rbx]
$7FA5FDC991A0 lit 1->2
$7FA5FDC991A8 #28
7FA5FD93F83E: mov r15,$08[rbx]
$7FA5FDC991B0 or 2->1
7FA5FD93F842: or r8,r15
$7FA5FDC991B8 ;s 1->1
7FA5FD93F845: mov rbx,[r14]
7FA5FD93F848: add r14,$08
7FA5FD93F84C: mov rax,[rbx]
7FA5FD93F84F: jmp eax

iforth lxf SwiftForth x64 vfx64
pop rbx dec ebx -8 [RBP] RBP LEA DEC RBX
lea rbx, [rbx -1 +] shl ebx, 1h EEFBB3 # 0 [RBP] MOV SHL RBX, #1
lea rbx, [rbx*2 0 +] mov eax, #EEFBB3h RBX DEC MOV RCX, RBX
mov rcx, rbx mov ecx, ebx RBX SHL MOV EBX, #00EEFBB3
mov rbx, $00EEFBB3 d# shr eax, cl RBX RCX MOV SHR RBX, CL
shr rbx, cl and eax, #3h 0 [RBP] RBX MOV AND RBX, #03
and rbx, 3 b# or eax, #1Ch 8 [RBP] RBP LEA OR RBX, #1C
or rbx, #28 b# mov ebx, eax RBX CL SHR RET/NEXT
push rbx ret near 3 # RBX AND
; 1C # RBX OR
RET

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

[alb...@spenarnc.xs4all.nl]

In article <20240130111251.79cc...@127.0.0.1>,

Kerr-Mudd, John <ad...@127.0.0.1> wrote:
>On Mon, 29 Jan 2024 15:04:16 -0800
>Paul Rubin <no.e...@nospam.invalid> wrote:
>
>> Hans Bezemer <the.bee...@gmail.com> writes:
>> > : days/month 15662003 swap 1- 2* rshift 3 and 28 or ;
>>
>> ;-)
>
>BTDT in asm
>leap years are a pain.

I have ignored the exception ending with 00 ciforth.
So my DAT&TIME has a year 2100 problem.
Now it fits neatly on one screen based on the __NR_time system
call, (seconds in epoch).

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. First gain is a cat purring. - the Wise from Antrim -

[Kerr-Mudd, John]

Somehow getting new stuff into my brain is getting hardwer; Forth has so
/many/ words. I learnt x86 (up to a usable standard, I'm not an expert)
ages back.

[minforth]

Kerr-Mudd, John wrote:
>> Wasn't it the idea that Forth was easier than assembler?
>> I can see how ANS-Forth turned that around :)
>>

> Somehow getting new stuff into my brain is getting hardwer; Forth has so
> /many/ words. I learnt x86 (up to a usable standard, I'm not an expert)
> ages back.

CPU types and OS generations are constantly changing. You can't (re)learn
everything and constantly chase after it over decades.

An assembler is obsolete after a few years. And what use is a racehorse
if you can't maintain it after a while?

That's why we switched to a C-based Forth system a long time ago. This
made porting to new platforms much easier. Hand-optimised assembler words
are still possible, but practically never necessary (except for some
hardware drivers). This horse runs fast enough.

[Anton Ertl]

And it is for Hans Bezemer, while Kerr-Mudd, John is more comfortable
in "x86" asm.

>I can see how ANS-Forth turned that around :)

I doubt that the comfort level of Kerr-Mudd, John is related to the
Forth dialect.

Anyway, taking your comment at face value, please present a version of
days/month above in your favourite Forth dialect so that we can
see the difference for ourselves.

[Kerr-Mudd, John]

On Wed, 31 Jan 2024 17:01:37 GMT
an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> dxf <dxf...@gmail.com> writes:
> >On 31/01/2024 8:40 pm, Kerr-Mudd, John wrote:
> >> On Tue, 30 Jan 2024 13:33:44 +0000
> >> minf...@gmx.net (minforth) wrote:
> >>
> >>> Kerr-Mudd, John wrote:
> >>>
> >>>> On Mon, 29 Jan 2024 15:04:16 -0800
> >>>> Paul Rubin <no.e...@nospam.invalid> wrote:
> >>>
> >>>>> Hans Bezemer <the.bee...@gmail.com> writes:
> >>>>>> : days/month 15662003 swap 1- 2* rshift 3 and 28 or ;
> >>>>>
> >>>>> ;-)
> >>>
> >>>> BTDT in asm
> >>>> leap years are a pain.
> >>>
> >>> ASM might be better, but probably not worth the pain.
> >>
> >>
> >> I'm more comfortable in asm than forth!
> >> ...
> >
> >Wasn't it the idea that Forth was easier than assembler?
>
> And it is for Hans Bezemer, while Kerr-Mudd, John is more comfortable
> in "x86" asm.
>
> >I can see how ANS-Forth turned that around :)
>
> I doubt that the comfort level of Kerr-Mudd, John is related to the
> Forth dialect.

True - call me John if you want (or newbie forther or whatever) - it's a
bit of an embarrassing pseudonym, but I've had it for years.

>
> Anyway, taking your comment at face value, please present a version of
> days/month above in your favourite Forth dialect so that we can
> see the difference for ourselves.
>

My 8086 asm calendar program can be seen in clax, if you're keen enough and
willing to dig back a year or 2.
It also uses a magic number for days per month, but I 'm pretty sure I
stole^w borrowed it from somewhere else.

[mhx]

> : days/month 15662003 swap 1- 2* rshift 3 and 28 or ;

Fun fact: The number 15662003 is the identifier for senile dementia.
( https://bioportal.bioontology.org/ontologies )

-marcel

[mhx]

mhx wrote:

>> : days/month 15662003 swap 1- 2* rshift 3 and 28 or ;

Somebody beat me to this much easier to understand improvement ...

It is of course possible to fit a polynomial through
the points in the table:

-( 11 x^11)/907200
+( 163 x^10)/181440
-( 37 x^9 )/1260
+( 13481 x^8 )/24192
-( 2055371 x^7 )/302400
+( 240683 x^6 )/4320
-( 28268521 x^5 )/90720
+( 85774775 x^4 )/72576
-(446998571 x^3 )/151200
+( 46351537 x^2 )/10080
-( 221017 x )/56
+1416

And now it also works for the month between January and February.

-marcel

[dxf]

On 1/02/2024 4:01 am, Anton Ertl wrote:
> dxf <dxf...@gmail.com> writes:
>> On 31/01/2024 8:40 pm, Kerr-Mudd, John wrote:
>>> On Tue, 30 Jan 2024 13:33:44 +0000
>>> minf...@gmx.net (minforth) wrote:
>>>
>>>> Kerr-Mudd, John wrote:
>>>>
>>>>> On Mon, 29 Jan 2024 15:04:16 -0800
>>>>> Paul Rubin <no.e...@nospam.invalid> wrote:
>>>>
>>>>>> Hans Bezemer <the.bee...@gmail.com> writes:
>>>>>>> : days/month 15662003 swap 1- 2* rshift 3 and 28 or ;
>>>>>>
>>>>>> ;-)
>>>>
>>>>> BTDT in asm
>>>>> leap years are a pain.
>>>>
>>>> ASM might be better, but probably not worth the pain.
>>>
>>>
>>> I'm more comfortable in asm than forth!
>>> ...
>>
>> Wasn't it the idea that Forth was easier than assembler?
>
> And it is for Hans Bezemer, while Kerr-Mudd, John is more comfortable
> in "x86" asm.
>
>> I can see how ANS-Forth turned that around :)
>
> I doubt that the comfort level of Kerr-Mudd, John is related to the
> Forth dialect.

Perhaps not, but for me it does. Let's talk about expectations since
we all have them.

A non-Forth programmer acquaintance said he thought it (Forth) wasn't
a HLL at all - more like assembler (and he was well-versed in asm).
Apparently even asm coders have expectations and straying too far
doesn't go down well. Hence prefix assemblers in forth, $ prefix
to denote a hex number, recognizers etc. When Mitch Bradley suggested
parsers h# f# for hex and float respectively one could hear the
proverbial pin drop. Personally I'd wear it in a forth environment but
finding another so-inclined would be difficult. Harder still would be
finding an app end-user that tolerated Albert's approach to command-line
parsing. Giving end-users what they expect is the best policy. They
don't care what language the app was written in or in making things easy
for the programmer.

[dxf]

Forth jockey to C horse: 'Winning isn't everything'.

[Gerry Jackson]

How does this simple lookup solution compare?

: d/m s\" 0\x1f\x1c\x1f\x1e\x1f\x1e\x1f\x1f\x1e\x1f\x1e\x1f" drop + c@ ;
: x 13 1 do i d/m . loop ;
x 31 28 31 30 31 30 31 31 30 31 30 31 ok

--
Gerry

[Anton Ertl]

Gerry Jackson <do-no...@swldwa.uk> writes:
>On 31/01/2024 09:59, Anton Ertl wrote:
>> minf...@gmx.net (minforth) writes:
>>>>> Hans Bezemer <the.bee...@gmail.com> writes:
>>>>>> : days/month 15662003 swap 1- 2* rshift 3 and 28 or ;
...

>How does this simple lookup solution compare?
>
>: d/m s\" 0\x1f\x1c\x1f\x1e\x1f\x1e\x1f\x1f\x1e\x1f\x1e\x1f" drop + c@ ;
>: x 13 1 do i d/m . loop ;
>x 31 28 31 30 31 30 31 31 30 31 30 31 ok

In Gforth, very well:

days/month d/m
lit 1->2 lit+ 1->1
#15662003 $7F58DC846E10
mov r15,$08[rbx] add r8,$08[rbx]
swap 2->1 c@ 1->1
mov $00[r13],r15 movzx r8d,byte PTR [r8]
sub r13,$08 ;s 1->1
1- 1->1 mov rbx,[r14]
sub r8,$01 add r14,$08
2* 1->1 mov rax,[rbx]
add r8,r8 jmp eax
rshift 1->1
mov rax,$08[r13]
mov ecx,r8d
add r13,$08
shr rax,CL
mov r8,rax
lit and 1->1
#3
and
add rbx,$48
and r8,-$10[rbx]
lit 1->2
#28
mov r15,$08[rbx]
or 2->1
or r8,r15
;s 1->1
mov rbx,[r14]
add r14,$08
mov rax,[rbx]
jmp eax

The 12 bytes of data vanishes against the reduced threaded-code and
native-code size.

For the other systems:

days/month

iforth lxf SwiftForth x64 vfx64
pop rbx dec ebx -8 [RBP] RBP LEA DEC RBX
lea rbx, [rbx -1 +] shl ebx, 1h EEFBB3 # 0 [RBP] MOV SHL RBX, #1
lea rbx, [rbx*2 0 +] mov eax, #EEFBB3h RBX DEC MOV RCX, RBX
mov rcx, rbx mov ecx, ebx RBX SHL MOV EBX, #00EEFBB3
mov rbx, $00EEFBB3 d# shr eax, cl RBX RCX MOV SHR RBX, CL
shr rbx, cl and eax, #3h 0 [RBP] RBX MOV AND RBX, #03
and rbx, 3 b# or eax, #1Ch 8 [RBP] RBP LEA OR RBX, #1C
or rbx, #28 b# mov ebx, eax RBX CL SHR RET/NEXT
push rbx ret near 3 # RBX AND
; 1C # RBX OR
RET

iforth SwiftForth x64 vfx64
pop rbx 40664E ( (S") ) CALL CALL 004256C0 (S") "0"
movzx rdi, [rbx $... +] "0" MOV RBX, [RBP]
push rdi 0 [RBP] RBX MOV ADD RBX, [RBP+08]
8 [RBP] RBP LEA MOVZX RBX, Byte 0 [RBX]
0 [RBP] RBX ADD LEA RBP, [RBP+10]
8 [RBP] RBP LEA RET/NEXT
0 [RBX] RBX MOVZX
RET

Pasting into lxf does not work, and my echo-based workaround does not
work in this example, either.

Your solution works great in Gforth and iForth, but S\" (and S") is
not that great in SwiftForth and VFX. Better use CREATE for the
table.

[alb...@spenarnc.xs4all.nl]

In article <07897c331ad14cc9...@www.novabbs.com>,

There is a guy names Smith (smith and Jones) who does a Forth in Hex/
machinelanguage. He looks up individual instructions in the Pentium
manuals, the way Chuck Moore does it.
It is a pretty complete Forth.

https://dacvs.neocities.org/SF/

(I found it at Reddit. There is interesting stuff there.)

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. First gain is a cat purring. - the Wise from Antrim -

[alb...@spenarnc.xs4all.nl]

In article <upfjl6$1vmfh$1...@dont-email.me>,

Four year period is better:
2 : | OVER , + ; : 5m 31 | 30 | 31 | 30 | 31 | ;
3 DATA TABLE ( start of month within leap period) -1
4 31 | 28 | 5m 5m 31 | 28 | 5m 5m 31 | 29 | 5m 5m
5 31 | 28 | 5m 5m , : T[] CELLS TABLE + @ ;

>
>--
>Gerry

>
--
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. First gain is a cat purring. - the Wise from Antrim -

[ahmed]

Hi,

for leap year:
: l_d/m 15662007 swap 1- 2* rshift 3 and 28 or ;

for other years:
: __d/m 15662003 swap 1- 2* rshift 3 and 28 or ; ( this is already given by H. Bezemer)

in fact:
15662003 written in base 4 gives: 323233232303 where the digits are what to add to 28 to get the days per month (beginning from the right).
15662007 written in base 4 gives: 323233232313 where the digits are what to add to 28 to get the days per month (beginning from the right).

that is what I remarked!

Bye

[Anton Ertl]

melahi...@yahoo.fr (ahmed) writes:
>Hi,
>
>for leap year:
>: l_d/m 15662007 swap 1- 2* rshift 3 and 28 or ;
>
>for other years:
>: __d/m 15662003 swap 1- 2* rshift 3 and 28 or ; ( this is already given by H. Bezemer)
>
>in fact:
> 15662003 written in base 4 gives: 323233232303 where the digits are what to add to 28 to get the days per month (beginning from the right).

Given that Forth can do base 4, this leads to a more readable variant:

: __d/m [ 4 base ! ] 323233232303 [ decimal ] swap 1- 2* rshift 3 and 28 or ;

Or we can get rid of the 1- by appending another digit. And let's
only introduce the constant when we have to, and use "+" instead of
"or" for the addition:

: __d/m 2* [ 4 base ! ] 3232332323030 [ decimal ] swap rshift 3 and 28 + ;

Or just do a byte lookup as suggested by Gerry Jackson.

[dxf]

On 1/02/2024 7:10 pm, Gerry Jackson wrote:
> ...

> How does this simple lookup solution compare?
>
> : d/m s\" 0\x1f\x1c\x1f\x1e\x1f\x1e\x1f\x1f\x1e\x1f\x1e\x1f" drop + c@ ;
> : x 13 1 do i d/m . loop ;
> x 31 28 31 30 31 30 31 31 30 31 30 31  ok

It's a neat one-line solution with little obfuscation suitable for a 16-bit
forth (and I imagine any other).

In DX-Forth it can be defined:

:noname + c@ ; build D/M ( m -- d ) ," \1f\1c\1f\1e\1f\1e\1f\1f\1e\1f\1e\1f"

which is two bytes less and theoretically faster.

[Gerry Jackson]

A leap year shouldn't be difficult to handle, a typical algorithm is

: leap-year? ( y -- 0 | 1 ) \ Returns 1 for a leap year, otherwise 0
dup 3 and if 0= exit then \ Return 0 if not divisible by 4
dup 400 mod 0= if drop 1 exit then
100 mod if 1 exit then
0
;p

and use it with:

\ days/month ignores leap years
: days/month ( month -- days )

s\" 0\x1f\x1c\x1f\x1e\x1f\x1e\x1f\x1f\x1e\x1f\x1e\x1f"
drop + c@
;

: days-in-month ( year month -- n )
days/month dup 28 > if nip exit then \ Exit if not February
swap leap-year? +
;

That definition of leap year is a bit slow with the MODs and can be
better, particularly if the range of years is restricted. For example
if the range is restricted to 1901 to 2099, LEAP-YEAR? can be defined as
: leap-year? ( year -- 0 | 1) 3 and 0= negate ;
as the year 2000 was a leap year

If only a few non-leap year century dates like 1900 are in the range,
they can be tested for specifically.

If a wider range is needed a bit vector can be used. In a 64 bit Forth,
500 years would take only 8 cells.

A completely general solution isn't feasible as the year in which
various countries adopted the Gregorian calendar varies from the 16th
century to the 20th century so days per month varies by country e.g. in
the UK September 1752 had only 19 days.

--
Gerry

[alb...@spenarnc.xs4all.nl]

In article <upeigu$1n4af$1...@dont-email.me>, dxf <dxf...@gmail.com> wrote:
<SNIP>

>Perhaps not, but for me it does. Let's talk about expectations since
>we all have them.
>
>A non-Forth programmer acquaintance said he thought it (Forth) wasn't
>a HLL at all - more like assembler (and he was well-versed in asm).
>Apparently even asm coders have expectations and straying too far
>doesn't go down well. Hence prefix assemblers in forth, $ prefix
>to denote a hex number, recognizers etc. When Mitch Bradley suggested
>parsers h# f# for hex and float respectively one could hear the
>proverbial pin drop. Personally I'd wear it in a forth environment but
>finding another so-inclined would be difficult. Harder still would be
>finding an app end-user that tolerated Albert's approach to command-line
>parsing. Giving end-users what they expect is the best policy. They
>don't care what language the app was written in or in making things easy
>for the programmer.
>

Seriously, what Mitch and I are doing is close to classical Forth.
I don't change any thing about parsing. I just introduce A PREFIX flag
that allows matching a dictionary entry if it is merely a prefix of
another word. The result is that `` H# 0A '' can be collated to
`` H#0A ''. The world has not noticed yet that it amounts to a netto
simplification of the Forth systems.

Groetjes Albert

[dxf]

On 5/02/2024 10:15 pm, alb...@spenarnc.xs4all.nl wrote:
> In article <upeigu$1n4af$1...@dont-email.me>, dxf <dxf...@gmail.com> wrote:
> <SNIP>
>> Perhaps not, but for me it does. Let's talk about expectations since
>> we all have them.
>>
>> A non-Forth programmer acquaintance said he thought it (Forth) wasn't
>> a HLL at all - more like assembler (and he was well-versed in asm).
>> Apparently even asm coders have expectations and straying too far
>> doesn't go down well. Hence prefix assemblers in forth, $ prefix
>> to denote a hex number, recognizers etc. When Mitch Bradley suggested
>> parsers h# f# for hex and float respectively one could hear the
>> proverbial pin drop. Personally I'd wear it in a forth environment but
>> finding another so-inclined would be difficult. Harder still would be
>> finding an app end-user that tolerated Albert's approach to command-line
>> parsing. Giving end-users what they expect is the best policy. They
>> don't care what language the app was written in or in making things easy
>> for the programmer.
>>
>
> Seriously, what Mitch and I are doing is close to classical Forth.
> I don't change any thing about parsing. I just introduce A PREFIX flag
> that allows matching a dictionary entry if it is merely a prefix of
> another word. The result is that `` H# 0A '' can be collated to
> `` H#0A ''. The world has not noticed yet that it amounts to a netto
> simplification of the Forth systems.

Not that simple if the interpreter and headers need changing. At the
time of ANS many forths already supported floats and hex in the form
we know. Changing that would require a strong argument. In practice
200x only added quoted characters. The latter being redundant it was
looks over substance.

[alb...@spenarnc.xs4all.nl]

In article <uptlcd$u5lq$1...@dont-email.me>, dxf <dxf...@gmail.com> wrote:
>On 5/02/2024 10:15 pm, alb...@spenarnc.xs4all.nl wrote:

<SNIP>

>> Seriously, what Mitch and I are doing is close to classical Forth.
>> I don't change any thing about parsing. I just introduce A PREFIX flag
>> that allows matching a dictionary entry if it is merely a prefix of
>> another word. The result is that `` H# 0A '' can be collated to
>> `` H#0A ''. The world has not noticed yet that it amounts to a netto
>> simplification of the Forth systems.
>
>Not that simple if the interpreter and headers need changing. At the
>time of ANS many forths already supported floats and hex in the form
>we know. Changing that would require a strong argument. In practice
>200x only added quoted characters. The latter being redundant it was
>looks over substance.
>

That argument backfires. ciforth contains no floating point.
Without changing "the interpreter and headers", I can add floating
point, *including* the denotations for floating point literals.
I repeat:

"
The world has not noticed yet that it amounts to a netto
simplification of the Forth systems.
"

The hex additions by $ triggered me to make this invention in the first
place. I was confronted by loads of Marcel Hendrix programs freely using
$ hex constants. There was no way I'd tolerate this pollution of the
kernel forth. So I made it a loadable extension.
Maybe we come to our senses and adopt 0x for the hex prefix, such as
used in Win32Forth. In ciforth this means change in one line in a
loadable screen:
"
: $ BASE @ >R HEX (NUMBER) R> BASE ! POSTPONE SDLITERAL ;
PREFIX IMMEDIATE
"
The change is $ --> 0x .

People that would rather not be bothered by prefixes either way,
can ignore the subject. They can keep PREFIX in the back of their mind
in case they need it. No $1 , no 0x1 .
A library sits there, and is invisible.

[mhx]

Out of curiosity: How do we postpone `` H# 0A '' ?

-marcel

[Anton Ertl]

m...@iae.nl (mhx) writes:
>Out of curiosity: How do we postpone `` H# 0A '' ?

h# 0a postpone literal

Apart from the H# this is the Forth-94 and -2012 way to postpone an
integer number.

Let's see which systems already support

: foo postpone $0a ; immediate
: bar foo ;
bar .

Gforth-0.7.3: undefined word (at the $0a)
Gforth development: bar prints 10 (as intended)
iforth (5.1-mini): $0a ?
SwiftForth x64: $0a ?
VFX 64: bar prints 10 (as intended)

Yes, I don't have the latest versions of all systems installed, let me
know if your system has learned new tricks in the meantime.

Anyway, for the fans of H#, how do you write the equivalent of
"postpone $0a" (as supported by development Gforth and VFX 64)? And
why is your equivalent better IYO?

[alb...@spenarnc.xs4all.nl]

In article <0c5c6838a692f81c...@www.novabbs.com>,

mhx <m...@iae.nl> wrote:
>Out of curiosity: How do we postpone `` H# 0A '' ?

That is the reason you don't us that type of prefixes, and
that you avoid postponing arbitrary parsing expressions.

In my book H#0A is a number and behaves the same in interpreter and
compilation mode. Same a 1.03E-10 .

>
>-marcel

[dxf]

On 8/02/2024 5:39 am, Anton Ertl wrote:
> m...@iae.nl (mhx) writes:
>> Out of curiosity: How do we postpone `` H# 0A '' ?
>
> h# 0a postpone literal
>
> Apart from the H# this is the Forth-94 and -2012 way to postpone an
> integer number.
>
> Let's see which systems already support
>
> : foo postpone $0a ; immediate
> : bar foo ;
> bar .
>
> Gforth-0.7.3: undefined word (at the $0a)
> Gforth development: bar prints 10 (as intended)
> iforth (5.1-mini): $0a ?
> SwiftForth x64: $0a ?
> VFX 64: bar prints 10 (as intended)
>
> Yes, I don't have the latest versions of all systems installed, let me
> know if your system has learned new tricks in the meantime.
>
> Anyway, for the fans of H#, how do you write the equivalent of
> "postpone $0a" (as supported by development Gforth and VFX 64)? And
> why is your equivalent better IYO?

The only system I'm aware actively using H# et al is Bradley's. It's
possible he has no use for what you ask in which case why support it?
Certainly no Forth standard has deemed it necessary and systems that
support it appear to be in the minority. If you wish you may add
DX-Forth to the list.

[mhx]

alb...@spenarnc.xs4all.nl wrote:

> In article <0c5c6838a692f81c...@www.novabbs.com>,
> mhx <m...@iae.nl> wrote:
>>Out of curiosity: How do we postpone `` H# 0A '' ?

> That is the reason you don't us that type of prefixes, and
> that you avoid postponing arbitrary parsing expressions.

Yes. Say I want to postpone a number and store it in a rewritten
colon definition. Not only do I have to parse the parsing
expression `` H# 0A '' in the original, I have to store it
in the rewritten definition as `` H# 0A '' again, because
it is too dangerous to say `` 0A '' or `` 10 '' and
of course I can't use `` $0A '' or `` #10 '', much less
`` H#0A '' :--)

-marcel

[dxf]

On 8/02/2024 1:10 am, alb...@spenarnc.xs4all.nl wrote:
> In article <uptlcd$u5lq$1...@dont-email.me>, dxf <dxf...@gmail.com> wrote:
>> On 5/02/2024 10:15 pm, alb...@spenarnc.xs4all.nl wrote:
> <SNIP>
>>> Seriously, what Mitch and I are doing is close to classical Forth.
>>> I don't change any thing about parsing. I just introduce A PREFIX flag
>>> that allows matching a dictionary entry if it is merely a prefix of
>>> another word. The result is that `` H# 0A '' can be collated to
>>> `` H#0A ''. The world has not noticed yet that it amounts to a netto
>>> simplification of the Forth systems.
>>
>> Not that simple if the interpreter and headers need changing. At the
>> time of ANS many forths already supported floats and hex in the form
>> we know. Changing that would require a strong argument. In practice
>> 200x only added quoted characters. The latter being redundant it was
>> looks over substance.
>>
>
> That argument backfires. ciforth contains no floating point.
> Without changing "the interpreter and headers", I can add floating
> point, *including* the denotations for floating point literals.
> I repeat:
> "
> The world has not noticed yet that it amounts to a netto
> simplification of the Forth systems.
> "

What is simple about H#0A ? H# 0A is simple because it requires no
system changes. But it also contradicts the notion forth understands
numbers. If it's ok for forth to differentiate doubles from singles,
why not floats, hex etc.

[mhx]

dxf wrote:
[..]

> What is simple about H#0A ? H# 0A is simple because it requires no
> system changes. But it also contradicts the notion forth understands
> numbers. If it's ok for forth to differentiate doubles from singles,
> why not floats, hex etc.

IMHO there isn't anything wrong with a standard conforming system
that has an humpty-dumpty facility to redefine or define words that
recognize `` H#0A '' for what I want it to mean.

In fact, I *expect* to be able to modify any Forth to do exactly
what I want. The `problems` with that start when I want to use
my new features in a Standard Program, or when I want to use a
Forth that has non-standard facilities that clash with my own
vision on how they should behave.

The easy way out is to wait for a standard Forth that is dumb
as a brick (no problem) but generates Vfx performance-quality code,
with a library that extends it to (e.g.) Gforth that can target
anything from standard phones to super computers.

-marcel

[Hans Bezemer]

On Wednesday, February 7, 2024 at 6:50:52 PM UTC+1, mhx wrote:
> Out of curiosity: How do we postpone `` H# 0A '' ?
>
> -marcel

I'd say: don't over complicate it:

hex
0A constant #0A
decimal

Solved.. Worst case scenario: you have to define 256 constants. But how often does THAT happen?

Hans Bezemer

[dxf]

On 8/02/2024 7:16 pm, mhx wrote:
> dxf wrote:
> [..]
>> What is simple about H#0A ?  H# 0A  is simple because it requires no
>> system changes.  But it also contradicts the notion forth understands
>> numbers.  If it's ok for forth to differentiate doubles from singles,
>> why not floats, hex etc.
>
> IMHO there isn't anything wrong with a standard conforming system
> that has an humpty-dumpty facility to redefine or define words that recognize `` H#0A '' for what I want it to mean.

How many compiler/languages support this? AFAIK if an application required
an interpreter, the programmer wrote one. That has to be better than
shoe-horning forth's interpreter to do it.

"I don't like the idea of a Forth, old or new, that does everything." - Moore

[alb...@spenarnc.xs4all.nl]

In article <18c959289e22ab30...@www.novabbs.com>,

It hurts. Don't do that.

[alb...@spenarnc.xs4all.nl]

Forth must not ony understand numbers, but all literals that come
with an application program. Used definable prefixes is ideal
for that. This contradicts nothing.

[minforth]

Flexibilty is the inportant advantage. Prefixes may simplify parsing;
iow if it helps it helps, not much to discuss there.

E.g. parsing csv tables does not need prefixes, but Forth's flexibility
and compactness helps a lot.

[dxf]

On 8/02/2024 10:43 pm, alb...@spenarnc.xs4all.nl wrote:
> In article <uq1g1t$1ln91$1...@dont-email.me>, dxf <dxf...@gmail.com> wrote:
>> On 8/02/2024 1:10 am, alb...@spenarnc.xs4all.nl wrote:
>
>> What is simple about H#0A ? H# 0A is simple because it requires no
>> system changes. But it also contradicts the notion forth understands
>> numbers. If it's ok for forth to differentiate doubles from singles,
>> why not floats, hex etc.
>
> Forth must not ony understand numbers, but all literals that come
> with an application program.

Why - what other language compiler does?

> Used definable prefixes is ideal
> for that. This contradicts nothing.

Simply saying 'I can make my compiler do that' is no reason in itself.
ISTM if it were very important end-applications carry an extensible
compiler around with them, the world - not to mention forth target
compilers - would be following the lead.

25 years ago Jeff Fox predicted:

"I see ANSI Forth [...] can become one more failed attempt to find
the ideal portable scripting language."

It was uncannily accurate.

[Anton Ertl]

dxf <dxf...@gmail.com> writes:
>> IMHO there isn't anything wrong with a standard conforming system
>> that has an humpty-dumpty facility to redefine or define words that recognize `` H#0A '' for what I want it to mean.
>
>How many compiler/languages support this?

Most Forth systems support extending the text interpreter.

Concerning other languages: I expect that Lisp and Prolog systems have
such capabilities.

>AFAIK if an application required
>an interpreter, the programmer wrote one. That has to be better than
>shoe-horning forth's interpreter to do it.

Why do you think so?

Greenspun's tenth rule is:

|Any sufficiently complicated C or Fortran program contains an ad hoc,
|informally-specified, bug-ridden, slow implementation of half of
|Common Lisp.

So, yes indeed, any sufficiently complicated application requires an
interpreter, and C and Fortran programmers write one. And the result
is bug-ridden and slow. Does not sound better to me.

>"I don't like the idea of a Forth, old or new, that does everything." - Moore

That's why we have Forth systems that are extensible.

[dxf]

On 10/02/2024 3:12 am, Anton Ertl wrote:
> ...

> Greenspun's tenth rule is:
>
> |Any sufficiently complicated C or Fortran program contains an ad hoc,
> |informally-specified, bug-ridden, slow implementation of half of
> |Common Lisp.
>
> So, yes indeed, any sufficiently complicated application requires an
> interpreter, and C and Fortran programmers write one. And the result
> is bug-ridden and slow. Does not sound better to me.
>
>> "I don't like the idea of a Forth, old or new, that does everything." - Moore
>
> That's why we have Forth systems that are extensible.

You may - but does Moore? IIRC he said Forth should be small enough that
it can be thrown away. The only reason I see for doing that is when it's
no longer fit for purpose. This, of course, contrasts with an industry
that promotes the compiler. ISTM application code written with primitives
is going be simpler and more easily altered when the time comes than code
hooked to, and reliant upon, on a specific compiler. I certainly don't
want to make my complier any more complicated than it is. I'm kind of
glad I'm at the point where I can forget about how it works (or ought to
work).

[dxf]

On 10/02/2024 3:12 am, Anton Ertl wrote:

> dxf <dxf...@gmail.com> writes:
>>> IMHO there isn't anything wrong with a standard conforming system
>>> that has an humpty-dumpty facility to redefine or define words that recognize `` H#0A '' for what I want it to mean.
>>
>> How many compiler/languages support this?
>
> Most Forth systems support extending the text interpreter.
>
> Concerning other languages: I expect that Lisp and Prolog systems have
> such capabilities.
>
>> AFAIK if an application required
>> an interpreter, the programmer wrote one. That has to be better than
>> shoe-horning forth's interpreter to do it.
>
> Why do you think so?

Because it's almost always not what you wanted. Using CATCH to stop the
interpreter aborting is a workaround. Feeding CREATE to EXECUTE-PARSING
is a workaround. Much easier to write the function you want it than to
retrofit an existing one. When complaints were made to ANS that OF was
inadequate, the response was the user can always contrive something that
OF will swallow.