Sectorforth is a 16-bit x86 Forth that fits in a 512-byte boot sector (2020) | Hacker News Reader

Sectorforth is a 16-bit x86 Forth that fits in a 512-byte boot sector (2020)

github.com

55 pointssigalor16 comments

I love both Forth and Lisp but SectorLisp it's far better.

Also, for a small demo, check Eforth under Subleq/Muxleq:

edit subleq.fth/muxleq.fth and set these options to 1:

   1 constant opt.multi      ( Add in large "pause" primitive )
   1 constant opt.editor     ( Add in Text Editor )
   1 constant opt.info       ( Add info printing function )
   0 constant opt.generate-c ( Generate C code )
   1 constant opt.better-see ( Replace 'see' with better version )
   1 constant opt.control    ( Add in more control structures )
   0 constant opt.allocate   ( Add in "allocate"/"free" )
   1 constant opt.float      ( Add in floating point code )
   0 constant opt.glossary   ( Add in "glossary" word )
   1 constant opt.optimize   ( Enable extra optimization )
   1 constant opt.divmod     ( Use "opDivMod" primitive )
   0 constant opt.self       ( self-interpreter [NOT WORKING] )

Then run this to create a new EForth image with float/do...loop and such:

   ./muxleq ./muxleq.dec < muxleq.fth > new.dec

Subleq is the original one, muxleq it's multiplexed. The command it's the same, just replace muxleq with subleq (edit the fth file too).

Usage: ./muxleq new.dec

For a brief help:

     words

On Forth syntax, the EForth Overview PDF will be enough, except for 8086 related code, where here it's different.

Any opinion on which Forth implementation is good for 8-bit CPUs, in particular 8051?

Your own. And I'm not joking.

No, it makes sense now that you say it. :)

It's not large.

For every person that uses forth for something even a little bit more elaborate rolling your own is a rite of passage. I highly recommend it because it will get rid of the 'turtles all the way down' feeling that typical modern day software development gives. Once you get it working and you want access to a richer environment you can always choose to layer another 'ready made' thing on top of your own or to build your own environment out. But FORTH is an acquired taste, you can't just hop to github or apt-get install something to give you a particular large and battle tested library. It's more akin to watchmaking or jewelry than herding cattle.

C64: https://github.com/jkotlinski/durexforth

It's impressive what you can do in the C64 with just Forth instead of C64 Basic.

For Speccy/ZX80/ZX81, I'm pretty sure they ported the Jupyter ACE one, boosting up the available RAM in the 48k and 128k making Basic almost obsolete in that platform.

Eight primitives and a colon compiler in 512 bytes is a nice demonstration of how much you can bootstrap from almost nothing. The examples building up from there are the best part.

Really shows how approachable it would have been to have just a tiny bit more added to the API of 'PC BIOS' to make for an extremely portable driver platform system to allow OS independent arbitrary hardware drivers as Forth that the system BIOS could compile at boot and run beneath the OS. Though of course the PC BIOS API from when that mattered isn't in anything like a modern protect mode operating profile.

PC BIOS was mostly just for DOS and bringup, it also helped in moving stuff across the barrier during 32 bit boot but afterwards the only thing you would normally use it for is to call hardware specific ROMs for instance for mode changes and such. The rest of the time you'd avoid it like the plague (also because of the expensive switch back to 'real' mode).

X86 asm as she is intended to be wrote. `repe cmpsb` for symbol table string comparison, etc.

Similar to this project: https://github.com/fuzzballcat/milliForth

The ZEROEQUALS function can be replaced by: pop ax; neg ax;sbb ax,ax;push ax

It's nice to see that has a brainfuck interpreter. I wrote a lisp compiler recently, then used that to write a lisp interpreter, and in both cases have a version of brainfuck in it.

That said interpreting the brainfuck mandelbrot program takes several hours. On an old CP/M system I have a brainfuck compiler that converts a program to Z80 machine code, and that same mandelbrot example runs in less than two seconds.

So speed isn't great, but having brainfuck really proves a toy system is "real".

2020

Not that impressive considering this uses BIOS routines heavily and whole operating systems including basic interpreter fit in a couple of KiB

512 bytes is quite a bit less than "a couple of kilobytes"

It's much better than 512, it fits in 336 bytes iirc.

Reply on news.ycombinator.com