>>19575>or crazy, probably both.I'm not so sure myself. Considering what's public info, declassified government docs, patents, etc. like vid related:
https://www.youtube.com/watch?v=mc-dH3Tl7oo (microwave ray gun in LA County jail).
http://breakingdefense.com/2013/11/raytheon-non-lethal-heat-beam-tackles-new-missions/Not saying there's he wasn't crazy, just that it's not my automatic assumption anymore given existing tech.
But I may be biased: I'm on a Cyberpunk image board, after all.
----
>>19529> 0x07400 - locks up when some are changed.This appears to be the function call stack. The instruction pointer is pushed here along with the rParam register on opcode 0x19 (visit()), then the IP is set to the specified address (like a jump), and these values seem to be restored on opcode 0x20 (the unnamed return code).
My thoughts on Function Call semantics ahead:
Instruction 0x19 is odd. The "dest" "slot" value byte of the 32bit instruction (bits 16 to 23) contains a value that's added to the rParam register. The bits are shifted down 14 instead of 16, and masked off to 0x3Fc. Thus the 8 bit value is effectively multiplied by 4 before adding it to rParam.
The values at 0x7400 don't contain a normal function stack like a x86 CDECL, as there is no parameter data that gets pushed onto the call stack. Maybe one of the other offsets mentioned. I'm still trying to figure out exactly how you pass parameters between functions, but it seems like they may be purely passed via registers and global vars.
The base value of the registers in memory can shift up on a function call, but can't be modified normally afterwards. The offset is unsigned, and modification of rParam throws NOPERM. So, a visit()ed function can't read register values below what the caller offsets to.
That means there's no need to push / pop the registers you want to save, since you can move the register base pointer beyond them. So offsetting by 4 means register value #0,1,2,3 are "protected" and your register #4 becomes register #0 in the called function.
One way to call a function could be as follows:
Figure out how many register values you need to save. Issue instruction 0x19 with the source data as the code offset to execute, and bits 16-23 set to the number of registers to save (which are 32 bit, so the multiplication by 4 works out). The called function won't be able to mess with your protected registers you offset beyond. When its done the called function issues instr 0x20, and continues operation.
Normally, you have caller clean up (the caller restores the stack frame), or callee clean up (the function is responsible for restoring the stack frame before returning).
This seems like the call / return VM instructions do the clean up automatically -- and there's nothing to clean up, since the functions are using their own private copy of the registers.
To pass a parameter to a function you could populate what will be its register 0, 1, 2 ... n, with the parameter values. To return a value you would put the data back in these registers? Hmm. Or, the caller can access all the registers the function was using when it returned, so the return value could be in any register so long as the callee knows which one its in (this could be encoded in a function signature).
Forgive the rambling, I'm just "thinking out loud" here.
I guess function call semantics are beyond the scope of an assembler, but the VM blurs this line since it prevents modification of the call stack outside the call/ret functionality.
Kind of cool that you don't have to push/pop registers to save them, but the calling code has to know how many registers it's protecting before calling a function (most compliers do already know that, however).
