6 ms·

Forth is super cool for embedded work. The normal dev cycle of build, burn, not work, tweak, build, burn, repeat is quite slow and annoying. It was kind of revo

Forth is super cool for embedded work. The normal dev cycle of build, burn, not work, tweak, build, burn, repeat is quite slow and annoying. It was kind of revolutionary for me to discover Mecrisp[0], which demonstrates how can provide a (fast!) language that also provides a friggin' repl into your hardware. The ##forth IRC channel on Libera is quite active. Would recommend popping in for anyone interested. The two projects that got me interested in Forth are 1. JonesForth: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth.S;hb=HEAD http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth... Explanation and motivation for the What and Why of Forth and its implementation. Well, actually, it's actually an implementation in x86 assembly, but the comments are a wonderful exposition and intro into Forth. 2. SmithForth: https://dacvs.neocities.org/SF/ https://dacvs.neocities.org/SF/ Implementation of Forth in x86-64 opcodes. It's a hand-written ELF that implements a Forth. It's simplicity is absolutely beautiful. SmithForth is what pushed me over the edge to really start learning x86 assembly and Forth. I started by hand-decompiling the SmithForth binary, which was quite an adventure on its own. [0]:https://mecrisp.sourceforge.net/ https://mecrisp.sourceforge.net/

kragen 3y ago
you probably can't use amd64 in embedded work, or even i386 these days, but i think 'a friggin' repl into your hardware' is a good explanation of what's appealing about forth
- actionfromafar 3y ago
  Sure you can, lot's of custom x86 boards with vxWorks on them out there.
  - kragen 3y ago
    there are at least some, especially on very old machines
    - actionfromafar 3y ago
      Not sure what you mean by this. There are Atom-like boards, and Core i7 boards with BSPs and everything in between. Bringing up a custom system isn't that hard either.
      - kragen 3y ago
        yeah but basically nobody uses them. intel canceled edison five years ago https://hackaday.com/2017/06/19/intel-discontinues-joule-galileo-and-edison-product-lines/ https://hackaday.com/2017/06/19/intel-discontinues-joule-gal... the comments on that article from people who tried to use their boards are scathing (the link to the not-yet-discontinued curie in that article is now a broken link, and the link https://communities.intel.com/community/tech/intel-curie https://communities.intel.com/community/tech/intel-curie from https://github.com/arduino/ArduinoCore-arc32 https://github.com/arduino/ArduinoCore-arc32, which hasn't been updated in 5 years, says 'The core node you are trying to access is permanently deleted.' https://www.intel.la/content/www/xl/es/products/sku/96282/intel-curie-module-intel-quark-se-soc/specifications.html https://www.intel.la/content/www/xl/es/products/sku/96282/in... says it's discontinued.) this is very different from 30 years ago when pc104 boards were all over the place. pc104 is not completely forgotten but pc104 and vmebus are pretty well eclipsed by raspberry pi, esp32, arduino, gumstix, and plain stm32 and avr8 designs, increasingly even in non-hobbyist designs. can and i2c have displaced isa/eisa and sometimes even rs422 so if you are doing embedded work you probably will not be able to use amd64 or i386 and thus jonesforth or smithforth or stoneknifeforth. but the principles do apply
- vanderZwan 3y ago
  I think I posted an almost identical reply to you just a few days ago, but I'm presuming they linked the x86 examples because most people can actually try them without needing said embedded hardware
  - kragen 3y ago
    oh, sorry i missed it
    - vanderZwan 3y ago
      Oh no sorry, I didn't mean it as a critique, haha! I just thought this was a funny deja vu. It was this little comment exchange in a post linking a free x86-64 assembly book: k: it probably teaches more than everything i know about amd64 assembly, except the most important thing, which is that arm assembly is much better vdZ: I'm sure many architectures are nicer than amd64, but that's what the CPU in my laptop uses, as well as my Steam Deck. If I want to get into low-level hacking it's easiest to start with the hardware I have, no? k: yup, no use looking for your keys in the rose garden if you know you dropped them in the sewer https://news.ycombinator.com/item?id=38760386 https://news.ycombinator.com/item?id=38760386
      - kragen 3y ago
        haha, yep! i guess it's worth mentioning with qemu-user that you can totally run arm code on amd64 hardware, though sometimes things work that shouldn't, so it's not an ideal testing environment. i did a demo of this last year in https://asciinema.org/a/622461 https://asciinema.org/a/622461
        vanderZwan 3y ago
        > though sometimes things work that shouldn't Lol, so basically "undocumented opcodes, emulator edition"?
        kragen 3y ago
