Direct Access To Registers?


Drack

Member
Joined
Sep 29, 2008
Messages
210
I've got a simple question. Can a C++ app, run as a user, directly access the Pandora's registers through inline assembler?

If so, which ones?
 
Last edited by a moderator:
Probably all the ones you can usually access through assembler.
Which is to say, all the ones you need to use.
Like, general purpose registers, math registers...

Anything that a program can use, you can probably access through an inline assembler function.
 
Probably, should be in dev. discussion tho.

This is how I do it on x86, warning: dirty code ahead
CODE
inline void printR() {
unsigned long value;
__asm__("movl %%eax,%0;":"=r"(value)); printf("eax: 0x%.8X\n", value);
__asm__("movl %%ebx,%0;":"=r"(value)); printf("ebx: 0x%.8X\n", value);
__asm__("movl %%ecx,%0;":"=r"(value)); printf("ecx: 0x%.8X\n", value);
__asm__("movl %%edx,%0;":"=r"(value)); printf("edx: 0x%.8X\n", value);
__asm__("movl %%ebp,%0;":"=r"(value)); printf("ebp: 0x%.8X\n", value);
__asm__("movl %%esp,%0;":"=r"(value)); printf("esp: 0x%.8X\n", value);
__asm__("movl %%esi,%0;":"=r"(value)); printf("esi: 0x%.8X\n", value);
__asm__("movl %%edi,%0;":"=r"(value)); printf("edi: 0x%.8X\n", value);
}
 
JayFoxRox; Printing all the register values like that seems kind of useless when there's code between where you want them captured and where they actually are captured where a lot of the registers can be modified freely...

Drack; What do you mean by registers? Do you mean the ones in register files on the CPU, or do you mean hardware I/O ports (often called hardware registers) that let you interface with hardware components?

In user mode you should be able to read and write the following:

15 32-bit general purpose ARM registers in the user set
PC
Flags portion of the CPSR register (upper 4 bits)
16 128-bit NEON/32 64-bit VFP registers (same thing)

You won't be able to access:
Any of the banked registers in the other sets
Any of the SPSR registers (there's no user SPSR)

I don't think you can access coprocessor registers in user mode, but I don't actually know.
 
Last edited by a moderator:
'Exophase' said:
I don't think you can access coprocessor registers in user mode, but I don't actually know.
Most of them not but there are selected few you are allowed to read.
 
Last edited by a moderator:
Exophase: I know :p thats why I warned. I never call that function anyway. I did only use it to see wether my own entry point corrupts the stack or not - It was different before too. It should still print the register contents correctly, right? (Which doesn't make much sense because the register contents are modified after the first printf() - probably before)
Drack: Why would you even want to do this?
 
Last edited by a moderator:
'JayFoxRox' said:
Drack: Why would you even want to do this?
Maybe he has some math that gets called a lot that needs to be super-optimized.
But really, the G++ compiler will do enough of that for you, unless you have, like, A LOT of experience with machine code.
Also, I think there's a "register" tag you can add to variables that are accessed frequently, and g++ will try to keep them in a register and not swap back to memory.
 
Last edited by a moderator:
'JayFoxRox' said:
Drack: Why would you even want to do this?
I plan on writing a Nintendo DS emulator (or at least, rewriting some of the DeSmuME cpu code to optimize for architectural similarities). Inline assembler can come into play here, and if I have access to the registers, I can simply pass some of the ARM instructions straight to the Pandora CPU. Is this a naive assumption?
 
Last edited by a moderator:
'Drack' said:
'JayFoxRox' said:
Drack: Why would you even want to do this?
I plan on writing a Nintendo DS emulator (or at least, rewriting some of the DeSmuME cpu code to optimize for architectural similarities). Inline assembler can come into play here, and if I have access to the registers, I can simply pass some of the ARM instructions straight to the Pandora CPU. Is this a naive assumption?


And then some ;p
 
Last edited by a moderator:
'Exophase' said:
'Drack' said:
'JayFoxRox' said:
Drack: Why would you even want to do this?
I plan on writing a Nintendo DS emulator (or at least, rewriting some of the DeSmuME cpu code to optimize for architectural similarities). Inline assembler can come into play here, and if I have access to the registers, I can simply pass some of the ARM instructions straight to the Pandora CPU. Is this a naive assumption?


And then some ;p

Precisely why I asked. I'm finding details on how emulation is implemented surprisingly difficult to find, outside of examining source code. What method *should* I be studying? Virtualization?
 
Last edited by a moderator:
Virtualization is pretty vague.
The "methods" usually involved with emulation are like this:

Interpreting - Basically, you set up variables for all the bits of hardware memory, then you walk through the instructions, one by one, executing each one manually.
It's the most basic method of emulation, and it's usually slow.

Dynamic recompiling - So complicated I can only vaguely explain the concept. You have some sort of "thing" that you send instructions into, and it spits out native code. Then you tell the operating system, "Hey! execute that native code!". It's a lot more involved than straight interpretation, and I imagine there's issues with synchronizing and buffering the code output, but it ends up being way faster somehow.

I would think static recompiling exists, but the fact that it doesn't seem to shows that I know very little about the whole field. :unsure:

But good luck.

edit: You're right, emulation is an advanced topic that's not covered in basic tutorials. You might have to just find an open-source project like a java virtual machine and learn how it works, then try to apply it to the ARM instruction set.
 
Last edited by a moderator:
No. Not virtualization. Dynamic recompilation. But I think starting with something like NDS is a pretty bad idea if you can't figure out on your own out a properly good way to go about it, and I think trying to optimize DeSmuME is going to be a ton of work.
 
Last edited by a moderator:
Back
Top