TelosTelos
commented
3 years ago I guess I'm inclined towards making the default be inline compilation (i.e. putting another copy of the function body everywhere the function gets called, with no need for jumps and little need for argument copying), since that'll be preferable the vast majority of the time, in a context where processor cycles are usually going to be our most limiting resource.
I think it may be worth offering some sort of @outofline decorate to allow creation Python-like out-of-line functions in the rare circumstances where those are needed, mostly (a) circumstances where the function is too long to put all compilations of it inline without exceeding the 1000-instruction cap, and/or (b) circumstances where the function calls itself recursively (either directly or via some intermediary). Circumstance (b) would generate an easily detectable infinite loop during compilation of an inline function, which could pop a compiler error recommending defining one or more of the offending functions @outofline instead. Unfortunately, by the time we detect this, it may be hard/arbitrary to choose which offending function(s) to move outofline, and it'd be be hard to undo previous inline compilations without just restarting the compiler, so probably better to pop an error and make the user responsible for the choice.
One tricky issue involves the question of whether or not inline defs should be allowed to change the value of variables given as arguments to the function -- i.e. of whether inline defs should be "macros" or "functions". Consider the following def.
def inc(x):
x += 1
return xWhen construed as an ordinary function, inc(y) would leave y itself unchanged, and return the value y+1. Construed as a macro, inc(y) would increment the value of y to y+1, and also operate as this new value in a larger expression (i.e., x = inc(y) would be equivalent to the C expression x = ++y.) Macros produce more efficient mlog code (fewer assignments of variables to values) but are less familiar than functions to Python coders (though objects passed to functions do behave in almost this way in Python).
My inclination here is to say that whatever we do is going to be a bit unfamiliar, so we may as well go with the most efficient and most generally useful option, and explain it. So I'd lean towards macros. With functions, its practically impossible to get macro-like efficiency. In contrast, with macros, it's trivial to get function functionality: just use 0+y as the argument, rather than y itself, since this has the very same effect of making this instance of the def operate on some temp variable whose value is set to be a copy of y. E.g., inc(0+y), would compile as pseudocode temp = 0+y; inc(temp) which leaves y itself unchanged. So implementing defs as macros quite straightforwardly makes both options available to coders, both with pretty close to maximal efficiency, with the only drawback being needing to remember to use 0+ to protect an argument from being changed, when wanted.)
Lonami
Probably the most controversial change I've been thinking about making is removing the stack, which (0) currently is used only as a conduit for passing arguments and return-lines to functions. The primary alternatives are (1) to pass function arguments and return-lines via variables, of which mindustry offers an unlimited supply, and/or (2) to treat functions as "inline" macros. I'm just posting pro's and con's here before pulling the trigger on this.
In favor of (0) using a stack: Putting return-lines on the stack allows recursive functions to return back up the chain to whatever initially called them. Currently there is no real advantage to putting arguments on the stack, but eventually this might allow for functions that pass an open-ended list of *args, or this might help with giving each recursion its own independent namespace. There would be an advantage to making function namespaces and recursion match the way they work in Python (as long as it runs acceptably fast, which I doubt it will). Quick math: pushing+popping an argument/linenumber takes three more instructions than simple variable setting (push+change_pointer+pop+change_pointer --vs-- set). To implement namespaces, we'd also need 4 instructions per "local" variable that will be allowed to have different values in different namespaces. There may be some ways of trimming a few of these (e.g. I think the current code manages to skips two back-to-back pointer changes in each call) but most of this will be unavoidable).
Against (0) using a stack: a stack requires an associated memory cell, and it requires extra instructions, both in total program length and while running. The current use of a stack kind of gives us the worst of both worlds: recursion and namespaces don't work in the standard Python way, yet it still needs a memory block and is needlessly slow. If we set it up so these really did work as they do in Python, it would be even slower, prohibitively slow for strategic purposes in game (though maybe there would be some hope that optimization passes could streamline some of this, but that'd take more work than I'm willing to put into it!). So long as we need coders to learn that Pyndustric functions don't work quite the same as Python functions, we may as well choose a system for them to learn that will be efficient and well-suited to the strategic purposes of people who are trying to write useful mlog programs.
Option (2) inline macros would be even more efficient than (1) passing via variables, as this trims jumps and argument-setting on both the calling end and returning ends. The only real drawbacks of (2) inline macros (as compared to (1)) are (a) that inline macros are a tiny bit trickier for us to code (since you have to replace arguments within the function body), and that for longer functions they'll add more to the total instruction count, which will risk running into the 1000-instruction cap. But my guess is that 90%+ of uses, these would just be flat out better, so if we were to support just one of these, (2) would probably be the way to go.
We needn't necessarily choose just one. We could allow a choice between these options with an
@decoratorsyntax, or we could attempt to automatically detect which is best. Auto detection of global-vs-local variable use in a function is a pain but probably doable. True recursion requires a stack at least for return-lines. Non-stack functions are almost always better inline, modulo questions about whether you want to be able to read the argument-variables again outside the function, except in the case where you need to put long functions out-of-line to stay under the 1000-instruction cap.So... which way should we go?