Programmingland

Java RMI without name server

noreply@blogger.com (Fernando Magno Quintão Pereira) — Sat, 10 May 2008 06:09:00 +0000

You know, Java RMI is cool, but sometimes that pesky name server just gets into the way. One starts the name server by typing something on the sorts of rmiregistry. Well, there are other ways, but that is very common.

Today I decided to tinker a little bit with Java RMI. My idea was to code some sort of channel, that would give me direct access to a remote object, as long as I know its address in the distributed system. I want the client to be able to get the object without having to do a lookup before, by just typing:


RemoteObjInterface roi = ImportChannel.imp(host, port);
roi.remoteMethod();

Notice that there is no type cast on this code. Actually, the type cast happens in ImportChannel, so, I am just sweeping the garbage under the carpet. The server, by its turn, should be very simple too. The code should be like:


RemoteObjImpl ro = new RemoteObjImpl();
ExportChannel ec = new ExportChannel(ro);
ec.export();

The code is available below. I am using the example application from these slides.

Server. The server application, that creates a remote object and exports it via the export channel given further below.
TimeClient. The client application. It uses an import channel to get a hold of the remote object, and then it calls a remote method on it.
Second. The remote object's interface.
SecondImpl. The implementation of the remote object.
SecondImpl_Stub. This is the stub for the remote object. We need a stub to call a remote method, you know. Of course, we do not really need the source code, just the bytecodes, but I am given the source here just for fun. To produce an stub, one can use rmic. This tool erases the source code, after generating the bytecodes. To keep the source, use the option -keep.
ServerThread. The server uses this thread to handle clients looking for the remote object.
ExportChannel. This is the interface that a server must use to make an object available to receive remote calls.
ImportChannel. This is the interface that the client must use to get a hold of a remote object.

If you download all files above, then running this example application is very easy. You will need two terminals. In the first, initialized the server by typing java Server. It will print the port in which the object is listening. To use the client, go to the other terminal and type java TimeClient port, where port is the port where the server is listening. In this example, I have set the server to start listening at port 20000.

Fortran plus MPI in OSX Tiger

noreply@blogger.com (Fernando Magno Quintão Pereira) — Tue, 29 Apr 2008 18:24:00 +0000

Finally I've got the fortran/mpi stuff running in my macstation. The installation process is very complicated, and so I will be describing it here. First of all, the physics software that we must execute is OpenPIC2, and it must be installed once the running environment is set up.

We need a couple of things in order to run OpenPIC2: we need the fortran compilers up and running, and also an implementation of MPI (the official documents about MPI are available here). To install all that stuff, we'd better use some package installation manager. I recommend two packaging tools: MacPort and Fink. I had to install both, as I need fink to get g77, and I need port to get g95. You can download fink here, and Mac Ports here. Installing these programs in an apple computer is very simple.

Ok, now that we have the package managers up and running, it is time to install the compilers. Let's start with g95:


sudo port -v selfupdate
port -d install g95

This should install g95 in your machine. Actually, there is some other stuff that is pretty useful, and I guess we should install it right now. The first software is rpm, to compile the sources of openmpi, and the second is stow, which helps to organize the software installed.


sudo port -d install rpm
sudo port -d install stow

That should do with the port part of the installation routine. Now, let's get g77, and to do this, we use fink:


fink install g77

It is as easy as this. Now, you probably have two different compilers running in your machine. Fink puts stuff in /sw/bin. You'd better add it to your path. To add it permanently to your path, you can edit /etc/profile.
Good, good. Now comes the turing test for the faint of heart: installing openmpi from source. Actually, you can install it using port, but them it will not enable mpif90, which we need to compile stuff. You can get the source rpm from the openmpi site. I chose openmpi-1.2.6-1.src.rpm. Anyway, download it to your machine, and then do


rpm -i openmpi-1.2.6-1.src.rpm
cd /opt/local/src/macports/SOURCES
sudo tar -jxf openmpi-1.2.6.tar.bz2
cd openmpi-1.2.6
export CXX=g++
export CC=gcc
export F77=g77
export FC=g95
./configure
sudo make
sudo make install prefix=/usr/local/stow/openmpi-1.2.6
cd /usr/local/stow/
sudo stow openmpi-1.2.6

These commands should get openmpi running in your system. To test it, type mpif90 in your command prompt. If this does not report any error message, you can just throw some fireworks; otherwise, I recommending sitting and crying.

