7 ms·

I'm a embedded software dev and write code all day in C. Sure enough forth comes up in conversations once in a while as does other ideas like Python, JS, Lua et

I'm a embedded software dev and write code all day in C. Sure enough forth comes up in conversations once in a while as does other ideas like Python, JS, Lua etc.. Of all the alternatives to C, Forth is the only one which groks hardware. This is particularly important for embedded development. Any realistic alternative to C must understand interrupts, memory mapped registers etc.. Forth is the only one in which this is possible. Every other example I've seen always uses C for "low-level" access or a libraries. If you need to do that, then you won't win over embedded devs like me. It's much easier to write good embedded C code (no mallocs etc) than having to debug FFI. Having said all that, my mind doesn't understand Forth. I'm too used to seeing code in C or even assembly to fully understand Forth. Nevertheless things like https://github.com/jeelabs/mecrisp-stellaris https://github.com/jeelabs/mecrisp-stellaris are really cool and are a realistic alternative to C.

ekidd 10y ago
> Any realistic alternative to C must understand interrupts, memory mapped registers etc.. Forth is the only one in which this is possible. Every other example I've seen always uses C for "low-level" access or a libraries. Forth is a great little language, and a perfect example of how to to do a surprising amount with very little. For more complicated embedded work, however, I've been deeply impressed with Philipp Oppermann's tutorial on writing a kernel in Rust: http://os.phil-opp.com/ http://os.phil-opp.com/ You have to limit yourself to Rust's "core" library (instead of the usual "std"), and you won't have a heap until you write one, but it's surprisingly nice. Well, except for debugging double faults. That's never nice. :-/ Here's my toy PIC 8592 interface in pure Rust: https://github.com/emk/toyos-rs/tree/master/crates/pic8259_simple https://github.com/emk/toyos-rs/tree/master/crates/pic8259_s... Be careful, it's a subtle chip and I only deal with the basics.
- qwertyuiop924 10y ago
  Yeah, but Rust is much more complex than Forth, and really hates baremetal: you can do baremetal in Rust, but it's idiomatic to minimize contact. That works really well in some cases: OS work, for example. But if you're working in a raw microconroller, you're going to be touching metal constantly, and you won't want anything you don't use slowing you down. In short, Rust is great, but it doesn't beat Forth in Forth's biggest problem space: programming embedded systems under exceptionally tight size/speed constraints.
  - armitron 10y ago
    Not to mention that Rust is not interactive and doesn't allow for dynamic, incremental development. Forth brings the rapid, extremely tight feedback loop one sees in Lisp or Smalltalk to hardware. Comparing it to Rust is missing this point entirely. Finally, let's not forget that Forth has been empirically validated multiple times in this domain (e.g. NASA has used Forth on board satellites and spacecraft). Rust is entirely unproven in the hardware/microcontroller space (some would say in general), so I tend to view posts like ekidd's ("for more complicated embedded work") as projecting/wishful thinking.
    - qwertyuiop924 10y ago
      Good point: I was going to bring this up, but I already had in another post, and I didn't think anybody who wanted rust on their hardware wouldn't care, as they quite clearly liked compiled languages. But this is a huge draw for Forth, speaking as a Lisp user.
pjmlp 10y ago
> Forth is the only one in which this is possible. Every other example I've seen always uses C for "low-level" access or a libraries. If you need to do that, then you won't win over embedded devs like me. Not really. https://www.mikroe.com/mikrobasic/ https://www.mikroe.com/mikrobasic/ https://www.mikroe.com/mikropascal/ https://www.mikroe.com/mikropascal/ http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm http://www.adacore.com/gnatpro/embedded http://www.adacore.com/gnatpro/embedded http://www.ptc.com/developer-tools/apexada http://www.ptc.com/developer-tools/apexada http://www.ghs.com/products/ada_optimizing_compilers.html http://www.ghs.com/products/ada_optimizing_compilers.html Zero lines of C.
- vidarh 10y ago
  AmiBlitz (the Amiga Blitz Basic version) is another - you can write M68k assembler anywhere in a program, as they're legal AmiBlitz syntax. http://www.amiblitz.de/ http://www.amiblitz.de/
