Inside3D!
     

QCC and Quake's localstack

 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> QuakeC Programming
View previous topic :: View next topic  
Author Message
deft



Joined: 02 Jan 2010
Posts: 3

PostPosted: Sat Jan 02, 2010 11:22 pm    Post subject: QCC and Quake's localstack Reply with quote

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?
Back to top
View user's profile Send private message Visit poster's website
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Sun Jan 03, 2010 12:19 am    Post subject: Reply with quote

Recursion. Noun. See recursion.
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
deft



Joined: 02 Jan 2010
Posts: 3

PostPosted: Sun Jan 03, 2010 12:56 am    Post subject: Reply with quote

doh!

thanks!
Back to top
View user's profile Send private message Visit poster's website
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Sun Jan 03, 2010 4:34 am    Post subject: Reply with quote

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.
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
deft



Joined: 02 Jan 2010
Posts: 3

PostPosted: Sun Jan 03, 2010 5:34 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Sun Jan 03, 2010 6:25 am    Post subject: Reply with quote

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
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> QuakeC Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group