Hacker News Reader

Comment by shortsightedsid | Hacker News Reader

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 are really cool and are a realistic alternative to C.

View on HN

> 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/ 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_s... Be careful, it's a subtle chip and I only deal with the basics.

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.

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.

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.

> 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/mikropascal/

http://www.astrobe.com/default.htm

http://www.adacore.com/gnatpro/embedded

http://www.ptc.com/developer-tools/apexada

http://www.ghs.com/products/ada_optimizing_compilers.html

Zero lines of C.

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/

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...

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.

Actually, I might get the wrong picture but from FOSDEM talks and high integrity conferences programms, I get the opposite view.

The same can be said of Lisp and Forth. Would you call them fringe?

> OTOH, I am immediately suspicious of any product that claims it's professional and also has BASIC in the name...

For many years the Elektor magazine and a few other competing ones, had the listings of electronic stuff done in Assembly, Basic and Turbo Pascal.

Before Raspberry PI was a thing, many developers were using Basic STAMP.

https://www.parallax.com/catalog/microcontrollers/basic-stam...

I'm aware, but... urgh. Yuck. I don't think BASIC causes brain damage, but I also don't think it's a very nice thing to work in.

Although I suppose it does depend on the dialect, to an extent...

Some years ago when Java was relatively new, I had come across this company Esmertec, which was making Java toolchains for embedded devices. Site seems to be still there, not sure about the company:

www.esmertec.com

You are right. I completely forgot about ADA and representative clauses. I remember reading that representative clauses mapping to register fields. And to be fair, basic and pascal also can be used for bare metal stuff.

Ada isn't a dynamic language, so it doesn't really apply here; you don't get to use it in the ways like Forth; like having a boot ROM with an Ada REPL (laugh).

Of course there are other systems programming "monolithic executable" programming languages that allow straightforward access to memory mapped hardware registers.

Static languages can have REPLs.

They can, but I'm not even sure you'd be able to fit all of Ada's reserved words in a typical boot ROM ;)

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.

> Any realistic alternative to C must understand interrupts, memory mapped registers etc..

In what way does C understand interrupts?

Borland C used to, and I believe OpenWatcom still does. Haven't seen any other one that did for a long time.

Most C compilers do, but those are language extensions, not defined on the language's standard thus not portable across compilers.

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.

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.

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...

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

Reply on news.ycombinator.com