Calling Conventions/Stack

[Baker]

Here is a great guide to structure of the stack and what goes on in a function call.

http://www.tenouk.com/Bufferoverflowc/B ... low2a.html (detailed function call)
http://dwarfstd.org/DownloadDwarf5.php (how debug information for gdb is stored)
https://en.wikipedia.org/wiki/X86_instruction_listings (x64 instruction set)

About 2 years ago, I would read the pros and cons of the different language calling conventions (caller cleanup, callee cleanup) and dig into the stack structure, but not really/just barely use it.

Weird thing is, earlier in the year I turned the Quake menu as-is into a mouse interactive menu.

https://www.youtube.com/watch?v=pWyFltQ-wRY

But the interface was hard-coded into the engine and rubbed me the wrong way, because I felt like the interface should be script-like (text representation).

But to get from hard-coded representation to a script-like representation that allows variable declaration and function calls and complex expressions is no small amount of work.

In fact, it involves 4-5 different highly complex problems.

But why else do something? I would imagine this is why FrikaC, JP Grossman, Spike and others found satisfaction in the QuakeC compiler.

[revelator]

Could use cegui completle scriptable via lua and xml., used in atleast one game im aware of that uses the crystal engine.

Pro's
Scripting via lua xml and possibly others i have to have a look at it again been some years.
Gui elements can be locked unlocked which is a big help when setting up ingame stuff.
Could also be used for hud and other stuff.

Con's
Library is C++ but C wrapping is present, and it can be linked statically so not really a problem.
A rather big overhead in size.

[ericw]

[Baker]

[Spike]

just use menuqc.
implement the core builtins from https://github.com/xonotic/darkplaces/b ... enudefs.qc while skipping the all the network+font crap, while throwing in sprintf+the easier fte_strings builtins. hopefully autocvars too.
using DP's key constants can be annoying, although I suppose its not mandatory if everyone uses stringtokeynum at startup for the keys they care about.
A third implementation would convert menuqc from a mere argument into an actual standard.
Implementing someone else's standard means you don't have to bother documenting your own thing, and there's already a few existing implementations to test against (even if they need some tweaks to avoid unimplemented stuff at the time).
I'd implement it into qss, but I'm too lazy and I don't think anyone would actually care anyway.

Frankly though, the biggest issue is cvar names being randomized in pretty much every frikkin engine out there, so that's something for Gunter to have fun with (cvar_type(n)==0 means that the cvar is not defined, and thus he should try one of the other possible known names, which is equivalent to what I do with my menusys menu mod).


FTE's plugins tend to implement menus via fte's 'console windows' feature, combined with embedded console links/images for mouse stuff. Yes you can make proper menus in there, but with them being so isolated from the engine it makes the whole thing inconsistent and annoying, whereas consoles are a few lines to create them and then a load of prints. Easy, and with scrolling for free.

[Baker]

[revelator]

Not dead but yeah it sure has lost some traction

If just for curiosity you could have a look at doom3's menu system, its pretty standard xml albeit written in C++, but it might give you some ideas.
cegui is opensource so you can modify it to your hearts content, but yeah adding a huge library just for a menu is kinda meh.
QT could also be used if going for something aking to a launcher, then again size will probably be a bit to much for so little benefit.
If going for a launcher type with no menu at all in quake itself you could use the fast light toolkit or FLTK in short, its probably one of the smallest applications for creating gui's out there and it spits out a single *.c when you have everything right in the editor .
qcmenu is also a possiblity if you want to keep things straight in the quake world.

[frag.machine]

The advantage I see in menuqc is being useful not just for menus but for custom GUI projects in general: HUD's, NPC's dialogues, etc.

One idea I had in the past was a minimal markup language using notations to refer to global gameplay vars, cvars and entity fields in general. And instead calling directly C functions, just forwarding commands to the console. Easier said than done obviously. In the end I was introducing things like loops to control animations and conditional clauses when I decided to scrap it.

[Baker]

[Spike]

JIT actually means that functions are converted to native machine code only when the function's actually executed. Q3 takes the lazy choice and does Ahead-Of-Time compilation instead. Basically just convert the entire thing at load time instead of run time. I've misused the term multiple times myself.

