iirc, every variable has an ID. I do not know how the firmware actually handles it but here is how I think it works: To read/write to the variable the firmware will need to look that ID up and return the corresponding variable and type.
A pointer variable type should be added, but instead of having a position in memory it should contain an ID to a variable. It would need its own special type and store the ID as an unsigned int. When the firmware looks up the variable, it should notice the pointer type and instead of returning the result it should look it up again but with the new ID. (A recursive process, with the danger of looping.)
Every opcode which receives the pointer will then act on the variable it points to and never the ID it actually contains. (IIRC you will not be able to directly access members of a pointed structure, you would have to move it into a temporary structure of same type.)
The mov-opcode will also not affect the ID, it will affect the pointed variable. A 'set-address' opcode will do that instead, first parameter is the pointer and second parameter is the address. A 'get-address' opcode will then return the ID of the second parameter into the first.
A bit of a warning though, an ID of 0 is valid, a NULL pointer would actually be an entirely different value... (Can't remember it though, I think it was something in the lines of 6xxxx.)
(Edit: I changed this part significantly since my earlier idea wasn't very C like...)
(Dynamically created variables could be stored in those as long they are given an ID, but that is an entirely different matter.)
Well, this is my idea of how a simple pointer implementation would work on the standard firmware.
)