3 ms·

As someone who felt that C was the path to knowledge for how modern computer systems "work", Forth and QEMU have become my "stretch challenge" for those with th

As someone who felt that C was the path to knowledge for how modern computer systems "work", Forth and QEMU have become my "stretch challenge" for those with the motivation to tinker. For me, working thru the resources on the OSDev wiki by taking jonesforth and linking it with the bootstrap from the "Writing an OS in Rust" tutorial (https://os.phil-opp.com/ https://os.phil-opp.com/) really showed me how far C is from the hardware, and how much closer Forth connects to the idiosyncrasies of a computer system. Further, the immediacy of the Forth REPL can help with little experiments and building up the understanding of how much a machine's architecture influences code/data structures, opcode choice, privilege management, etc. Plus, understanding Forth will bend your brain in a very strange but positive way :)

stochastic_monk 8y ago
I’m convinced that Forth is a valuable intellectual exercise. Can you elaborate on how you feel Forth better matches how a computer actually works? I’m not yet convinced on that point, but I have no Forth experience.
- mjevans 8y ago
  The most fun, in a tinkering sense, that I've ever had with low level programming was in a variant of Forth (within Minecraft, years ago when the mod that included it was still up to date). That experience made me regret that Forth wasn't part of my formal education experience: it is a wonderful slightly above assembly language. Forth is what should be included in a BIOS as the absolute lowest level interpreted language. A basic machine abstraction could be made by using only interpreted functions/procedures and that could be used to bootstrap add-in routines for attached hardware. It would be very possible to write low level bootstrap drivers that could be used on any architecture providing the specification (including some interface hooks for defining how to register and use an IO interface).
  - rhn_mk1 8y ago
    I'm not sure if you're posting this with awareness, but for the public benefit I'll say that this had been done, ages ago indeed. https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware I've had the pleasure to interact with it while trying to get a SPARC Ultra 60 workstation to work. The driver hooks missing from most modern hardware meant that not all graphics cards could be used with full support - currently BIOS drivers provided on some PCI hardware (RAID, network adapters) are only for the x86 architecture. I forgot what they are called though...
- sharkbot 8y ago
  It would be my pleasure :) I'll refer to jonesforth [1], but I think the lessons apply to the other Forth's I've seen. The main core of a Forth is generally written in assembly to bridge the specifics of a processing unit and the canonical Forth words. For instance, most control flow words are defined in Forth, but a couple critical ones are implemented in assembly and "exported" up to the higher level words. [2] The main task of the core is to bootstrap to a sufficiently powerful yet abstract dictionary of words that will allow a full Forth to flourish. But to get there, you'll have to make a lot of choices that will be constrained by your chip (Intel x86, x86_64, ARM, Z80, etc). The big one is type of interpreter (direct threaded, indirect threaded, etc). In jonesforth, check out the docs and implementation of NEXT [3]. The choice was guided by a quirk of the Intel instruction set that allowed loading the memory pointed by esi into eax and incrementing esi all in one step; further, Intel x86 allows an indirect jump to the address stored in a register (eax). Not all instruction sets support this pattern, you'll have to experiment and investigate for various chips. That choice is a critical one, but it's one of many. Where do you store the dictionary of words? How do you implement DOCOL? What registers will you preserve? Why? What instructions will you expose? Which ones will you hide? Will you allow new words to be created with machine code? In C, much of this has been decided by others decades ago (existing operating system ABI choices, mainly). In Forth, you can try things out and only be restricted by the chips, which is what all of us are ultimately constrained by, even fancy-pants languages like Rust and Go :) Once you get past the core into Forth, some of the computer details recede, but you usually have to be somewhat aware of how you are using the system, far more than modern programming languages. Forth is the ultimate deep-dive "language" [4], but that is as much a curse as a blessing. Basically, use Forth for the understanding it provides, then go back to making good software in typical languages aided by the enlightenment you've attained :) [1] https://github.com/nornagon/jonesforth/blob/master/jonesforth.S https://github.com/nornagon/jonesforth/blob/master/jonesfort... [2] https://github.com/nornagon/jonesforth/blob/master/jonesforth.S#L1989 https://github.com/nornagon/jonesforth/blob/master/jonesfort... [3] https://github.com/nornagon/jonesforth/blob/master/jonesforth.S#L227 https://github.com/nornagon/jonesforth/blob/master/jonesfort... [4] I've actually stopped calling Forth a programming language; programming system captures the idea a little better, I find.
bigmit37 8y ago
Thank you for this =)
mturmon 8y ago
I agree about the benefits of a Forth-like language for tinkering. It's still very simple (like C), but the execution model is totally different, simpler, and more functional/mathematical. I learned the HP programmable calculator version of Forth as one of my first languages, and I loved programming in that model. I think one's brain loses some flexibility if it hasn't programmed in a nonstandard model from an early time.
AtomicOrbital 8y ago
back in the 1980's when I first got into programming I wrote a 3D flight simulator in Forth ... terrific language ... loved teaching myself how to construct multi-dimensional data structures when the language itself only offered 1D arrays ... back pre-internet folks had to roll up their sleeves and write the plumbing level logic themselves unlike today with endless libraries at hand
Karrot_Kream 8y ago
Do you have the source to your OS bootstrap code + jonesforth? I'd love to play around with that.
- sharkbot 8y ago
  It's hard to share, unfortunately, but I would recommend trying it out yourself regardless. The journey was more rewarding than the destination, at least for me. In my case, the destination was a very simple Forth interpreter that read input from the serial port and sent a single packet over the virtual NIC interface. There are so many ways to go, that just happened to be my choice.

