> There are Java and Oberon implementations for single digit MB, like Cortex-M4.

So? Just because you can use a language on a given system doesn't mean that you should use it in any serious context.

A GC typically makes memory usage and execution latency non-deterministic, or at the least very hard to analyze. If your washing machine software OOMs whenever the GC didn't run between two button pushes, you'll have a great Heisenbug.

Well, I happen to consider factory control management, weapon targeting and missile tracking systems, some big serious context.

Here is just one of them.

http://www.militaryaerospace.com/articles/2006/10/lockheed-m...

"PERC Ultra offered Lockheed Martin the responsiveness it needed to meet its most demanding timing requirements. In addition to real-time threading and deterministic garbage collection, PERC Ultra provided the instrumentation and VM management tools necessary to support the mission-critical real-time requirements of the Aegis Weapon System."

"The Lockheed Martin-developed Aegis Weapon System is the sea-based element of the U.S. Ballistic Missile Defense System. The Aegis Weapon System is a radar and missile system integrated with its own command and control system, capable of simultaneous operation defending against advanced air, surface, and subsurface threats."

Is that serious enough for you?

Is this where we bring in the anecdote about the missile flight control system which never freed any memory, because the minumum time to OOM was less than the maximum flight time of the missile?

Ask and ye shall receive[0].

[0] https://news.ycombinator.com/item?id=14233542

> A GC typically makes memory usage and execution latency non-deterministic, or at the least very hard to analyze.

You could say same about malloc and free. Not deterministic at all either. Memory fragmentation is a huge issue as well, and can bring down the whole system.

Typical GC (not all flavors) has a huge advantage on microcontrollers: you gain ability to compact heap. No more fragmentation.

That said, mostly I try not to dynamically allocate anything in firmware or kernel drivers. Whenever possible. Sometimes I write my own specialized allocators. For example a simple wait free allocator fast and rugged enough to call from an interrupt service routine.

> Only if talking about microcontrolers with few hundred KB, where even C is a challenge.

C is the default and not a challenge on 8-bitters.

So which compiler does offer 100% ANSI C compliance on something like a Z80 or PIC?

SDCC is standard compliant (even up to C11) and has support for Z80: http://sdcc.sourceforge.net/

Thanks for pointing it out, I wasn't aware of it and it does look good, but they clearly state the uses cases which it isn't fully ANSI C compliant on page 24 of the documentation.

I think you're nitpicking.

That's close enough in my book. Those MCUs are tricky targets and I can certainly live for example with not being able to pass structs as return values. Or without re-entrancy. Perfectly understandable once you take into account limited IRAM space, 128 or 256 bytes, where stack, register banks and most of your temporaries and globals need to reside.

Which validates my point of using C on 8 bit CPUs being a challenge.

"Less than absolutely total standard compliance" != "a significant challenge compared to absolutely total standard compliance", especially if the differences are clearly documented.

The challenge is not being able to write idiomatic ANSI C, rather trying to tame the compiler to produce code comparable to hand tuned Assembly to fit into those processors, the majority of time using compiler specific extensions.

You're sounding like a propagandist - like you want to just argue your talking points, rather than actually have a conversation where you listen to what the other side is actually saying. It makes you a real pain to talk to.

Just in case you're actually trying to engage in good faith, though, I'll try this one more time. If I have a compiler that is less-than-100% standards compliant, I may not be able to use a few features of the standard. That means there may be a few ANSI C idioms that I can't use. Of those, the number that I would choose to use on that size of processor is very, very few. So in practice, there is no "challenge".

Why would I use very few of these features? Because on a processor that size, you're not writing a huge app. You don't use all the functions in the standard library, you don't use all the keywords, you usually don't push the language very far at all. At worst, you might have to develop one or two idioms of your own. It's... mildly annoying, rather than the big deal you're trying to make it.

It is not a challenge, it is by far the most common way to program them.

Yeah not being able to write idiomatic ANSI C, rather trying to convince the compiler to produce code comparable to hand tuned Assembly to fit into those processors, the majority of time using compiler specific extensions.

SDCC is also full of bugs and the compiled code is not well optimized. For a low level CPU like that, you have to write assembly at some point.

I wrote smaller programs with it for a Z80 home computer which originally didn't have C support. I didn't encounter bugs, but it's true that the code generation is less than optimal for Z80 when compared to manually written assembly (understandable because of the small register set), but the compiler supports mixing assembly and C very well, so no complains here :)

Literally the whole industry doesn't care two bits about "100% ANSI C compliance", which I'd guess isn't even possible on a pure Harvard architecture like AVR or PIC.

Even the ESP8266, where ram & flash are measured in kilobytes can run a minimal version of python. This whole "low resource can't run heavy languages" trope needs to die.

Comparison of a sensor fusion algorithm the likes of which are used in quadcopters:

| impl | c | py3 | mpy | pypy3 | cy3 |

|------|-------|--------|---------|-------|-------|

| [ns] | 0.176 | 11.462 | 37.633 | 0.818 | 0.590 |

| .c | 1.000 | 65.126 | 213.824 | 4.648 | 3.352 |

mpy - MicroPython

cy3 - Cython

So, ... low resource can't run heavy languages fast (yet?). Good thing is by using MicroPython and writing the time critical stuff in C you can get the best of both worlds while paying the least.

edit: sigh, markdown table

If you add two spaces in front of each line, it formats as monospace. Like this:

  | impl | c     | py3    | mpy     | pypy3 | cy3   |
  |------|-------|--------|---------|-------|-------|
  | [ns] | 0.176 | 11.462 |  37.633 | 0.818 | 0.590 |
  | .c   | 1.000 | 65.126 | 213.824 | 4.648 | 3.352 |

Also, I'm taking a guess here and assuming that the values in the second line mean "execution time as multiples of the execution time for C".

Yes, it was `*c`, but the star screwed up formatting even more ;)