Like I said many times in past, I don't have any more interest in publicly supporting a language that does not seem to attract a lot of coders, but this is an obscure platform, so it's all expected. It was fun as a dream few years ago, but it's clear now that effort of mine is useless now.
The time I would spend on adding any new VRBasic features is way more better spent on 3D experimenting with jag, or like now - learning GPU.
That being said, the VRBasic backend can indeed make my GPU debugging way faster and productive, as with few minor tweaks to the C# codebase, I can introduce C-style syntax, as the backend already does all the heavy language-parsing lifting (parsing, labels, copy-pasting pass-through code, expressions ...). I don't even need to implement the GPU functionality, as the backend will just copy-paste all unknown commands as-is, so all I really need to do is just to implement those 3 features (conditions, loops, math expressions). It's already integrated in my build config, so I'll just exchange the parser executable and it'll work as it is with the smac.
I'm currently thinking that if I actually bothered to implement the virtual machine (there's not that many instructions in GPU), I could actually use VisualStudio's debugger and step through the GPU code inside VS and see all the registers and variables live (extremely handy for what I'm doing right now - checking contents of registers after a loop has run couple hundred times). Since GPU's instructions only work on 2 operands, the implementation of the VM would be very easy - just adjust the register or memory value after executing each instruction. And I wouldn't even need all instructions. ~20 would be enough (LOAD/STORE/MOVE, ADD/SUB, DIV/MULT, SHRQ/SHLQ, NEG/ABS, AND/OR/NOT/XOR, JUMP/JR).
I already have the C# backend hooked up to the XNA window, so I can already right now display the contents of Framebuffer anyway, so I'd actually have a debugging set-up for jag GPU work inside VisualStudio (well, at least for software-rasterizing functionality that does not use jag's blitter, but that's what I'm working on right now anyway).
I never thought of this use case while working on VRBasic codebase, but looks like it can be reused for something much better. This would be actually much more productive than gdb, that I don't even have hooked up to jag yet.
I just spent 2 hrs chasing one texturing bug that manifests only in using corner scenarios after executing couple hundred times. If I had it running in VisualStudio, I suspect it would take about 3 minutes to find (just hit breakpoint, set it to break after 100 times), so I think I crossed the threshold whether I want to keep printing values on jag's screen or spend a weekend with implementing a simple VM for those ~20 instructions.