[vardump]

Could this be used for embedded development? Currently C is used pretty much universally for this purpose. While C is better than straight assembler, it seems to be very prone for bugs, especially when there are multiple developers and over time in maintenance phase.

Something safer is desperately needed for embedded firmware development. Lack of such a language is already affecting physical safety of end user devices.

Something that can run for example on a microwave oven, car engine control, digital thermometer and industrial machinery.

Maybe I'm missing some, but some of the most important wish list items I can think of right away:

- High readability, Golang-like "understandability"

- Anywhere between 1 - 256 kB of RAM, 2 - 1024 kB of program ROM.

- Must have C-like code density and performance, but a small loss is acceptable in exchange for better safety.

- Ability to implement IRQ service routines, etc. low level code.

- Array access, pointer and type safety.

- Debugging support... this is a tricky one.

- Migration assist from C code. Doesn't need to be perfect, just to assist where ever feasible.

- Would be very nice: Some language level support for duplicating and checking critical variables in memory. Like those for controlling servos etc. physical. To improve end user physical safety.

Targets should include at least, in order of importance:

- ARM thumb-2 (like Cortex M0)

- Altera NIOS 2 (must be possible to modify easily to target custom instructions)

- 8051

Various Atmel architectures, MIPS and OpenRISC would also be nice.

But I guess it comes down to LLVM support for those platforms.

[dom96]

I think that Nim satisfies many of the items on your list. Have you taken a look at it?

Specifically, it's a very good C replacement as it compiles to C. So you can easily run it on all of those embedded architectures.

While I must admit that it leans towards using a GC for memory safety, you can disable it and use Nim as a more readable C easily. If you're brave you can attempt to use Nim's GC in embedded hardware too, it's very flexible.

If you want statically guaranteed memory safety then do check out Rust, I'm assuming you already have though and dismissed it for some reason.

[vardump]

Yeah, Nim is one of the languages I'm interested in.

> Specifically, it's a very good C replacement as it compiles to C. So you can easily run it on all of those embedded architectures.

Yes, this is indeed a huge plus for this application.

>If you're brave you can attempt to use Nim's GC in embedded hardware too, it's very flexible.

I'm not going to be that brave. :)

> If you want statically guaranteed memory safety then do check out Rust, I'm assuming you already have though and dismissed it for some reason.

Static guarantees are good, less code and checking at runtime. I haven't dismissed Rust in any way. One huge bonus point for Rust is that it has a major organization, Mozilla, behind it. Of course, the fact that Mozilla is primarily interested to develop a web browser can be a liability. In the future, Rust might take a path that's less suitable for embedded firmware.

[minthd]

If you're willing to be stuck with a specific architecture(xcore by xmos) ,they offer their XC language and tools ,which are very good your requirements:

a actor model like language for the xcore mcu. supports actors(paralell tasks with communication chnnels, pattern matching on "events", assigning actors to diffeent "cores"-hw threads, boundary checks on arrays, special pointers(aliased/restricted) with good error messages, type checking, mostly compatible with c(except pointers)

Debugging is very good: Regular debugger, xScope - a virtual scope/logic-analyzer with access to internal states.XTA Timing analyzer - can determine(i think statically) the worse case timing between any 2 points in code. xScope and XTA might also work in simulation mode.

This complements well with their architecture ,which basically allows real-time without jitter, and with very high accuracy/speed, through usage of multiple virtual cores.

Very well fitted to industrial environment, and maybe they would be willing to add your request for memory duplication of variables , because it fits their niche.

[vardump]

Sounds very good and interesting. But vendor lock-in and architecture restriction is unacceptable. Embedded firmware development needs something that can be targeted to existing platforms.

[minthd]

Ah, OK.

BTW ,this guy[1] is already using/playing with rust for mcu's. maybe he found a way to make it work for ISR's ?

[1]http://spin.atomicobject.com/2015/05/21/generate-embedded-ru...