To compile the physics software, download this tar ball, and open it somewhere in your machine. You might have to edit your LAM.make file. The one that I have uses the following options:


MPIFC = mpif90
FC90 = g95
FC77 = g77
OPTS90 = -O3 -fno-second-underscore
OPTS77 = -O3 -fno-second-underscore
MOPTS =
LOPTS =
LEGACY =

In order to compile the first example, try:


make -f LAM.make lesopenpic2f77.out

You will probably get a lot of warnings, but do not let them scary you away. To run the program, try:


mpirun -n 2 esopenpic2

You will get a bunch or numbers. Do not ask me what are they about, but it looks right from my 600m distance.

A little of Erlang

noreply@blogger.com (Fernando Magno Quintão Pereira) — Sat, 19 Apr 2008 23:04:00 +0000

I have started doing some toy programs with Erlang. That is a functional, dynamically typed language that provides support for implementing parallel and distributed systems. It is very simple to write a small distributed application running on the same machine; however, I had problems to find information about this on the web. Thus, I decided to write this little tutorial which uses examples from the book Concurrent Programming in Erlang by Joe Armstrong.

This is the code of a server application, that allows users to make deposits, withdraws and enquires. The client application is given here. I tested these programs in a CentOS linux kernel 2.6.18-53.1.14.el5 running on a 64 bit Intel(R) Xeon(R) CPU. My interpreter is Erlang (BEAM) emulator version 5.5.2 [source] [64-bit] [async-threads:0].

To run these examples, open two command shells, that I shall call server shell and client shell. In the server shell, change to the directory that contains bank_server and start the erlang prompt:


erl -sname bank

Once in the erlang prompt, type the following commands:


c(bank_server.erl).
bank_server:start().

Likewise, start the command prompt in the client shell:

erl

In order to test if the server is reachable, in the client shell you can ping the server erlang node:


net:ping(bank@Tuvalu).

If you get pong as answer, then everything is fine. But, if there is any error, you will get the atom pang instead. I really think this is a bad interface for reporting errors, but, Alas, it is not my decision... Anyway, here, Tuvalu is the short name of the machine where I was running this example, and bank is the node name, determined in the command prompt when starting erlang in the server shell. Once in the erlang prompt, one can access the bank server using the interface provided by the client application. A simple example section is:


bank_client:deposit(fernando, 100).
bank_client:ask(fernando).
bank_client:withdraw(fernando, 50).
bank_client:ask(fernando).

LLVM 2.2

noreply@blogger.com (Fernando Magno Quintão Pereira) — Sat, 26 Jan 2008 22:56:00 +0000

Today I installed LLVM 2.2. The first test, compiling SPEC2000 using the extended linear scan algorithm produced this result, with this sequence of passes. Now, I will try to install the puzzle solver in this new version.

LLVM 2.1

noreply@blogger.com (Fernando Magno Quintão Pereira) — Mon, 10 Dec 2007 00:45:00 +0000

I will be trying to deploy the puzzle solver on LLVM 2.1. I checked the code, and it does not seem to be a very easy task. It has changed a lot since 1.9. After that, I will have to add instruction folding, and then comes the really difficult part: to make the puzzle solver retargetable... don't cry for me Argentina... just to warm up, here is the list of passes invoked by the original LLVM 2.1 with linear scan, and here a list of the passes invoked with the simple register allocator.

The classes of registers in x86, and the new register numbering, as defined by LLVM 2.1 is given here

Profiling LLVM

noreply@blogger.com (Fernando Magno Quintão Pereira) — Tue, 25 Sep 2007 19:05:00 +0000

It is possible to use gprof to profile the LLVM tools such as llc and such. It is necessary to build LLVM with the profiling functions enabled. To do this, go to the LLVM root and type:


make -j2 ENABLE_PROFILING=1

That will build a 'Profile' directory containing all the binaries of LLVM tools. Now, every time you run llc it will produce the gmon.out file containing profiling information. This file can be read with gprof using the command line:


gprof $PATH_TO_LLC/llc > out.prof

Jump tables

noreply@blogger.com (Fernando Magno Quintão Pereira) — Mon, 24 Sep 2007 06:07:00 +0000