- qwertyuiop924 10y ago
  Is there any reason he would have heard of those? They're all pretty fringe, arguably moreso than Forth, for some of them. Some of these do look neat: I've had an interest in both Ada and Oberon, although I haven't been able to get over the verbosity and unpleasant syntax of either (it's not COBOL, or anything, but it's not nice). OTOH, I am immediately suspicious of any product that claims it's professional and also has BASIC in the name...
  - jnbiche 10y ago
    Ada is not fringe. It's used by many large companies, although less and less these for new projects these days. There are some huge Ada codebases being maintained in industry, particularly in the aviation industry.
    - pjmlp 10y ago
      Actually, I might get the wrong picture but from FOSDEM talks and high integrity conferences programms, I get the opposite view.
junke 10y ago
What is an embedded dev's view of Ada, by the way? (out of sheer curiosity)
pixpop 10y ago
> Any realistic alternative to C must understand interrupts, memory mapped registers etc.. In what way does C understand interrupts?
- kayamon 10y ago
  Borland C used to, and I believe OpenWatcom still does. Haven't seen any other one that did for a long time.
  - pjmlp 10y ago
    Most C compilers do, but those are language extensions, not defined on the language's standard thus not portable across compilers.
    - Turing_Machine 10y ago
      Yep. If nothing else, just about all of them have the asm keyword. That's non-standard (but almost always present) in C compilers, and "conditional" in C++ (i.e. the keyword is in the standard, but the semantics are implementation-defined). And yeah, it's a given that it's going to be non-portable. Given asm, implementing a Turbo C-style int86() function seems pretty trivial. It might even be doable as a macro.
      - pjmlp 10y ago
        I loved the asm way in PC compilers used to support inline asm. asm { mov ax, 0x0013 int 0x10 } Can't really like the way clang and gcc asm work, even it it means giving more info to the optimizer.
        groovy2shoes 10y ago
        Not to mention that you could just use C identifiers in the asm block willy-nilly: int foo(int c) { int r; asm { mov ax, 0x0b00 int 0x21 /* poll stdin for input */ mov ax, offset c /* get address of `c` */ call bar /* call other C function */ mov r, dx /* save the result in `r` */ } return r; } Or something like that — it's been a while. Those were the days! GCC's (and I'm assuming clang's is much the same) inline assembly is a joke in comparison. I remember, when I first encountered it, flipping back-and-forth through the GCC docs looking for how people actually do inline asm with GCC...
kazinator 10y ago
I wrote a proprietary app in Lisp (using Clozure Common Lisp) for Windows. In the licensing code, I needed to get the list of network adapters and also the volume ID of the installation drive. It was easy to call the Win32 functions directly. Note that enumerating the adapters requires walking linked list of C structures returned by the GetAdaptersInfo function (to which you have to specify an allocated memory buffer where that list will be stored.) I did that all in Lisp; not a line of C.

ekidd 10y ago

> Any realistic alternative to C must understand interrupts, memory mapped registers etc.. Forth is the only one in which this is possible. Every other example I've seen always uses C for "low-level" access or a libraries. Forth is a great little language, and a perfect example of how to to do a surprising amount with very little. For more complicated embedded work, however, I've been deeply impressed with Philipp Oppermann's tutorial on writing a kernel in Rust: http://os.phil-opp.com/ http://os.phil-opp.com/ You have to limit yourself to Rust's "core" library (instead of the usual "std"), and you won't have a heap until you write one, but it's surprisingly nice. Well, except for debugging double faults. That's never nice. :-/ Here's my toy PIC 8592 interface in pure Rust: https://github.com/emk/toyos-rs/tree/master/crates/pic8259_simple https://github.com/emk/toyos-rs/tree/master/crates/pic8259_s... Be careful, it's a subtle chip and I only deal with the basics.

qwertyuiop924 10y ago
Yeah, but Rust is much more complex than Forth, and really hates baremetal: you can do baremetal in Rust, but it's idiomatic to minimize contact. That works really well in some cases: OS work, for example. But if you're working in a raw microconroller, you're going to be touching metal constantly, and you won't want anything you don't use slowing you down. In short, Rust is great, but it doesn't beat Forth in Forth's biggest problem space: programming embedded systems under exceptionally tight size/speed constraints.
- armitron 10y ago
  Not to mention that Rust is not interactive and doesn't allow for dynamic, incremental development. Forth brings the rapid, extremely tight feedback loop one sees in Lisp or Smalltalk to hardware. Comparing it to Rust is missing this point entirely. Finally, let's not forget that Forth has been empirically validated multiple times in this domain (e.g. NASA has used Forth on board satellites and spacecraft). Rust is entirely unproven in the hardware/microcontroller space (some would say in general), so I tend to view posts like ekidd's ("for more complicated embedded work") as projecting/wishful thinking.
  - qwertyuiop924 10y ago
    Good point: I was going to bring this up, but I already had in another post, and I didn't think anybody who wanted rust on their hardware wouldn't care, as they quite clearly liked compiled languages. But this is a huge draw for Forth, speaking as a Lisp user.

