This mornings detour was all about the return stack - or lack of return stack. In fleshing out the code I noticed that I hadn't accounted for returning from a SUB. Code in a SUB is like a SEQ, but they are 16 opcodes long because there is no 4 byte schedule header. Also like a SEQ, they aren't read into SRAM in a group, just an opcode at a time.
Whether or not I need a return stack somewhat depends on the wording I've used to describe calling & creating a SUB. In terms of memory it really only has 2 things to describe it; an instruction pointer for the current opcode position, and an A-register for scratch use. SUBs also need to track their caller (the aforementioned missing return stack), because it need not be the running SEQ. The obvious way is to simply strip off the last running record from the execution list, which is the same as a 'return'.
The description of the instruction pointer needs to describe:
- what memory it's in [two or three bits]
- what page of that memory [0..255] has it
- the element of that page [0..31]
- the opcode number [0..15]
- any flags (four bits?)
If the A-reg is included in this description, that's four bytes long, so we can store the environment. The only thing we need to add is a master pointer to know which 4-byte record is the 'end'.
In terms of SRAM use, 256 bytes would be 64 calls deep. In the spirit of 'Nobody will ever use 640k of RAM', I think that's plenty. For now.
write up the keywords.txt and example for the XEEPROM library, and test it all out
- Write up something that manages the 4 byte structs for describing execution state. Library?Plain array? Library, I think.
organize the reg[ ] array into config and run entries. Those entries that are only used during setup() don't have to be copied in memory. I should be able to save about 32 bytes of SRAM this way.
- copy the sun position schedule currently in a FLASH_ARRAY into some of the unused low bytes of internal EEPROM. I think it fits between the reg and MAP.
sift thru the current spreadsheet of opcodes and stuff all the blocking calls into one group so we can flag those in the sequence generator - in case we need to run those as 'exclusive'.
- I had an idea to wrap the stock LCD library so we can include references to a string_table for option-list type fields. Currently it's all numeric. Smells like scope creep.
- UPDATE: Forgot the August 31 deadline for autonomous operations. Dang.