Jump tables are a nice idea, but the way that LLVM is producing them is hurting the pass to break critical edges. My solution, not quite democratic, was to forbid jump tables altogether. To do this, I had to edit the file SelectionDAG/SelectionDAGISel.cpp. The method visitSwitch is responsible for creating jump tables. I simply commented that code out.
Now, my SelectionDAGISel.cpp looks like this.

Four little things

noreply@blogger.com (Fernando Magno Quintão Pereira) — Mon, 17 Sep 2007 17:31:00 +0000

Four things. First, this script from Lang Hames happens to be very useful when building LLVM. It unpacks the downloaded files and compiles everything, including the sources.

Second, enabling spec 2000 in LLVM 2.0 is different from 1.9. For the latter, just use the command in the post below. For the former, use:


./configure --enable=spec=/project/fernando --with-spec=/project/fernando --with-externals=/project/fernando

Third, to run llvm 2.0 is a little different from 1.9. In order to produce .bc files, the following can be used:


llvm-gcc -o XXXX.bc XXXX.c -c -emit-llvm -O1

Finally, when using the test suite that comes with LLVM, if you want, say, to enable the beta llc, and disable the C-back end:


make TEST=nightly report.html DISABLE_JIT=1 ENABLE_LLCBETA=1

To specify the beta-options, change Makefile.program under the platform that you are running.

Teste Suite 1.9

noreply@blogger.com (Fernando Magno Quintão Pereira) — Fri, 14 Sep 2007 23:05:00 +0000

I have just finished installing the test suite of LLVM v1.9. The whole process is not that difficult, but I had to directly download the test files. The version in svn was made for the most recent version of LLVM. Additionally, I had to create a symbolic link pointing to the location of the spec files, e.g: ln -s $SPEC_LOCATION/spec2000 speccpu2000. This speccpu2000 is the name that the LLVM configuration file expects. This done, I had to go to $LLVM_SRC/projects/llvm-tests and type:


./configure --enable-spec2000 --with-externals=/misc/project/fernando

That was it! To run tests, I can just use the same old command line:


make TEST=nightly report.html DISABLE_JIT=1

Bank of register v1.9

noreply@blogger.com (Fernando Magno Quintão Pereira) — Thu, 13 Sep 2007 03:03:00 +0000

This is the register list for the x86 architecture in LLVM 1.9:

1: AH, 2: AL, 3: AX, 4: BH, 5: BL, 6: BP, 7: BPL, 8: BX, 9: CH, 10: CL, 11: CX, 12: DH, 13: DI, 14: DIL, 15: DL, 16: DX, 17: EAX, 18: EBP, 19: EBX, 20: ECX, 21: EDI, 22: EDX, 23: ESI, 24: ESP, 25: FP0, 26: FP1, 27: FP2, 28: FP3, 29: FP4, 30: FP5, 31: FP6, 32: MM0, 33: MM1, 34: MM2, 35: MM3, 36: MM4, 37: MM5, 38: MM6, 39: MM7, 40: R10, 41: R10B, 42: R10D, 43: R10W, 44: R11, 45: R11B, 46: R11D, 47: R11W, 48: R12, 49: R12B, 50: R12D, 51: R12W, 52: R13, 53: R13B, 54: R13D, 55: R13W, 56: R14, 57: R14B, 58: R14D, 59: R14W, 60: R15, 61: R15B, 62: R15D, 63: R15W, 64: R8, 65: R8B, 66: R8D, 67: R8W, 68: R9, 69: R9B, 70: R9D, 71: R9W, 72: RAX, 73: RBP, 74: RBX, 75: RCX, 76: RDI, 77: RDX, 78: RSI, 79: RSP, 80: SI, 81: SIL, 82: SP, 83: SPL, 84: ST(0), 85: ST(1), 86: ST(2), 87: ST(3), 88: ST(4), 89: ST(5), 90: ST(6), 91: ST(7), 92: XMM0, 93: XMM1, 94: XMM10, 95: XMM11, 96: XMM12, 97: XMM13, 98: XMM14, 99: XMM15, 100: XMM2, 101: XMM3, 102: XMM4, 103: XMM5, 104: XMM6, 105: XMM7, 106: XMM8, 107: XMM9.

And these are the classes of registers:

Class ID	Number of regs	Reg size	Alignment
1	16	4	4
2	16	8	8
3	16	2	2
4	4	2	2
5	16	4	4
6	4	4	4
7	16	8	8
8	20	1	1
9	7	8	4
10	8	8	4
11	16	16	16
12	8	8	8

