Refactoring, problems, and solutions.

January 14, 2010

Looking at mini.h, simd-intrinsics.h in mono/mini in the mono project code base I noticed that to port the intrinsics framework to Arm, I would need to rework/refactor a few things, namely the code that checks to see if a method is supported by the underlying cpu simd platform. [mono/mini/simd-intrinsics.c, see the usage of SimdIntrinsc.simd_version in the code] Currently, it uses a number that corresponds to the bit index of  Mono.Simd.AccelMode flags.  This is comparison because arm and x86/amd64 will support some of the same intrinsics functions–add, subtract, multiply, etc. I did not want to introduce a ugly hack to get that to work so, I am experimenting with changing SimdIntrinsc.simd_version from a bit index number to a set of bit flags. Looking at the incumbent code, I notice it is only used in some data structures and one or two places elsewhere only in the same file. This should make the change strait forward and simple, make the changes less hackish, and promote porting to other platforms.

The other issue I face is that the double floating point registers (32 of them of 64 bits each) and the vector registers (16 of 128 bits each) share the same physical registers in the Arm CPU. Two double f.p. registers for every vector register in fact. This leads to some interesting problems to resolve in the register allocator latter on. For now, to just get something working, my plan is to split it into 16 double f.p. registers and 8 vector registers logically, which would be fairly easy to do. This will allow me to get things rolling and set things up and do some testing before the problem is finally resolved.


Setting up development environment

January 8, 2010

Now that I worked out how to set up a arm Ubuntu Qemu image, I am now moving to set up the development environment.

Doing so, I was thinking of what work might need to be done to add Arm Neon to the list of supported vector intrinsics. Refactoring some parts would be required as it has a lot of x86/amd64-isms in it.


Success!

January 7, 2010

I got the arm version of ubuntu to work!

Here are the instructions I used. Note: Don’t uses the build script in karmic… it gave me a headache. Use this one here. It goes right along with the instructions and works! Oh, use the option to build the image directly without the intermediate tarball step, it will create a 1 gigabite hdd image. Then use the instructions there to run the image in qemu and … you got a arm vm on your machine.


Mono, Ubuntu, Arm, Qemu and….

January 7, 2010

I tried to set up a virtual arm based machine using qemu so I can work on the arm neon port of the mono simd intrinsics., but… setting it up was a bit of a challenge. So, going to try again. Hopefully, it will get set up soon.


JIT, mono, and performance.

January 7, 2010

My next project is to improve the JIT (just in time compiler). This is tricky because constrained execution budget the JIT.

Now… here are  few things I am thinking of working on:

Autovectorization:
This is a very ambitious project and possibly risky when it comes to adding this to the jit, as autovectorization can be a very expensive operation to do. Might be sutible for a standard compiler but for a jit…. not likely; however, hopefully I can use the very rich type data in C# to make some “shortcuts” in algorithm.

Register Allocator:
I noticed this doesn’t use the live range info in the code… experiment with implementing this.

SIMD:
Add the capability to use intrinsics for indexers for the structs in Mono.Simd name space.

Port the simd intrinsics to ARM architecture. This will be tricky because how the fp and vector regs share the same hreg space in a “odd” way. This will most likely require changes in the register allocator and other areas as parts of the simd intrinsics code is heavily x86 centric.


C, .Net, Mono, and Google Summer of Code 2009

January 7, 2010

During the summer of 2009, I completed an application for a internship during the summer with an opensource group named Mono Project after a short time my project was  accepted.

Several challenges existed, working with an existing code base, a linear register allocator, a Just-in-Time compiler.

The most challenging aspect of this project was that the floating point code used the SSE registers in the Amd64 platform to do its work, and I had to work with the register allocator to make sure the code that uses these registers in scalar mode and vector modes don’t confect.

While doing this, I found that the register allocator worked back to front on the Intermediate Representation code it was given. It took a while to figure this out, but I did. After this, I modified the register free/non-free maps for both the floating point and vector registers so that they were aware of each other and what each others status of a respective register was.

The next challenging thing was to map the vector IR opcodes to the machine language opcodes for the Amd64. The use of the official documentation for the platform helped greatly; in addition, the X86 platform was was very similar in some aspects. This similarity broke down because of the Amd64 platform use of the REX prefix byte and that when the REX prefix byte is before an opcode that opcode cannot access the AH, BH, etc registers like in the X86 platforms. Because of these two things, a few things had to be reworked when using the X86 as  template for the Amd64 platform, like the max bytes an native machine opcode can have, and some IR to native opcode mappings had to be reworked.

Over all, I learned a lot more about JIT’s, .NET, Mono, C and programing in general.


My time at Pramari, LLC

January 7, 2010

Starting in January 2008, I started a internship with Pramari, LLC. They are an RFID consulting firm and an open source middleware developer. My first project with them was develop an emulator for the Mercury 4, Thing Magic reader to plug into their existing GUI and set of readers named Rifidi. The syntax of the commands where very similar to SQL. The first part of the project was to get something sent some emulated tags back and integrate it into the existing GUI.

The next step of this project was to add non tag related commands. To do this I had to refactor this particular emulator to be more extendable. To do this, I used a modular style programing using polymorphism.

During these two phases of this project I developed sets of JUnits to automate the testing of the emulator. This helped in catching regressions. During these two phases of this project, I normally worked independently (while telecommuting) with minimal supervision (often once or twice a week with my supervisor and once a week meeting the rest of the company which was less than 10 people), and often tried to find the solution to a problem myself before I contacted my supervisor.

My second project with them I help develop an edge server/client project from the from inception to about three months. This was a very good learning experience because while helping on this project, temporarily relocated to their main office for three months, and this helped build my experience working with a team. During this project I learned Modal-Controller-View methodology by helping implement it in the project from the beginning. As the weeks went by, we first made something that ‘just works’ then figured out the problem points latter, then address these issues as they came up. This cycle was often completed in one or two weeks… and in some cases less than one week, i.e ‘rabid development’. In some cases, refactoring was in order but others… the codebase was scraped and we used what we learned to build a better version.

Some of my takes was to help build some of the core classes for the server part and part of the GUI for the client. The server part was challenging because could spawn hundreds of threads to do its work, and we had to address this to get it to work better–not to mention the synchronization between threads.

On the client side, I created a GUI plugin for it from the ground up. Part of the task was to use JMS and RPC to read the tags that the server got and displayed them. This plugin was developed in SWT and Eclipse and was built as a modular plugin. The other part of the client I worked on with my co-workers was how the client communicated with the sever. This was fairly interesting as the server and client were often on other machines (or on separate processes if on the same machine) while being tested… and sometimes across the Atlantic Ocean with one machine in Connecticut and the other in the abroad office in Germany.

One of the on going projects i worked on was QA testing. Testing the Rifidi and Edge Client GUI’s for bugs was interesting because it had to be done by hand and I had to find those obscure bugs that come up that don’t show up in normal use. One bug I found was hard to nail down the resulting problem was. It was with a dialog control that, when minimized and then maximized, did not repaint the child controls. I eventually found that the problem was in SWT itself and not the application. Therefore, I submitted a bug to Eclipse and then preceded to use the problem control’s hooks to build a work around so that whenever the control was maximized, it issued a paint command for the control.

The internship ended because the company had to downsize to service, but on the bright side I gain many new experiences and professional relationships.


Follow

Get every new post delivered to your Inbox.