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 -

looks good.

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

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

;-)

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

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

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

Kerr-Mudd, John wrote:

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

>> Hans Bezemer <the.beez.speaks@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

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

> Kerr-Mudd, John wrote:
>
> > On Mon, 29 Jan 2024 15:04:16 -0800
> > Paul Rubin <no.email@nospam.invalid> wrote:
>
> >> Hans Bezemer <the.beez.speaks@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

--
Bah, and indeed Humbug.

On 31/01/2024 8:40 pm, Kerr-Mudd, John wrote:
> On Tue, 30 Jan 2024 13:33:44 +0000
> minforth@gmx.net (minforth) wrote:
>
>> Kerr-Mudd, John wrote:
>>
>>> On Mon, 29 Jan 2024 15:04:16 -0800
>>> Paul Rubin <no.email@nospam.invalid> wrote:
>>
>>>> Hans Bezemer <the.beez.speaks@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 :)

minforth@gmx.net (minforth) writes:
>>> Hans Bezemer <the.beez.speaks@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

In article <20240130111251.79cc1c8e876a8b333cdd99d6@127.0.0.1>,
Kerr-Mudd, John <admin@127.0.0.1> wrote:
>On Mon, 29 Jan 2024 15:04:16 -0800
>Paul Rubin <no.email@nospam.invalid> wrote:
>
>> Hans Bezemer <the.beez.speaks@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 -

On Wed, 31 Jan 2024 20:55:50 +1100
dxf <dxforth@gmail.com> wrote:

> On 31/01/2024 8:40 pm, Kerr-Mudd, John wrote:
> > On Tue, 30 Jan 2024 13:33:44 +0000
> > minforth@gmx.net (minforth) wrote:
> >
> >> Kerr-Mudd, John wrote:
> >>
> >>> On Mon, 29 Jan 2024 15:04:16 -0800
> >>> Paul Rubin <no.email@nospam.invalid> wrote:
> >>
> >>>> Hans Bezemer <the.beez.speaks@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 :)
>

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.

--
Bah, and indeed Humbug.

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.

dxf <dxforth@gmail.com> writes:
>On 31/01/2024 8:40 pm, Kerr-Mudd, John wrote:
>> On Tue, 30 Jan 2024 13:33:44 +0000
>> minforth@gmx.net (minforth) wrote:
>>
>>> Kerr-Mudd, John wrote:
>>>
>>>> On Mon, 29 Jan 2024 15:04:16 -0800
>>>> Paul Rubin <no.email@nospam.invalid> wrote:
>>>
>>>>> Hans Bezemer <the.beez.speaks@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.

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.

- 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

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

> dxf <dxforth@gmail.com> writes:
> >On 31/01/2024 8:40 pm, Kerr-Mudd, John wrote:
> >> On Tue, 30 Jan 2024 13:33:44 +0000
> >> minforth@gmx.net (minforth) wrote:
> >>
> >>> Kerr-Mudd, John wrote:
> >>>
> >>>> On Mon, 29 Jan 2024 15:04:16 -0800
> >>>> Paul Rubin <no.email@nospam.invalid> wrote:
> >>>
> >>>>> Hans Bezemer <the.beez.speaks@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.
--
Bah, and indeed Humbug.

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

On 1/02/2024 4:01 am, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> On 31/01/2024 8:40 pm, Kerr-Mudd, John wrote:
>>> On Tue, 30 Jan 2024 13:33:44 +0000
>>> minforth@gmx.net (minforth) wrote:
>>>
>>>> Kerr-Mudd, John wrote:
>>>>
>>>>> On Mon, 29 Jan 2024 15:04:16 -0800
>>>>> Paul Rubin <no.email@nospam.invalid> wrote:
>>>>
>>>>>> Hans Bezemer <the.beez.speaks@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.

On 1/02/2024 1:41 am, minforth wrote:
> 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.

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

On 31/01/2024 09:59, Anton Ertl wrote:
> minforth@gmx.net (minforth) writes:
>>>> Hans Bezemer <the.beez.speaks@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
>

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

Gerry Jackson <do-not-use@swldwa.uk> writes:
>On 31/01/2024 09:59, Anton Ertl wrote:
>> minforth@gmx.net (minforth) writes:
>>>>> Hans Bezemer <the.beez.speaks@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.

- 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

In article <07897c331ad14cc94cf96ecd1a50d97b@www.novabbs.com>,
minforth <minforth@gmx.net> wrote:
>Kerr-Mudd, John wrote:
>
>> On Mon, 29 Jan 2024 15:04:16 -0800
>> Paul Rubin <no.email@nospam.invalid> wrote:
>
>>> Hans Bezemer <the.beez.speaks@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

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 -

In article <upfjl6$1vmfh$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:
>On 31/01/2024 09:59, Anton Ertl wrote:
>> minforth@gmx.net (minforth) writes:
>>>>> Hans Bezemer <the.beez.speaks@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
>>
>
>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

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 -

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

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

- 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

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.