AMPL

noreply@blogger.com (Fernando Magno Quintão Pereira) — Fri, 07 Sep 2007 22:23:00 +0000

Today I used ampl for the first time. To use it, follow the following steps:

specify a license file: setenv ILOG_LICENSE_FILE "/usr/share/ilog/ilm/access.ilm"

start the daemon process: ./ilmd &

run the ampl command: ./ampl

in the command prompt, it may be necessary to specify the solver to use:
option solver '/usr/share/ilog/ampl20021038.cplex91/cplexamp' ;

Enjoy!

Command tags for SPEC2000

noreply@blogger.com (Fernando Magno Quintão Pereira) — Tue, 27 Feb 2007 19:50:00 +0000

By the way, I found the following list of parameters to run SPEC2000. I took it from Design and Implementation of a Lightweight Dynamic Optimization System, a paper by Jiwei Lu, Howard Chen, Pen-Chung Yew and Wei-Chung Hsu. Thanks for writing the paper, guys :)

Benchmark	Command Line Input
ammp	`< ammp.in`
applu	`< applu.in`
art	`-scanfile c756hel.in -trainfile1 a10.img -trainfile2 hc.img -stride 2 -startx 470 -starty 140 -endx 520 -endy 180 -objects 10`
bzip2	`input.program 58`
equake	`< inp.in`
facerec	`< ref.in`
fma3d	`< fma3d.in`
gap	`-l ./ -q -m 192M < ref.in`
gcc	`200.i -o 200.s`
gzip	`input.source 60`
lucas	`< lucas2.in`
mcf	`inp.in`
mesa	`-frames 1000 -meshfile mesa.in -ppmfile mesa.ppm`
parser	`2.1.dict -batch < ref.in`
sixtrack	`inp.in`
swim	`< swim.in`
vortex	`lendian1.raw`
vpr	`net.in arch.in place.in route.out -nodisp -route only -route chan width 15 -pres fac mult 2 -acc fac 1 -first iter pres fac 4 -initial pres fac 8`

Scripts for SPEC2000

noreply@blogger.com (Fernando Magno Quintão Pereira) — Mon, 26 Feb 2007 05:37:00 +0000

I did some scripts to compile the spec programs. They are in this directory. About the new stuff, to add/remove the new analysis:

in PhiDeconstruction_Fer::insert_memory_transfer, remove the memory transfers.
in ChordalAlloc_Fernando::spill, remove the slot mapping.
in SplitPhiGroups_Fer::runOnMachineFunction, comment the body, but let return false.

To disable all the LLVM optimizations, just use this command:
llvm-gcc -Wa,-disable-opt v1.c -o executable.

The vpr benchmark (one of SPEC2000), uses X window capabilities. It produces a very cool window. How to compile an X11 application?
gcc main.c -L/usr/X11r6/lib/ -lX11

Check the script to see how to compile 175.vpr.

By the way, I would like to thank Dale J. for helping with the command line for the gap benchmark. Some of the SPEC2000 benchmarks need some special flags when being compiled. You can find those flags in the configuration files of spec2000. In my system, they are in project/fernando/spec2000/config.

Bug solved :)

noreply@blogger.com (Fernando Magno Quintão Pereira) — Tue, 16 Jan 2007 05:47:00 +0000

The bug from January 13 has been solved. The problem was that I was using a value to small as the maximum spilling factor of any register. Result: it happened that all the registers had bigger spilling factors, and no register could be spilled. Silly. Now the spilling factor is 2147483647, the biggest unsigned int in my mac.

Bugs

noreply@blogger.com (Fernando Magno Quintão Pereira) — Sun, 14 Jan 2007 00:54:00 +0000

There is a bug when compiling the benchmark cdecl. To compile the program with LLVM's linear scan, follow these steps:


llvm-gcc cdecl.c -o cdecl
llc -f -regalloc=linearscan cdecl.bc -o ln.s
gcc ln.s -o exec
./exec cdlex.l.in

To compile the program with the SSA-based allocator, do as follow:


llvm-gcc cdecl.c -o cdecl
llc -f -regalloc=chordal cdecl.bc -o ch.s
gcc ch.s -o exec
./exec cdlex.l.in

The output produced by the different allocators is not the same.