pjmlp 10y ago

> Forth is the only one in which this is possible. Every other example I've seen always uses C for "low-level" access or a libraries. If you need to do that, then you won't win over embedded devs like me. Not really. https://www.mikroe.com/mikrobasic/ https://www.mikroe.com/mikrobasic/ https://www.mikroe.com/mikropascal/ https://www.mikroe.com/mikropascal/ http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm http://www.adacore.com/gnatpro/embedded http://www.adacore.com/gnatpro/embedded http://www.ptc.com/developer-tools/apexada http://www.ptc.com/developer-tools/apexada http://www.ghs.com/products/ada_optimizing_compilers.html http://www.ghs.com/products/ada_optimizing_compilers.html Zero lines of C.

vidarh 10y ago
AmiBlitz (the Amiga Blitz Basic version) is another - you can write M68k assembler anywhere in a program, as they're legal AmiBlitz syntax. http://www.amiblitz.de/ http://www.amiblitz.de/
qwertyuiop924 10y ago
Is there any reason he would have heard of those? They're all pretty fringe, arguably moreso than Forth, for some of them. Some of these do look neat: I've had an interest in both Ada and Oberon, although I haven't been able to get over the verbosity and unpleasant syntax of either (it's not COBOL, or anything, but it's not nice). OTOH, I am immediately suspicious of any product that claims it's professional and also has BASIC in the name...
- jnbiche 10y ago
  Ada is not fringe. It's used by many large companies, although less and less these for new projects these days. There are some huge Ada codebases being maintained in industry, particularly in the aviation industry.
  - pjmlp 10y ago
    Actually, I might get the wrong picture but from FOSDEM talks and high integrity conferences programms, I get the opposite view.

junke 10y ago

What is an embedded dev's view of Ada, by the way? (out of sheer curiosity)

pixpop 10y ago

> Any realistic alternative to C must understand interrupts, memory mapped registers etc.. In what way does C understand interrupts?

kayamon 10y ago
Borland C used to, and I believe OpenWatcom still does. Haven't seen any other one that did for a long time.
- pjmlp 10y ago
  Most C compilers do, but those are language extensions, not defined on the language's standard thus not portable across compilers.
  - Turing_Machine 10y ago
    Yep. If nothing else, just about all of them have the asm keyword. That's non-standard (but almost always present) in C compilers, and "conditional" in C++ (i.e. the keyword is in the standard, but the semantics are implementation-defined). And yeah, it's a given that it's going to be non-portable. Given asm, implementing a Turbo C-style int86() function seems pretty trivial. It might even be doable as a macro.
    - pjmlp 10y ago
      I loved the asm way in PC compilers used to support inline asm. asm { mov ax, 0x0013 int 0x10 } Can't really like the way clang and gcc asm work, even it it means giving more info to the optimizer.
      - groovy2shoes 10y ago
        Not to mention that you could just use C identifiers in the asm block willy-nilly: int foo(int c) { int r; asm { mov ax, 0x0b00 int 0x21 /* poll stdin for input */ mov ax, offset c /* get address of `c` */ call bar /* call other C function */ mov r, dx /* save the result in `r` */ } return r; } Or something like that — it's been a while. Those were the days! GCC's (and I'm assuming clang's is much the same) inline assembly is a joke in comparison. I remember, when I first encountered it, flipping back-and-forth through the GCC docs looking for how people actually do inline asm with GCC...

kazinator 10y ago

I wrote a proprietary app in Lisp (using Clozure Common Lisp) for Windows. In the licensing code, I needed to get the list of network adapters and also the volume ID of the installation drive. It was easy to call the Win32 functions directly. Note that enumerating the adapters requires walking linked list of C structures returned by the GetAdaptersInfo function (to which you have to specify an allocated memory buffer where that list will be stored.) I did that all in Lisp; not a line of C.