PSPEMU Rev301

[MaXiMu]

PSPEMU Emulator for windows Based language programation D.

http://code.google.com/p/pspemu/
Upload last revision compiled for me follow link http://pspemu.4shared.com/ (Inactive)

- Added in the 7zip

- Pspemu.exe Rev161
- ddbg.exe
- demos

Rev 301 Oficial

Download PSPEMU rev301 Googlecode

Translator English Changes r99-110 Comented by soywiz in the blog

R99 -> R110. A few days later, a more relaxed pace, slowly but surely.

- Major refactoring in different components. Partial cleaning of code.
- Corrections IoFileMgrForKernel. One thing that was preventing some games work that
IoFileMgrForKernel, Streams created when opening files and passed them to the virtual machine as a
pointer of the host machine, the guest took as an integer identifier. The pointer was lost in the heap
the host and battery, and the value was stored in a memory area controlled by the GC and not
can manage, when running the garbage collector, was loaded streams that were still in use.
The solution was kept a list of open Streams in the area controlled by the GC. It was still going on
pointer, but no longer lost. Although what I will do in the future will be to create IDs that are assigned low value
the pointer. That's more manageable and closer to the original behavior. This came into operation on
Trigonometry Wars.
- Add the module to manage the registration sceReg the psp and added a pair of fake registration keys for
prove that it worked. Not implemented yet 100%, or saves the state of registration or registration charge
a file, but allows for registry keys that was the first approach to testing par with
some homebrew.
- Temporarily disable the audio threads, ralentiazaban quite all, and now no sound
working properly. I have to do a mixer or use one already made (such as fmod for example).
- Implemented more methods of different modules of the kernel.
- Improved the error handling and debugging information is displayed, but (there is not a debugger
graphic conditions).
- Made minor changes to tear pspsolitaire ThreadManForUser. The threads usually one of the
aspects that things break. Until they are properly implemented, will have problems everywhere.
- Add a Logger class on the one hand to not depend on the console when working over the GUI and the other
part in order to filter certain messages request.
- The issue of testing was completely broken for quite some revisions, so I started to get away.
I restructured the syscalls, they change the code> = 0x2000 a> = 0x1000 because the PSP does not reserve these codes
for kernel functions and is more "safe." Add a new syscall to specify a memory range
of which will be a CRC32 to verify that the content is expected. I prepared an executable that would release
tests searching for files. expected.
- I started a hexadecimal editor component for viewing and editing the memory of the guest.
- Add a record CLOCK by increased thread for each statement executed.
- I put debugging of JAL and JR r31 to locate problems more easily.
- I started the implementation of the relocation of relocatable Elf.
- Fixed a few graphical problems: transform2D 480 -> 512 for glOrtho (this was to "eat" some
pixels to the right in games with whole / part in 2D); glReadPixels in gpu.impl.GpuOpengl (who had made
render problems by GE RGBA8888 targets that were not).
- Made changes to the assembler. I added the possibility that the emulator could load, assemble and execute
mips assembler directly. This would create very simple tests to test assembler
instructions individually. I created a demo in a few assembly instructions (about 12) to test the
performance. Despite being 12 instructions, made a very costly process, which was to paint the entire displayBuffer
(0x04000000, 0x04088000) in a color that was changing (and not pixel by pixel, but each component). That is
more or less half a million iterations. And every iteration has several instructions. In this mode interpreter
6fps was about.
- This was the prelude to what I wanted. I wanted to start and dynamic recompilation. And at 6
morning I left the example simple assembler which I run at 50fps and without touching
optimizations too: P. This is about 8 times the speed mode interpreter.
- Just because you're working on the laptop, one that already has some time, implies less power
implementation. This has advantages: it makes me see things that go slow and try to make it go faster.
Cons: I lose more time, programs that "cascade" after a while or the time I spend
compiling, is wasted time. DSSS I have to test to see if improved compile times
substantially.

Things to discuss:
The most interesting thing in this block of revisions has been the dynamic recompilation. It was a first approximation.
But had done some demo dynamic recompilation technique D, had been very simple, low-
realistic.

About how it is mounted:

