"limited to nds cardage rom spaces"
http://problemkaputt.de/gbatek.htm#dscartridgeheader
http://problemkaputt.de/gbatek.htm#dscartridgeprotocol
32 bit address space available, though individual file formats might go lower and some games will try to cram whole files into memory which can make things tricky. That is also ignoring some kind of tweak you might do on this emulator/hypervisor type deal to make sector addressing or bankswitching or some kind of virtual extension. This would bring it in line with some of the largest 3ds releases from what I can see.
Anyway I don't know the 3ds hardware and firmware/bios/hypervisor/OS setups well enough to know how feasible it would be to make use of or adapt something running in the background on the 3ds.
I would first look for the limitations that might prevent it -- the link above is great for DS hardware, you would need it all working on the DS (though might be able to skip wifi, even if I imagine you want this so as to be able to do wifi games without needing WEP, and not all games will need 3d hardware even if most of the later ones will). For instance the reason the GBA is so hard to emulate on the DS is because the DS slot is actually a fair bit slower than the GBA one and thus you would need to compensate for that.
Being made from C/C++ means fairly little in this. That is good for dynamic recompilation emulators, means some measure of decompiler can happen (rather than being limited to disassembly), possibly means you can infer some info if the devs did not strip all useful function names out and has implications for cheat making as far as memory allocation. For the purposes of (expanded capabilities) hypervisor style running then it can be written in java, assembly, or brainfuck... it matters not a lot.
