green at spindazzle dot org

It's been a while, so here are some updates from me:

• libffi 3.0.9 left the building on Dec 31.


• I continue to toy around with my lisp-based web app framework for Java servlet containers, blow. I'm hoping to get it running on Google App Engine soon.


• moxie development continues, although I haven't blogged about it in a really long time. What's exciting is that I'm very close to a major milestone in the development of my libre core.

Time to plug my FOSS project to a wider audience again! I'm developing a Free embedded microprocessor called Moxie suitable for implementation in FPGA devices.**

The moxie uClinux port is coming along nicely, and I'm getting really close to running userland apps.

Click here to read the development blog.

That is all!

**I'm developing on Fedora with Java-based tools, so I hope my Fedora and Classpath Planet compadres will forgive me for these periodic intrusions. :-)

Some notes:

• Congratulations to the Fedora team for another great Fedora release


• Congratulations also go out to my friend Andrew Haley for being selected to join the OpenJDK Interim Governance Board. From a GCJ/GNU Classpath perspective, this certainly feels like a "Mission Accomplished" moment (in the non-ironic sense).


• Did you know that OpenSolaris has been ported to an ARM processor? That's certainly a surprise.


• In other embedded news... my own Free Software embedded processor project (Moxie) is chugging along. As of this week the GNU toolchain port is now merged into the upstream FSF repositories. The project blog is here: http://moxielogic.org/blog.

I've been a falling a little behind on my Fedora packages, so thanks to everybody who is either being patient with me or picking up the slack. I'd be happy to have more co-maintainers, or to hand off any of the following to motivated packagers: zynaddsubfx, whysynth-dssi, vkeybd, seq24, phasex, liblo, lash, ladspa-swh-plugins, hexter-dssi, fluidsynth-dssi, fluidsynth, dssi, and aubio.

My microprocessor, moxie, is coming along nicely. I have U-Boot running on the qemu port, which I find amazingly cool. Please read all about it on the moxie blog.

That is all!

A couple of quick notes...

* I've upgraded the "ggx" name to "moxie". moxie-elf-gcc is more fun to type!

* All blogging about this project has moved to a new blog here http://moxielogic.org/blog

If you're curious enough to follow this effort, please subscribe to the new blog, because it won't really be showing up on Planet Classpath or Fedora People anymore.

The moxie qemu port is working decently now, complete with UART simulation. Read all about it here.

I'm back at it after a very long break. The qemu port was working well enough off the 0.9.1 branch, so I started looking at the qemu trunk and, wow, things have changed. The dynamic translator is now using Bellard's Tiny C Compiler backend. This should be a nice improvement over the code template system used in 0.9.1, but it means recoding the translator.

I've got the qemu build hooked into the ggxdev repository now, and will check it in once it starts simulating code again.

I'm at the point with the ggx linux kernel bring-up that running it on something more than the gdb simulator seems like a good idea. The basic sim I've implemented is nice for running user-land style programs with limited IO requirements, but the kernel expects a lot more h/w to be in play. qemu is a popular system-level simulator that does JIT code translation, and it seems to be the natural choice (vs SID, for instance, which is nice technology but doesn't have qemu's community momentum).

I've recently been grumbling about the poor state of kernel documentation relative to what we get with the GNU tools. Well, qemu is in a whole different league. There's very little to go on other than ports to a handful of architectures, but even then there's a lot of variability in how those are implemented. Still, after lots of trial and error, I was just able to execute my first basic block of jitted ggx code:

_start:
ldi.l $sp, 0x200000
ldi.l $fp, 0x0
jsra 0x1074

This is the start of a basic program. We're simply setting the stack and frame pointers and jumping to a routine. Those three ggx instructions currently blow out into 15 qemu instructions that look something like this:

0x0000: movl_T0_im 0x200000
0x0001: movl_r1_T0
0x0002: movl_T0_im 0x0
0x0003: movl_r0_T0
0x0004: movl_T0_im 0x1074
0x0005: movl_r1_T0
0x0006: subl_T0_im 0x4
0x0007: subl_T0_im 0x4
0x0008: movl_T1_im 0x1094
0x0009: stl_T0_T1_kernel
0x000a: subl_T0_im 0x4
0x000b: movl_r0_T1
0x000c: stl_T0_T1_kernel
0x000d: movl_T0_r0
0x000e: movl_T0_r1

ggx's jsra instruction accounts for most of that, as it has to allocate stack space and stash the current stack pointer, frame pointer and return address.

qemu then expands these 15 intermediate instructions into 150 x86 instructions, which appear to execute cleanly. I still have a lot to learn and implement, but it doesn't seem impossible now.

The MiBench consumer_jpeg_d benchmark is 30% faster now that I've added 8- and 16-bit loads and stores with offset addressing. So, for instance,...

  ldo.b $r1, 0x8($r2)

SGI has fixed the SGI Free Software License B.

I pulled my jogl package out of Fedora once I clued into the fact that the SGI Free Software License B wasn't actually a Free Software license. I don't know what this means for jogl now that SGI has gone and fixed things, but I hope that somebody has the time and inclination to figure this out and resubmit jogl.

The ggxdev MiBench harness is working pretty well now ("ant benchmark" will run them). I added my first new instructions based on benchmark results: inc and dec. Prior to inc and dec, you would often see code like this:

ldi.l $r1, 1
add.l $r0, $r1 # add 1 to $r0, and save result in $r0

This is a 8 byte sequence. We can drop that down to a single 2 byte instruction with the new "inc"rement instruction, which looks like this:

inc $r0, 1