anta40 3y ago
Are there non-embedded Forth use cases these days? I tried almost a year learning Forth due to curiosity and still don't "get" it. As a HLL guy, for me Lisp is more understandable (well I don't use it for daily work, though). And if I need low level, well there's assembly.
sph 3y ago
Someone linked to me FreeForth, a Forth that doesn't have any compile / interpret distinction. Everything is compiled, and if run interactively, words are first compiled into anonymous "function" and then run, which has a lot of benefits; such as allowing compile-only words at the REPL. I haven't heard anyone talk about or recreate this variant, which to me seems a very interesting evolution of the original Forth. Nor has anyone tried to recreate it in something more readable than a thick assembly implementation that's trying to be a little too smart for its own good.

kragen 3y ago

you probably can't use amd64 in embedded work, or even i386 these days, but i think 'a friggin' repl into your hardware' is a good explanation of what's appealing about forth

actionfromafar 3y ago
Sure you can, lot's of custom x86 boards with vxWorks on them out there.
- kragen 3y ago
  there are at least some, especially on very old machines
  - actionfromafar 3y ago
    Not sure what you mean by this. There are Atom-like boards, and Core i7 boards with BSPs and everything in between. Bringing up a custom system isn't that hard either.
    - kragen 3y ago
      yeah but basically nobody uses them. intel canceled edison five years ago https://hackaday.com/2017/06/19/intel-discontinues-joule-galileo-and-edison-product-lines/ https://hackaday.com/2017/06/19/intel-discontinues-joule-gal... the comments on that article from people who tried to use their boards are scathing (the link to the not-yet-discontinued curie in that article is now a broken link, and the link https://communities.intel.com/community/tech/intel-curie https://communities.intel.com/community/tech/intel-curie from https://github.com/arduino/ArduinoCore-arc32 https://github.com/arduino/ArduinoCore-arc32, which hasn't been updated in 5 years, says 'The core node you are trying to access is permanently deleted.' https://www.intel.la/content/www/xl/es/products/sku/96282/intel-curie-module-intel-quark-se-soc/specifications.html https://www.intel.la/content/www/xl/es/products/sku/96282/in... says it's discontinued.) this is very different from 30 years ago when pc104 boards were all over the place. pc104 is not completely forgotten but pc104 and vmebus are pretty well eclipsed by raspberry pi, esp32, arduino, gumstix, and plain stm32 and avr8 designs, increasingly even in non-hobbyist designs. can and i2c have displaced isa/eisa and sometimes even rs422 so if you are doing embedded work you probably will not be able to use amd64 or i386 and thus jonesforth or smithforth or stoneknifeforth. but the principles do apply
vanderZwan 3y ago
I think I posted an almost identical reply to you just a few days ago, but I'm presuming they linked the x86 examples because most people can actually try them without needing said embedded hardware
- kragen 3y ago
  oh, sorry i missed it
  - vanderZwan 3y ago
    Oh no sorry, I didn't mean it as a critique, haha! I just thought this was a funny deja vu. It was this little comment exchange in a post linking a free x86-64 assembly book: k: it probably teaches more than everything i know about amd64 assembly, except the most important thing, which is that arm assembly is much better vdZ: I'm sure many architectures are nicer than amd64, but that's what the CPU in my laptop uses, as well as my Steam Deck. If I want to get into low-level hacking it's easiest to start with the hardware I have, no? k: yup, no use looking for your keys in the rose garden if you know you dropped them in the sewer https://news.ycombinator.com/item?id=38760386 https://news.ycombinator.com/item?id=38760386
    - kragen 3y ago
      haha, yep! i guess it's worth mentioning with qemu-user that you can totally run arm code on amd64 hardware, though sometimes things work that shouldn't, so it's not an ideal testing environment. i did a demo of this last year in https://asciinema.org/a/622461 https://asciinema.org/a/622461
      - vanderZwan 3y ago
        > though sometimes things work that shouldn't Lol, so basically "undocumented opcodes, emulator edition"?
        kragen 3y ago

anta40 3y ago

Are there non-embedded Forth use cases these days? I tried almost a year learning Forth due to curiosity and still don't "get" it. As a HLL guy, for me Lisp is more understandable (well I don't use it for daily work, though). And if I need low level, well there's assembly.

sph 3y ago

Someone linked to me FreeForth, a Forth that doesn't have any compile / interpret distinction. Everything is compiled, and if run interactively, words are first compiled into anonymous "function" and then run, which has a lot of benefits; such as allowing compile-only words at the REPL. I haven't heard anyone talk about or recreate this variant, which to me seems a very interesting evolution of the original Forth. Nor has anyone tried to recreate it in something more readable than a thick assembly implementation that's trying to be a little too smart for its own good.