I did not study the variable handling close enough, but I expect a memory area where actually the metadata about the variable is kept - last but not least for garbage collection and the like - and that part stays put (has fixed address) - I expect or hope... I know: in science and technology, only fools hope :). But anyway...
The pointer overwriting the variable name in the source I was thinking of would point to the location of the meta data and not the location where the actual value is. Since I do not know how the space of the variable metadata is organized (where var creates the metadata), it may add some challenges. For example, if it is a linked list - just as so many things seem to be in Espruino (for better or worse) - it is still a look up... so no gain, just pain.
The linked-list concept makes me just now think that the meta data may be a 'memory address in-line' header of the actual variable data, and all is a linked list with explicit (pointers) or with implicit (length) linking for the lookup. Separation of the variable meta data from the actual value data make a partial JIT possible... (That's what I did in my OO VMs in order to have resolved references... that are fast, random - array like - accessible).
There are usually not infinite places for a 'contiguous, growing/shrinking' memory space... and the separation asks just for one more... In addition, one more pointer has to be hosted per variable which points from the meta data to the value data. Furthermore, more discrete items in memory waste more bytes since they do not all align with the memory block boundaries... which confirms the truth that speed costs space. For some defined data types - such as int, boolean, float (and natively implemented objects of known fixed lengths), the meta data can also include the values and there is no need for pointing into the 'wild' (dynamically) managed memory space.
While writing this post, I conclude that Espruino does not separate variables' meta-data form variable data, and going for a separation is a major concept change: a new Theory of Operation.
@DrAzzy's idea is NOT THAT knee-jerk: remember Rockwell's 6502... a processor breath life into Commodore's PET and Apple I and on is still very a-live, and what did this thing do - more precisely - what where the architects of it thinking? Let's treat the first 256 memory locations / (single bit addresses) be handled differently: let's treat them as general registers! A brilliant hybrid choice for a time when (memory and processing) resources weren't commodities yet... and about the same I feel with Espruino. And I used the Wang Computers which used a similar approach: Variable names would always start with an uppercase and be followed by a digit 0 thru 9. Ending with a $ denoted one of the two only available data types: Strings. The other data type was a number (of course - last but not least it was 'a computer' - Wang 2200 T, starting out from a Wang 370 desk calculator). Wang 2200 T was a TTL implementation with 18 bit word format and 7483 based ALU and memory was blankets of blankets of RAM chip 'cards'.
Usually, i like pure, consistent implementations, but with what is at stake and can be achieved 'here' with very limited resources asks for a bit more flexibility, creativity,... (going for that single letter variable thing, may mess a bit with the minifiers..., but after all it could be quite a boost. It could though start a 'war of claims': who owns which variable... because they are global and exist only once!
© Espruino, powered by microcosm.
Report a problem