I am currently at ca 13Kb Flash usage and 1Kb SRAM usage. SRAM usage can be adjusted, but Flash usage is fixed and will increase with definition of more build-in stuff. This is on a CISC, so I am not 100% sure how that convert to a RISC MCU, but it looks decently good. I notice that expressions bloat a bit so I might need to do a trade-off and simplify expressions or investigate smarter ways of coding. A typical trick to save Flash is to move logic to tables. I do as an example have a lot of strncmp() in if functions that can be optimized for a lower footprint. But, it is not exactly critical yet. My objectice is below 20Kb. I am aware that PBASIC was implemented in 8Kb back in 1978 using assembly, but this is not BASIC. PScript is actually a full, proper programming language despite the “script” part of the name.
One option that is possible is to extend the Interpreter later to support full Plain syntax as an Interpreter. And to be honest – it is not that far from having an Interpreter to building a compiler. The difference is that in an Interpreter I execute as I parse, in a compiler I need to output the stack as byte code. Lets see. I did not intend to let this grow into a full Plain, but I see the option. I will need far more than 20Kb for full Plain syntax however.
I am also coding in C++, and my expreience witg GCC on STM32 is that I quickly reach 64Kb. I have suffered Flash starvation on 32Kb and 16Kb devices and been forced to switch to C. I have never investigated the reasons as I believe this can be sorted with some GCC tricks – I have a friend that is more specialized on this that I can ask. But, I think a minimum requirement of 128Kb Flash is ok these days.
One option that I consider is for Plain to skip the C/C++ stage and compile straight to assembly. It is years since I even touched assembly and it’s a huge difference between generating C/C++ code versus generating assembly. The later will require that I generate for every single MCU and handle the differences. But, it is possible. The advantage will be smaller footprint as every automation step will bloat, but the advantages of using C/C++ as a middle step is so many that I doubht it will be worth it. Lets finish PScript and see where we go because this is just an experimental break from BSA at the moment.
A bit back to PScript footprint – I think 20Kb is ok if I can maintain that and it actually looks good – I think I have ca 75% of the code in place and the full Interpreter with comments will be < 2000 lines of code. It will be a nice component to add in on a CLI.