It's encoded with a new 16-bit format that includes a single register operand and an unsigned 8-bit immediate value. Similarly, the dec instruction decrements a register by an 8-bit value. Teaching the compiler to use inc and dec was pretty easy. The MiBench results are now 8% smaller and 7% faster.

With the GCC test results looking good and GDB stumbling along better than before, now is the time to port the Linux kernel...

I started with the FR-V linux port because it has a uClinux implementation, and I have a passing familiarity with both the architecture and the kernel maintainer (hi David!). My basic strategy was to copy all of the FR-V bits over to new ggx directories, then hack and slash until it links. Anything I didn't understand I simply replaced with a stub that loops forever. This gets you to something that links very quickly, but doesn't boot very far. Then you simply fire up the kernel in gdb and tackle each hang until it starts to crawl. I also had to implement a Linux console that would talk to my simulator via the swi instruction, just as I had done in libgloss. This gives me IO to the gdb/sim console. So now....


$ ggx-elf-run vmlinux
Linux version 2.6.26 (green@spindazzle.org) (gcc version 4.4.0 20080827 (experimental) (GCC) ) #65 Wed Sep 10 06:02:38 PDT 2008
console [simcons0] enabled
Console: GDB GGX simulator stdio
uClinux GGX port by Anthony Green
Memory 00400000-00800000
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 255
Kernel command line:
PID hash table entries: 16 (order: 4, 64 bytes)

...and then it hangs.

The ggx ISA so far only includes instructions you might use in a typical user-land program. The kernel, however, requires special support. The first thing I've hit is the need for some kind of program status word (PSW) to indicate if I'm in "user" mode or "supervisor" mode. I don't want to use any of my 16-registers for this. One idea is to map the PSW to a special memory location, but instead I've decided to add a new bank of registers to ggx, one of which will be the PSW register.

Earlier in this post I described a new instruction encoding for inc and dec that included a register operand and an 8-bit immediate value. I'm going to use this same encoding for the new instructions Get Special Register (gsr) and Set Special Register (ssr). The 8-bit value will identify one of 256 special registers that we can move in and out of the single register operand. I'll use special register 0 as the program status word. The other 255 registers will no doubt be handy for other system level things.

FESCO just ratified the Fedora Packaging Committee's approval of my Common Lisp packaging guidelines. Excellent.

Also worth mentioning is the fact that Vlad Makarov's new register allocator (the "integrated register allocator", IRA) has been pushed into the GCC development trunk. Vlad is always the first person I see when I visit Red Hat Toronto, and he's been heads down on this project for a very long time. Somebody should update the GCC News page because this is a very exciting development. I've tried it out with my ggx port and it's definitely winning. Check out his paper from the 2007 GCC Developers' Summit.

A few months ago, when I first started looking at exception handling support for ggx, I discovered that it would be really easy if only I had a few spare registers. ggx only has 8 registers, and gcc likes to claim some for itself now and then. EH support is possible with only 8, but far too tricky for my taste.

About that same time I noticed that gcc was emitting a lot of code that looked like:

add.l $r1, $r1, $r2

This means "add the contents of $r1 to $r2 and store them in $r1". We don't actually need three operands for these instructions. Two would do just fine as long as we always put the result value in one of the operand registers.

If you recall, we currently encode three-operand instructions into 16 bits like so:

0ooooooaaabbbccc

oooooo - FORM 1 opcode number
aaa - operand A
bbb - operand B
ccc - operand C

Those three-bit operand fields only let us address 8 registers. But if we only have to encode two operands in a 16-bit instruction, we can do something like this:

0oooooooaaaabbbb

Using 4 bits to represent the operands instead of 3 effectively doubles the number of registers we can address to 16!

The down side is that it's possible that we'll end up with larger code in some cases. For instance,

add.l $r1, $r2, $r3

must now be...

mov.l $r1, $r2
add.l $r1, $r3

Happily, however, giving the compiler 8 more registers actually results in significantly smaller code. Here are some relative code sizes from sample MiBench benchmarks:

Yes, it's fantastic that IcedTea passes that Java TCK. Congratulations! But, personally, I'm more jazzed that Sun will be incorporating Mauve testing into their OpenJDK development process. Mauve is only about a quarter the size of the TCK but, to my knowledge, it is a giant among stand-alone FOSS test suite efforts, with 50+ contributors and ~250k lines of test code.

The Mauve site has a comically dated FAQ (my fault). And, like many an FAQ, it doesn't really list Frequently Asked Questions so much as it lists questions we were hoping people would ask frequently.

It took 10 years, but David Herron finally popped the big question (#8): "I'm Sun. Can I use the Mauve Project's testsuite?". Yes, David. You can!

The audio production apps in F9 appear to be working well with jack audio. Just be sure to add yourself to the jackuser group via System->Administration->Users and Groups. This will give you the permissions you need to run the jack audio server in Real Time mode (the default setting in qjackctl).

There's still no audio production group in comps.xml, so you'll have to do something like the following to install a nice collection of audio apps:

$ yum install vkeybd hydrogen qjackctl ardour rosegarden4 \*dssi\* zynadd\* phasex libfreebob ladspa\* swh\* seq24 csound sooperlooper

Remember, you don't need a MIDI keyboard to have fun. Just fire up vkeybd and use the qjackctl Connections windows to hook it up to synths in the ALSA tab.



Also make sure that your soft synth audio is routed to the system audio ports.



Have fun! And don't forget about the fedora-music mailing list.

There's a new google group for ggx discussion: http://groups.google.com/group/ggxdev

Also, intuxication.org is hosting a mercurial repository with all of the tools sources. Details are available here.

I'm pretty impressed with how easy it was to create and use the mercurial repo at intuxication.org. Nice job guys!