The thing thats interesting about both Q3 and Java(from what I remember of it) is that they both logically have TWO stacks, as it were. One stack holds the locals, the return addresses, etc, while the other stack holds the temporaries, the intermediates, whatever you want to call them.
so you have some load instruction with a single argument that reads data from somewhere and then just pushes it to the intermediates stack. followed by another similar instruction, then you have some simple 'mul' instruction without any arguments that pops the two arguments, multiplies them together, then pushes the result. this can then be followed by some store operation that shoves that data somewhere. When combined with a few rules like 'the intermediates stack must be empty before any jumps or comefroms', the AOT/JIT compiler is then free to allocate/remap whatever registers it likes for the various intermediates slots, and thus your simple 'mul' instruction can then become a simple x86 mul instruction (but with some extra magic each side to try to avoid needing extra movs to remap the registers to match x86's annoying specific-register requirements). If you're processing a function at a time then you can combine the two stacks back into a single block.

If you're generating bytecode then yes, x86 is horrible with all of its different extensions and additions over the years. arm bytecode 'should' be a little more straight forward, if only because it won't have quite so many restrictions on which register is used, nor different forms of instructions for different registers. I've not needed to deal with arm bytecode itself, and tbh I can never remember which terms are ins or outs with arm asm, but the bytecode itself should be more predictable, if I understand correctly.
Note that 'mov ebp,esp' has a totally different meaning from 'mov ebp,[esp]' so its hardly surprising that the bytecode changes to reflect the memory address instead of a register. Especially if your memory address is formed from multiple args like both a register AND an immediate, getting even more complex when you throw in a second register and a multiplier too... Handy though, you can get a lot of stuff done like that, hence the lea instruction which can be quite handy for multiply-and-add type stuff, especially when the regular mul instruction is so awkward.

On the other hand, QuakeC has logically has 65k+ different registers and no real indication about whether a variable is a local, an intermediate, or even a global, which makes it hard to keep track of their scopes, effectively resulting in all operations writing back into ram. That said, considering you would need to write an AOT compiler for 3 or 4 different instruction sets (even if only two main families), its easier to just write a simple interpreter, in which case the performance difference won't be that significant. Besides, your engine already has a QC interpreter...

If you have different intermediate bytecode for 32bit or 64bit builds, you're probably doing it wrong. I would argue that a vm does not need to store native pointers, thus you should not need any 64bit intermediate bytecode for your interpretter, and even if you did you could treat pointers differently (ie: always use 64bit bytecode), always reserve 64bits for them and just read+write them as 32bit on 32bit systems - this is effectively what 64bit processors do when running in compatibility mode anyway. Really though, any objects should be referenced via some table, thereby allowing you to orphan them safely or whatever, as well as free them at exit (even if you've no GC while actually running).
(obviously different ABIs need different native bytecode, but that doesn't mean that the intermediate stuff should differ, because if it does then what's the point of it at all? might as well just compile directly to the native bytecode)

[frag.machine]

Besides JIT, at least as implemented by Java, would require Quake 3 to have an embedded profiler to detect the "hot spots" and only convert those parts to native instructions. Spike's explanation makes more sense to me.

[Baker]

[Baker]

Funny the mind-bending problems something like this smacks you with. You kept jacking up the specs and rewriting everything ...

Then suddenly you realize you have it running. And it scares you a little bit.

Sure there are 12 more complex things to do. But when you've done the hardest ones and planned for the other 12 along the way, it isn't that scary.

Next up: RAII C should have had this handling file handles and sockets. It also makes sense that C Unix libraries treat sockets and file handles identically, just another fd (file descriptor).

[Baker]

The wiring this kind of thing involves is astounding and very boring, but puts fun computer science challenges in front of you.

Even with support for numerous datatypes in the opcodes, did a speed test and get 2,000,000+ byte code instructions per second.

Fundtion calls, which have to load up the stack on-the-fly (in reverse order, cdecl style , can do about 200,000 byte-code function calls per second.

Ended up adding CTRL+BREAK support to "break" in debug mode. To my surprise, at least on Windows -- the message queue call is extremely efficient --- I call Win32 PeekMessage after every operation (I was hoping to catch a signal, but that is only possibly in a console application ) and the penalty is very low.

[Baker]

Ghost town update, haha

Constructing IDE. Mostly to test setting breakpoints and then "edit and continue".

With edit and continue, I'm trying to sort out a logical way to determine what code has changed.

I think as a matter of low common denominator it can only be code inside a single function that changed, so I plan to scope it that way.

The virtual machine stuff itself, the most fun was writing code for shortcircuiting AND and OR. They aren't really proper operators and have to be designed to skip potentially big blocks of code.