Patches created with XOD seem to compile and work OK on the ATTiny series of AVRs (at least the variants like the ATTiny85 with larger amounts of Flash memory), via copy and pasting the generated code into the Arduino IDE (v 1.8.3) using Spencer Konde’s ATTinyCore library for that environment:
Two small changes I made to the generated source to get it to work were to first #include <stddef.h>, and second to redefine “typedef double Number” to be “int16_t” instead, as compiling with support for floating point significantly increases the Flash memory usage. I don’t know if that change will break some XOD core modules, but it appears to work OK for simple patches.
With link-time optimization enabled on an ATTiny85 the “Blink” patch + XOD overhead compiles to about 2k Flash usage, plus 60 bytes of SRAM.
That will be a problem in more complex cases. Many things rely on fractional numbers. you’ve seeded an idea in my mind. What if a node could make a hint like “I use only integers”, “I use 0-1 range with at most 0.001” resolution”… In that case, the transpiler would be able to choose an optimal type for data interchange. Very raw idea worth investigation.
BTW, “Look what I’ve done” category is intended to collect some kind of “complete” achievements. Would you mind to add a GIF, short MP4, or even a photo to the post to give an instant feel to topic readers? One picture worth 1000 words.
Experimenting more I’ve found that probably the overhead as far as Flash usage is concerned for the floating-point is not that bad on the ATTiny; in a test with LTO enabled and a simple patch multiplying two analog input values together (no way for the compiler to optimize that!) the difference between using a 4 byte double and a two byte int, plus overhead for the math routine is only a couple hundred bytes.
The real killer is the SRAM usage, the ATTiny85 series only has 512 bytes, and when using patches that have “Number” internal state when Number is a double that gets eaten up pretty quick!
Might also be worth investigating using some kind of fix-16 fixed-point implementation for smaller devices with a two byte int as the fundamental type, ideally all the conversions, casting, shifting etc. could be macros and would be mostly transparent to the user, and not add significant runtime overhead.
you’ve seeded an idea in my mind. What if a node could make a hint like “I use only integers”, “I use 0-1 range with at most 0.001” resolution”… In that case, the transpiler would be able to choose an optimal type for data interchange. Very raw idea worth investigation.