[Concept] Compiling the map script directly to JASS bytecode

[MindWorX]

If you have any way to find the ThreadLocalStorage there is a straight forward way to get the current VM across versions as long as the structs remain the same.

VirtualMachine* vm = GetThreadLocalStorage()->Jass->VirtualMachineManager.VirtualMachines[GetThreadLocalStorage()->Jass->VirtualMachineManager.Count - 1];

As far as I can tell, the VMs are pushed and popped like a stack so using Count-1 should give you the top, aka the current VM.

 

[WaterKnight]

While people are discussing if WC3 is going to die, I, on the other hand, want to give it a new life

• No More LEAKS!!!

  Sounds like a dream come true, doesn't it? The allocation, assignment, and destruction of local variables is a costly operation, the game needs to compute a hash of the variable's name every time you use it, and you even need to manually clean all your variables at the end of functions, if you don't want to produce leaks.
  
  But if we run our entire map from bytecode, we won't use JASS local variables anymore! We will do what every machine compiler already does: assign VM registers for all local variables used in the code. Not only this will result in an incredible speed increase, but also there will be no need to null those variables anymore, since registers are always cleaned up at the end of execution.

Does this mean object variables won't hold a reference anymore, meaning if the object gets destroyed midway and the same address allocated again, the variable would point to the new object?

To make an estimation about how the byte code should be presented, it is necessary to know what exactly it allows for. But Lua, for instance, feels unmaintainable. With no static typing and such, you discard verification and IDE possibilities. Maybe rather have a mixed approach? Like creating a super language that extends vJass/Wurst/... and only have designated pieces compile to byte code -> interoperability, optimization where needed.

Moreover, I understand this works in standard Wc3 and won't be touched by Blizzard? I mean the lower we dig, the more probable it becomes for modification via patches

 

[Waffle]

if there is some feature of a hypothetical language that cannot work without bytecode trickery, it had better need to be wrapped in an unsafe block or something of the sort, if blizzard does change it, it should be plainly obvious, without using some fandy tools to know what places broke.

might also conceivably have a 2-mode compiler, one which compiles to the more efficcient output that uses bytecode and one that generates some awful hack that at least keeps the map playable in case 1.29 comes out a year from now and breaks it and the bytecode maintainers wont be there to fix it for weeks..

there is also the issue of compile setups getting more and more complicated and harder to maintain... there is a reason there are people still using jngp even tho enticing alternatives are available. onboarding new teammembers can be quite a hassle and it doesnt help if you need to get a bunch of settings right and apply a custom patch to support some dialect of cjass that nobody has supported for 5 years.

i see no good reason why we need to use lua for instance when the map script is jass, and the interleaving of the 2 inside map scripts to call objectmerger is just so awful ppl dont even want to look at it.