It is assembled in layers. There is a first layer of code that an issuer does not focus on any host platform,
or any guest. This first layer is responsible for providing a number of functions to write to a buffer
(Which will be run) values of 8, 16 and 32 bits. It is also responsible for creating labels and slots
referencing tags, and the ability to write in the slots, once the labels have been defined.
Allows 32-bit writes relative and absolute. Then I set another layer on top which is already focused on
Host code generation for X86 32-bit implementation. It offers a limited number of functions for
code generation. (I'll add as I am going to be needed.).
Then I set up a guest-focused last layer MIPS. Basically offers a number of functions that emit code
of 8086 on the basis of characteristics of MIPS.

Basic Operation:

The subject of the records of the mips. The PCs are 8 records for use "general" (although for some
instructions are specific use). Some records must be preserved after the execution of duties
as specified in the calling conventions of the X86:
http://en.wikipedia.org/wiki/X86_calling_conventions
EAX, EDX and ECX can be used without fear of teasing values used in the field above. So I decided
work with these mainly to avoid brown or push and priests to keep records and
restored in some other memory area.
Because you can not map registers 8 to 32, the simplest implementation is to work with a pointer where
are the records and use the direct memory access as the X86 beater.
I decided to use the register ECX to store the pointer to the records. So the first thing you do before
begin to execute code is to put in ECX the pointer to the records.
After that normal operations are to save / load values in registers EAX and MIPS
EDX, to the relevant transaction and keep in check the value, using ECX as a basis.
Then, regardless of the jumps that are the hardest part (especially for the mips branch delayed
Likely and subsequent revisions). Beyond that, it should be switching threads and manage
breaks "from time to time." Since we know that eventually the code will reach a branch or a jump,
by noses, as branches and jumps are good times for these costly efforts. Before the
jumps, I make a call to a function "tick" that is responsible for making these processes and return true or false
depending on whether there has been a change in PC. If there has been a change in PC, you have to leave the implementation and
start again. This happens in the syscalls, in the jr jalr and has your
indeterminate when you recompile the code.

The management of delayed branch:
Identify characteristics of a MIPS are delayed branch. To learn how to implement first
need to know how it works. Put simply, the delayed branch has the characteristic that the instruction
after a jump is executed after determining the jump. This is a nuisance because there is no X86
anything like that, so you have to rearrange some things.
This in itself is not "too much" fuss. The problem is that there are certain jumps "Likely", whose instruction
the delay slot is executed only if it is to make the jump, if not, skippea. This complicates a little
subject.
The solution I've applied myself (I have not clear whether it is good compared to others because I have not yet
seen other implementations) is to generate a source code before and after the delayed one slot in terms of
the jump instruction. In the normal branches, the comparison is made before the flags are saved
comparison if the operation modifies the delayed slot and then make the jump after running the
delayed slot if the condition is evaluated before certain about the type of jump.
The Likely I have not yet implemented, but it will add a further leap. Possibly one conditional on the
following the delayed instruction slot, and a delayed unconditional between the slot and the next instruction. It
a pain yes, but what there is.

Analysis of functions, compiled code reuse and cache:
The other tricky part is the management and analysis compiled block. On the one hand we must analyze the
code to run in search of conditional branches and unconditional jumps that produce a
impasse, which are the points that make the complete analysis function: J, JR.

Initially I did differently, but gave me some problems, I ended up creating a label for each
compiled instruction and then use references. To be made for each instruction can be done in one step
(Without a step of analysis [to determine the labels] and another issue) on the contrary should
may occupy more memory and when not compiled the code, could cost a bit more to compile. Although
I think these two factors are less, because once compiled when the matter is over.

The issue of selection of blocks of code to execute.
The first thing you do when you want to start to run from a memory location, is looking to see if there
compiled a block containing that address. If it contains, go to that block, the label located
begins to run. This course currently has a cost of two accesses to a hashmap (2 times log
with a linear part to collisions). Perhaps we could improve, but that will come later. For now improving
performance very much.
If not located (code cache miss), we begin the analysis process that generates a block compiled, and
when finished, turns to look in the cache.

One thing I have not done so you have to do and for which I have prepared a unittesting (which is passed without
problems in the interpreted version) is the invalidation of blocks. On certain occasions (eg
the guest dynamic recompilation or dynamic loading of libraries occupy the same memory space), a
executed code can be modified. You have to manage the scripts and if one plays a part cached
invalidate it. I think of any way to do this relatively fast enough, but I will discuss
issue when the time comes.

Otherwise nothing to add at the moment. The issue of dynamic recompilation is the first time I
I do seriously and I have no clear if I did it well. Anyway I wanted to make a first attempt at my "ball"
errors untapped learned by others and wanting to find out how to mount it myself. A
time is running other implementations will look to see how they have mounted them and compare. Stay with
the good things of mine, and the good things the other / others.

Nothing more. Here I post some screenshots of some homebrew games that begin to function with the latest
versions of SVN:

http://pspemu.soywiz.com/screenshots

Trigonometry wars. It was the first homebrew game to work. With the audio threads blocked, go to a
moderately acceptable speed on my laptop-mode interpreter.


Gold Miner. A demo made it possible for some summer competition in Shanghai. Load and speed will
pretty good on my laptop.


Technical Demo rpg. Wandrian: Tears of Fate. It costs a lot to load interpreter mode and then going from 10
Interpreter mode 35 fps on my laptop.


A port of the game start Skyroads. This is in 3D. Doing pretty well on my laptop.