stochastic_monk 8y ago

I’m convinced that Forth is a valuable intellectual exercise. Can you elaborate on how you feel Forth better matches how a computer actually works? I’m not yet convinced on that point, but I have no Forth experience.

mjevans 8y ago
The most fun, in a tinkering sense, that I've ever had with low level programming was in a variant of Forth (within Minecraft, years ago when the mod that included it was still up to date). That experience made me regret that Forth wasn't part of my formal education experience: it is a wonderful slightly above assembly language. Forth is what should be included in a BIOS as the absolute lowest level interpreted language. A basic machine abstraction could be made by using only interpreted functions/procedures and that could be used to bootstrap add-in routines for attached hardware. It would be very possible to write low level bootstrap drivers that could be used on any architecture providing the specification (including some interface hooks for defining how to register and use an IO interface).
- rhn_mk1 8y ago
  I'm not sure if you're posting this with awareness, but for the public benefit I'll say that this had been done, ages ago indeed. https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware I've had the pleasure to interact with it while trying to get a SPARC Ultra 60 workstation to work. The driver hooks missing from most modern hardware meant that not all graphics cards could be used with full support - currently BIOS drivers provided on some PCI hardware (RAID, network adapters) are only for the x86 architecture. I forgot what they are called though...
sharkbot 8y ago
It would be my pleasure :) I'll refer to jonesforth [1], but I think the lessons apply to the other Forth's I've seen. The main core of a Forth is generally written in assembly to bridge the specifics of a processing unit and the canonical Forth words. For instance, most control flow words are defined in Forth, but a couple critical ones are implemented in assembly and "exported" up to the higher level words. [2] The main task of the core is to bootstrap to a sufficiently powerful yet abstract dictionary of words that will allow a full Forth to flourish. But to get there, you'll have to make a lot of choices that will be constrained by your chip (Intel x86, x86_64, ARM, Z80, etc). The big one is type of interpreter (direct threaded, indirect threaded, etc). In jonesforth, check out the docs and implementation of NEXT [3]. The choice was guided by a quirk of the Intel instruction set that allowed loading the memory pointed by esi into eax and incrementing esi all in one step; further, Intel x86 allows an indirect jump to the address stored in a register (eax). Not all instruction sets support this pattern, you'll have to experiment and investigate for various chips. That choice is a critical one, but it's one of many. Where do you store the dictionary of words? How do you implement DOCOL? What registers will you preserve? Why? What instructions will you expose? Which ones will you hide? Will you allow new words to be created with machine code? In C, much of this has been decided by others decades ago (existing operating system ABI choices, mainly). In Forth, you can try things out and only be restricted by the chips, which is what all of us are ultimately constrained by, even fancy-pants languages like Rust and Go :) Once you get past the core into Forth, some of the computer details recede, but you usually have to be somewhat aware of how you are using the system, far more than modern programming languages. Forth is the ultimate deep-dive "language" [4], but that is as much a curse as a blessing. Basically, use Forth for the understanding it provides, then go back to making good software in typical languages aided by the enlightenment you've attained :) [1] https://github.com/nornagon/jonesforth/blob/master/jonesforth.S https://github.com/nornagon/jonesforth/blob/master/jonesfort... [2] https://github.com/nornagon/jonesforth/blob/master/jonesforth.S#L1989 https://github.com/nornagon/jonesforth/blob/master/jonesfort... [3] https://github.com/nornagon/jonesforth/blob/master/jonesforth.S#L227 https://github.com/nornagon/jonesforth/blob/master/jonesfort... [4] I've actually stopped calling Forth a programming language; programming system captures the idea a little better, I find.

bigmit37 8y ago

Thank you for this =)

mturmon 8y ago

I agree about the benefits of a Forth-like language for tinkering. It's still very simple (like C), but the execution model is totally different, simpler, and more functional/mathematical. I learned the HP programmable calculator version of Forth as one of my first languages, and I loved programming in that model. I think one's brain loses some flexibility if it hasn't programmed in a nonstandard model from an early time.

AtomicOrbital 8y ago

back in the 1980's when I first got into programming I wrote a 3D flight simulator in Forth ... terrific language ... loved teaching myself how to construct multi-dimensional data structures when the language itself only offered 1D arrays ... back pre-internet folks had to roll up their sleeves and write the plumbing level logic themselves unlike today with endless libraries at hand

Karrot_Kream 8y ago

Do you have the source to your OS bootstrap code + jonesforth? I'd love to play around with that.

sharkbot 8y ago
It's hard to share, unfortunately, but I would recommend trying it out yourself regardless. The journey was more rewarding than the destination, at least for me. In my case, the destination was a very simple Forth interpreter that read input from the serial port and sent a single packet over the virtual NIC interface. There are so many ways to go, that just happened to be my choice.