Lua Compact Debug (LCD)

[TerryE]

#74 refers.

Lua Compact Debug (LCD). What this patch does is to eliminate 90% of the overhead of using lua source execution rather than stripped binary luac.cross files. It's also stable on nodeMCU.

Read the whitepaper for the full description, but whatthis patch does is to allow the developer to trim (at compile time) what debug information is retained. At the normal level(2) only lineinfo is retained so tracebacks still work. The difference is that instead of the overhead being ~ 4N where N is the number of instructions, it's roughly 1M where M in the number of non-blank source lines. What this means in effect that the debug "overhead" drops to roughly 5% of what its is for an unmodified RTS. The runtime impact is negligible for normal code.

This is working stably on the nodemcu fork, but it seems to me that this would be of wider elua interest.

[bogdanm]

Before I look into this further, please help me understand the architecture of the ESP8266 better. I know it's a Harvard machine, but is it a modified one, such that it can access data from the program memory space directly (like ARMs do)?

[TerryE]

@bogdanm, the patch makes no particular assumptions of the target architecture. In fact as I said in the whitepaper, I developed this first as a standard Lua patch (see my Lua fork), getting a 100% pass at the strongest level of the Test Suite before porting it to the ESP. Also this operates on the Lua VM binary which sits in RAM anyway. It makes its RAM savings by:

• building and using a run length encoded scheme for mapping the PC to source line number which takes roughly one byte per non-blank source line rather than 4 bytes per instruction. This has no material runtime penalty, except making the calculation of line numbers during error traceback O(N).
• optionally stripping out debug info at the end of each the compile. The upvalue and local name metadata is maintained and needed for the compile, but it is only used thereafter for debugging. If you aren't going to use the debug hook, then this can be safely dropped.

However, to your Q re the memory architecture of the ESP8266, it's sort of modified. There is a true ROM, a pseudo ROM, RAM and Flash in different address regions of the same address space. The boot ROM copies a (<32Kb) fixed region of flash into RAM (pseudo-ROM), and this is accessed at full memory band with. There is 48Kb RAM. The normal flash program memory itself is mapped through a 1st level cache in RAM. In this last case cache-miss lines are primed at roughly 13×slower than RAM bandwidth (for QIO flash and 26× for the DIO flash), but cache hits run at full RAM bandwidth so the average slowdown for running Flash code might only be 2× or less. The only other oddity is that non-word-aligned data access cache-misses from Flash throw an exception with this LX06 implementation, and in this case we've added a S/W-based exception handler to prime the cache and restart the instruction, but in practice these exceptions rarely happen.

The Lua firmware runs out of Flash program memory, the Lua itself runs out of RAM. Separate to this is a SPIFFS. I don't do anything clever with allowing Flash Program Memory based LC files, or the like. Dropping the RAM utilisation of Lua programs by ~40% is enough for now 😄

[bogdanm]

Dropping the RAM utilisation of Lua programs by ~40% is enough for now 😄

Hard to debate that! 😄 I asked about the Hardvard thing because I wanted to understand if it's not easier to simply read all the debug information directly from flash, but you're right, your patch applies to a larger context. I'll definitely look at it more.
Also, thanks a lot for the details about the ESP8266 architecture. I tried to google for that previously, but got a lot of confusing information. I won't say that I understood everything now, but it's certainly better than before :)

[TerryE]

No apologies needed. IMO, the Espressif guys are just too paranoid about their proprietary content. So far, too much public info is based at hackers chipping away and retro-engineering the details of the architecture. It would certainly make our life easer in the nodemcu community if we had copies of the ESP8266 SDK source available (even under NDA) as well as decent first-source H/W specs.

The language issue is also a factor here. I am a native English speaker, and so (like most English and Americans) I take for granted that any educated engineer will have god use of English -- which is pretty arrogant really. My grandkids are probably going to have to be fluent in Mandarin! 😆