Another problem that I am having is in the compilation of sim.c (llvm/projects/llvm-test/MultiSource/Benchmarks/sim). The compilation/execution of this file is a little tricky because of the input tag in the llvm line:


llvm-gcc -DUNIX sim.c -o sim
llc -f -regalloc=linearscan sim.bc -o ln.s
gcc ln.s -o exec
./exec

The bug happens during compilation. When I invoke llc -f -regalloc=chordal sim.bc -o ch.s I get a compilation error.

SPECtations

noreply@blogger.com (Fernando Magno Quintão Pereira) — Sun, 01 Oct 2006 04:00:00 +0000

Today I installed SPEC2000 on the PowerPC. It was quite painful, but
finally it worked. I had to log in as administrator, and then I had
to add these two lines to install.sh:


VERBOSE=1
SPECTARGET=/local/admin/spec2000

Also, I gave the user permission to write everything on the top of the
spec installation directory. The rest is only to follow on
documentation. When it asks to run spec, try this
runspec --action=build --tune=base gzip, e.g, don't give
a --confing option. Anyways, I could not make LLVM to find
the spec :( But I can compile the sources. I just compile gzip, and it
worked fine. Compile all the sources, and give one of the input files to
the executable, for instance, combine.inpute.

Also, I've updated my LLVM version. Well, to install a new register
allocator is different. I knew this before, but I decided to summarize
the steps to help me in the future. It goes like this:

In your register allocator .cpp file add the following include;

#include "llvm/CodeGen/RegAllocRegistry.h"

In your register allocator .cpp file define a create function in the
form;


   FunctionPass *createMyRegisterAllocator() { 
     return new MyRegisterAllocator(); 
   }

and the "installing" static constructor declaration, in the form;


   static RegisterRegAlloc myRegAlloc("myregalloc", 
     "  my register allocator help string", 
     createMyRegisterAllocator);

To force the load/linking of your register allocator into the llc/lli
tools, add your create function's global declaration to "Passes.h".

Add a "pseudo" call line to
"llvm/Codegen/LinkAllCodegenComponents.h".

Apropos, when testing the llc tool, it is better to disable the jit compiler, so the test runs faster:

make TEST=nightly report.html DISABLE_JIT=1

SPEC 2000

noreply@blogger.com (Fernando Magno Quintão Pereira) — Fri, 08 Sep 2006 17:15:00 +0000

I finally got SPEC 2000, and I run the tests on it. For some reason, in my first attempt the compiler produced more than 12Giga of data. Well, this made my co-workers to burst into laugh, and made me to burst into tears. I've updated my llvm, just in case, and after the updating, I got 'only' 1.3 G of data, what is better, even though it is still quite a lot of output. I wonder how the old people should test SPEC on the old times. Anyways, I've got a table here.

More experiments

noreply@blogger.com (Fernando Magno Quintão Pereira) — Wed, 06 Sep 2006 17:06:00 +0000

I could get some more time improvement in my register allocation algorithm. I will be now trying to implement a conversion of three address code instructions to two address code for the X86 port. It worked quite well with PowerPC. The problem is that X86 has much more two address instructions. Annoying architecture... By the way, the new table contains some improvements.

First data checked in!

noreply@blogger.com (Fernando Magno Quintão Pereira) — Sat, 02 Sep 2006 02:41:00 +0000

Hey, I've got some documentation checked on the official LLVM web page!
Thank you for the honor, Chris :)
Hum... I think some more people had the same question as I did, when
testing the register allocation. Here goes the explanation:
In TEST.llc.Makefile, you can set the type of register allocator that
you want:


LLC_OPTS = -f -o=/dev/null -stats -time-passes -regalloc=linearscan

to compare against your allocator, open "Makefile.program", and set


LLCBETAOPTION := -regalloc=your_allocator -fast

After that, you just have to type make
TEST=nightly report.html on project/llvm-test/
An '*' on the report means that your test failed. The report will give you
your compile time, and the running time of the compiled file.

Documentation

noreply@blogger.com (Fernando Magno Quintão Pereira) — Thu, 31 Aug 2006 05:37:00 +0000

I am back working on LLVM. This time I decided to write some documentation about the infrastructure that LLVM provides for register allocation. Check the html.

Short break

noreply@blogger.com (Fernando Magno Quintão Pereira) — Thu, 24 Aug 2006 23:34:00 +0000

