I do have a current ARM7-based (LPC2366) hardware that is currently in production.

The firmware contains a huge amount of configuration options to allow different actions to be performed depending on different stimuli.

But I can't teach the current firmware all kinds of logic actions, filtering and data analysis, so I want a customer (normally not an end user, but someone who buys 100-1000 volume or more) to be able to specify their own actions.

If it was just logic, then I could implement PLC ladder logic or similar, but I don't want just logic but want the user to be able to add filter logic, numeric analysis of ADC data etc.

I do not have the slightest need for emulating any existing processor. Just to have access to a good GP programming language that is reasonably commonly known, and that is very frugal with RAM. This includes quite a lot of procedural languages, but excludes most object-oriented languages. Java, for example, can consume huge amounts of RAM even for very tiny applications.

Having the host processor run with a MMU would protect its data from being overwritten, but would leave a lot of other problems open.

If run with an embedded RTOS, the customer extensions would need to run in individual low-priority tasks, and the main application would have to export quite a lot of internal symbols, requiring the need for dynamic linking.

The host processor is not meant to be big enough to run Linux or any other full-blown OS, where the customer just adds one more stand-alone application to run. It is - and is expected to continue to be - a single-chip I/O processor, where all processor pins are spent connecting to existing hardware. It's just that I want to give it the ability to be configured with advanced filtering/decision making.

It should be noted that the processor needs hard real time, and not all RTOS supports dynamic linking or running of free-standing processes.

The currently used processor is a LPC2366 (in total 58kB RAM), which is the reason why a major criteria is a small RAM footprint. The processor may potentially be changed into a LPC2387 (98kB RAM) or possibly, but unlikely, a LPC24xx chip. But only if it can be shown that such a component switch will result in a very wide acceptance to pay more for the unit. Besides the redesign costs, it takes huge amounts of money to certify a unit in a large number of countries. An in reality, customers are expected to pay less for new products, or to get more features for the same price. The possibility to run plugins should be seen as an optional extra, not as a primary feature that may have a significant priority when it comes to the hardware design.

If the target machine had been running Windows or Linux, I would probably have looked at Java, JavaScript, Lua or something similar, but this is a quite small guy that may in some situations spend a significant amount of time trying to sleep, to conserve power.

A software-only solution means that the production costs are not affected, and that licensing costs for the extra capability can be negotiated with an interested customer.

The I2L interpreter sounds very promising, since it is likely that it was designed for ease of porting and for a good execution speed in the host hardware. That not too many existing customers (probably none) knows XPL0 is a bit of a gotcha, but the advantages may win over the disadvantages.

The XPL0 home page didn't mention anything about I2L, and you had to more or less know what to look for in the language manual.

I did write in my original post "unless someone can point at any good C compiler that can generate code for an abstract machine", thinking about this kind of solution, even if I would have preferred a C compiler.