Hi Ricardo Fernández Serrata,

re stack, new elements added to array begin: Thank you, I'll try. Indeed, adding them to array end makes more sense in most case but one: top of stack is addressed most frequently - and by keeping it in stack[0], I thought to avoid arithmetics for access. But indeed, being able to adress them by negative index from the end avoids arithmetics too.

Forcing results numeric with + is the result of running into problems with 0 not being -0 and the remnant of wanting to make sure I'm not comparing strings. Please refer to Funny -0 flow - the probably superfluous "+" served to exclude possible other error causes. Just noticing that you replied there: I also didn't benchmark the different methods, but believe that ~(expr)+1 isn't that bad for my specific case of changing sign, while running into 0 as result sometimes. This should be preferable over conditional branching, as it consists of one bitwise complement and one increment operation only. That's rather efficient, at least on CPU- and machine instructions level. abs I rather avoid, as it's an Automate function rather than merely an operator, chances are that additional procedure nesting is done. You may have noticed that I still employ this pedestrian method of two's complement forming in the VM.

re jsonDecode, that could indeed speed up program loading, when program is compiled with the external compiler, as it is now. But consider that the intention is to let the VM run its own compiler, in which case the program fed to the VM will be lines of source code, rather than compilation tokens. In that case will the compiler possibly be represented as a long series of assignments to elements of an array in a single block (if yet unknown length restrictions don't thwart that attempt), rather than being loaded as tokens from a file. Serving as ballpark figure could serve the smallest compiler of that kind I yet fabricated (a meta compiler, actually, able to compile its own source code) which took about 2.5 kB of code, or one written in bash, with about 2000 lines of code (but with a number of unneeded extras), another in Perl (about 1500 LOCs). These are all similarily virtual machine based, like the Automate one. The count also includes those primitives which already exist in the Automate VM as blocks, therefore is the actual LOC count the the compiler lower. I estimate the resulting size of the array carrying the compiler around 1000 elements. Loading ("binary") programs from json would then only be good with already precompiled and saved programs.

re bytecode: There's more involved than only these <64 primitives. It's true that the number of primitives is low, and will never get beyond a count with can be expressed by 8 bits. For practical purposes, that should be "7 bit" as an opcode extension mechanism would be needed: constants, variables, well, data structures in general, primitives, high level code are all represented in an identical way to the (so called) inner interpreter. Changing that representation to 8 bit tokens limits the total number of representable items, unless an extension mechanism is added. Such as, a single bit distinguishing between byte code tokens and other items, represented differently. Considering that, the higher level the code becomes, the fewer (byte code) primitives are used, and the more will it consist of other higher-level items, as level of abstraction increases. Now consider also that gain from byte codes only happens where those execute, but the penalty of increased inner interpreter complexity will be present throughout every level of code. You may have ignored here that a program running on the VM does not only consist of these primitives. In a real world system, the total primitives count is indeed low enough for expressing them as byte codes. But the total number of items is about always surpassing the 8 bit representable count by far. I think I rather stick to the resulting simplification of the inner interpreter, by rendering it unnecessary to distinguish between type of any of those. Not doing so would either introduce a serious limitation (256 items), or require additional complexity by having to express some (potentially many) items as something different than 8 bit tokens. Btw, there exists a "real world" system using byte codes for many of these primitives, and a different representation for most of the rest. That system is called "Java VM" :)

I can, if you wish, incorporate your comments into my replies. That way you'll not run out of text space while keeping context intact. You notice that I don't feel bound by any comment size limit.

Or you can simply join Automate telegram group