QCC and Quake's localstack

[deft]

I'm not sure where to post this, but I'm curious as to how Quake handles calling of functions.

I see that in PR_COMP.C (from qcc.exe code) that QCC just generates a huge list of 'globals' and everything operates on that, but then in pr_exec.c (Quake engine source) it shows that there is a localstack which 'backs up' variables that the current function is working with, before entering the next function.. but I don't see why that's necessary when globals+locals are basically allocated by QCC in one huge continuous block of memory.. when would any vars from one function 'step on' the vars from another?

am I missing something? were they missing something?

[Spike]

[deft]

[Spike]

in V5 (qtest), there was no locals stack
in V6 (release) recursion through a individual qc function works.
The only places I can think of recursion being used is with triggers triggering triggers.
But yeah, locals are saved on entry and restored on exit, so they do not appear to be changed.

Actually, not all locals are preserved, from what I remember, but that's more of a bug than a feature. Specifically, only locals and the temps between locals (not trailing temps) are preserved. This means that certain call nesting can break, eg: self.blah = thisfunction(); can result in the self.blah reference being stale (the first is overwritten by the second).
I think.
Which basically means you write to the wrong entity.
The reason is that the locals are stated as a global index/slot count, but the number is only updated for actual defined locals, and not temps.

[deft]

Hey thanks for all the info Spike. I got into coding by way of QuakeC a decade ago, and now I'm working on a project that I see would benefit from externalized game logic code via scripting engine, and I figured with all my QC experience and familiarity it would be easiest to approach the problem armed with the goal of setting up a system resembling QC, and some qcc sourcecode ;)

Now, if you don't mind my asking, do you think that it would be reasonable to de-alloc the defines that qcc accumulates after it processes each function ? or builds a separate defs buffer alongside pr_global_defs for defs created locally by each function being parsed?

It just personally seems kinda yucky that everything is lumped into one big globals, and that maybe a more sleek and efficient way of handling globals vs locals (both in compiling, and execution) could be done.

Do you have any personal opinions or thoughts on how to improve something like QuakeC? and I don't necessarily mean by changing the language itself, but more just the thing as a whole in terms of efficiency and compactness ?

Thanks again.

[Spike]

my personal opinion on how to improve quakec is to use my qcc, fteqcc.
You may personally feel that its yucky to lump everything into one array. But on the other side, what's worse, one array, or modifiers or flags or extra instructions to address globals and locals differently.

What's yucky is carmack's qcc's approach to temps, and making each new temp into a new 'global'.
Did you know that hexen2 had 2 progs.dat files, choosing which to load based on the map (each containing a different set of monsters), and that's after hexenc's hcc being massively rewritten.

fteqcc and even frikqcc are a lot less wasteful.

Actually, if your temps don't need to be initialised, there's really no issue with stating that all temps exist within a specific constant range shared by all functions. FTEQCC actually does this. It yields a much greater capacity.
FTEQW contains a reasonably pluggable QCVM module. I'm not going to claim that its the best code in the world, but its feature set is impressive and may save you some work, depending on what you wish to achieve with it. Its capable of loading multiple progs into the same VM instance, as well as multiple separate instances, obviously.
Blah