> > > Is emulating a MIPS 3000A in interpreted mode as simple as this source seems
> > to
> > > suggest?
> > Yes, it is. Why do you think there are that many r3k recompilers and not so
> > many for other processors? :-)
> > OG.
> I suppose, also, if there is only one type of branch (did I read that
> correctly?), there is a very easy way to find all code segments. If there is
> only a branch on equal or branch on not equal, then there can be no dynamic
> jumps like in 68000.
> That means that at load time, you could scan all binary paths and recompile the
> entire program.
> ELF Start address
> x x
> /\ /\
> Is this possible, on did I miss another jump opcode in the MIPS instruction set?
> Ahhhh - is that why N64 emulators are able to recompile at load time as well,
> and do all the searches for sqrt and stuff like that?
> Heh, I feel like I'm gradually working through the history of emulation and
> seeing how it's done... been through the Massage, Genecyst and Callus stages,
> i.e. hardware from the 80s and early 90's, and now slowly moving on to 1994,5 -
> PSX and N64, or rather 1998, the PSEmu Pro era.
> *Update* - Oh bollocks:
> jr Rsrc
> Jump Register
> Unconditionally jump to the instruction whose address is in register Rsrc.
> Damn and blarst
> You learn something old everyday...
PS and N64 were both initially based on libraries and no chipset documentation. Combine this with the fact that the devkit came with C examples and GCC compiler, and it becomes pretty easy to scan for and replace library calls. Of course you have to take care about new library versions, but there is still plenty you can cheat especially on N64 emulation.