Re: SUBLEQ and EForth

On 2025-05-14, Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 14-05-2025 11:31, anthk wrote:

Run it as ./subleq ./subleq.dec

>
I can't - it complains:
>
$ pp4th -x subleq.4th < subleq.dec
Error: Not a 16-bit SUBLEQ VM
>
Hint - no, it's not YOUR subleq interpreter ;-)
>
Hans Bezemer
>
>

Yes, it's not mine; but I understand it fine.
You need a 16 bit wide VM for Subleq. Most of them
from Howe (if not all) work as is. The fastest
one OFC it's the C one (altough the gawk and
mawk ones can be really good for being interpreted
languages, much faster than the Perl VM,
which I extended for muxleq (and avoiding
creating stating variables with "my" every
loop, which is far slower than globally
declaring a variable and giving a new value).

Still,  GAWK (and MAWK even more)  emulating a Subleq VM ran much
faster than Perl doing a Muxleq one.

Also, as for...next, I have it under
PForth for testing some code. Hackey, but it's fine:

: >MARK ( --A ) HERE 0 , ;
: AHEAD ( --A ) COMPILE branch >MARK ; IMMEDIATE
: AFT ( a --a A ) DROP [COMPILE] AHEAD [COMPILE] BEGIN SWAP ; IMMEDIATE

: FOR ( RUNTIME: N -- )
        COMPILE ABS  \ NO NEGATIVES
        COMPILE LIT 0 , COMPILE SWAP
        [COMPILE] ?DO ; IMMEDIATE

: NEXT
        COMPILE LIT -1 ,
        [COMPILE] +LOOP ; IMMEDIATE

I spawn pfe as "pforth -q -i ~/.pferc" and most of the stuff
on eforth runs on pforth, except for the weird float syntax
Also I found some double multiplying works missing, so
I tried to set ones in my own by looking up
elsewhere, as I'm still learning Forth with the
ANS Forth web book from Leo Bordie.

: t* tuck um* 2swap um* swap >r 0 d+ r> rot rot ;
: t/ dup >r um/mod rot rot r> um/mod nip swap ;
: m*/ >r t* r> t/ ; ( d n n -- d * n / n )
: d* 1 m*/ ; ( d d -- d * d )
: d/ 1 swap m*/ ; ( d -- d / d )

Hacky, but it works. I didn't find issues on using
'integers' and doubles as arguments for m*/ and
the double words bound to that.

Yes, Eforth under subleq it's slow, but usable;
and with muxleq the CPU usage plummets down.

Would it run fast under a physical CPU made of TTL's?
IDK, but the Minix 2 under http://magic-1.org it's fairly usable
at 4MHZ and running vi and even ed it's far more CPU
intensive than a Forth; so in the they would be pretty even.

But what I'd love it's some EForth for the Magic-1 CPU,
a native one, even with multiple users support.

No, not for Minix 2, native. It could run faster than
a Unix-like I'd guess. No Rogue, nor advent; but these could
be rewritten. Maybe even with less complexity than a C+Yacc
maze madness. Yes, it would use more storage, even with blocks,
but the code size would be smaller.

A floppy sized storage would allow tons of extra free size
for applications.

AWK? Forth. ed? Trivially reimplemented for editing blocks.
Unix pipes/composability? Forth words.
Copy and mv would be implemented
in the same way on a screen basis.
No directories, no timestamps, no FS.
Accesing serial ports it's barely a single step
over parsing them in Unix as files.

On multitasking:

https://www.bradrodriguez.com/papers/mtasking.html

So, this can be fun if the Magic-1 autor gets into it.
At least he won't need to target a new compiler/linker
and tons of C headers/libraries to match his new arch :D

Oh, and maybe the terminals won't lock as often as it
happened under ed while editing as simple gopher client
as it happened to me. Not vi, ed.