I will not be working on the Summer of Code project on the next four days, i.e, there will not be any posting on this period. On this Tuesday night I return working on the project. I have many ideas of how to optimize the code that is been produced.

post X pre deconstruction

noreply@blogger.com (Fernando Magno Quintão Pereira) — Wed, 23 Aug 2006 01:20:00 +0000

I finished compiling one comparison between my algorithm, and LLVM's linear scan algorithm. The results are not very good yet. But I plan to improve them. I already have some ideas of how to do this. Check the comparative table here. In this table, linear scan is the beta compiler, which is producing (unfortunately for me) faster code. By the way, I hope the window of your browser is big, otherwise it will be a bit painful to see all the results nicely aligned into columns.

Final code

noreply@blogger.com (Fernando Magno Quintão Pereira) — Mon, 21 Aug 2006 17:19:00 +0000

With the new C sources, my compiler could pass all the expected tests on C files. I could not find all the C++ libraries, so, it is not compiling all the .cpp files. But the new table is much better than the old one. The final code is here. I still plan to carry on many optimizations on this code, but I think the post-deconstruction of phi-functions will not add any benefits to the register allocator. What should be done is a graph based algorithm that uses maximum cardinality search to find a good coloring. This is my next step, and my project for this September.

stdlib.h

noreply@blogger.com (Fernando Magno Quintão Pereira) — Sun, 20 Aug 2006 04:58:00 +0000

I've discovered why so many tests were failing: my cfrontend was wrong. My version of LLVM does not compile anything that imports stdlib.h. I sort of fixed this by copying the sources from the gcc compiler in my OS (gcc 4.0.1) to


cfrontend/ ppc/ llvm-gcc/ lib/gcc/ powerpc-apple-darwin8.5.0/ 3.4-llvm/ old_include/ stdlib.h

. It seems that it solved this problem, but there are some other problems when compiling cpp files. I tried many tests by hand, using this script. My compiler passed all of them, with the new gcc front end. Also, I discovered another bug: I am not handling the translation of two address instructions. Now I think I am handling it, at least for the Power PC architecture. I implemented a small pass to make this conversion, after register allocation has been performed. The code is here: .cpp and .h. Actually, my compiler did not pass these tests: 2006-01-23-InitializedBitField.c, 2006-01-23-UnionInit.c, but linear scan failed too, so I will assume that it is a bug in the platform.

I just remember that this may be important: besides my own source code, I am changing the following files from LLVM:


include/llvm/Passes.h
include/llvm/Target/MRegisterInfo.h
lib/Target/X86/X86RegisterInfo.h
lib/Target/X86/X86RegisterInfo.h
lib/Target/PPC/PPCRegisterInfo.h
lib/Target/PPC/PPCRegisterInfo.h
lib/Target/PowerPC/PPCTargetMachine.cpp
lib/CodeGen/Passes.cpp

Night tests

noreply@blogger.com (Fernando Magno Quintão Pereira) — Sat, 19 Aug 2006 04:53:00 +0000

Yesterday I tried to run the night test, but something went quite wrong, and it end up stuffing 2 giga of data into my university account. Well, the computer complained all right, and it did not worked out. Anyways, it produced this table. I decided to upgrade my version of LLVM, and tried the whole thing again. The tests are running in this very moment, while I am writing this report. My command line was:

$HOME/Programs/ppc_llvm/utils/NewNightlyTest.pl -parallel -nickname pronesto :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm $HOME/Programs/ppc_llvm/projects/fer_tests $HOME/Programs/ppc_llvm/projects/fer_results

Class ID	Number of regs	Reg size	Alignment
1	16	4	4
2	16	8	8
3	16	2	2
4	4	2	2
5	16	4	4
6	4	4	4
7	16	8	8
8	20	1	1
9	7	8	4
10	8	8	4
11	16	16	16
12	8	8	8

Class ID	Number of regs	Reg size	Alignment
1	16	4	4
2	16	8	8
3	16	2	2
4	4	2	2
5	16	4	4
6	4	4	4
7	16	8	8
8	20	1	1
9	7	8	4
10	8	8	4
11	16	16	16
12	8	8	8

Class ID	Number of regs	Reg size	Alignment
1	16	4	4
2	16	8	8
3	16	2	2
4	4	2	2
5	16	4	4
6	4	4	4
7	16	8	8
8	20	1	1
9	7	8	4
10	8	8	4
11	16	16	16
12	8	8	8