QEMU: Carry and Carry Copy

AEMB is a family of highly-rated open-source embedded microprocessor core. All the programs for AEMB have to run in a simulation environment, because the core has not yet been implemented in silicone chip. Recently, one of the interns is assigned with the porting of AEMB for QEMU. With the QEMU ported for AEMB, it serves as a platform for application to run the embedded microprocessor.

QEMU is a processor emulator that relies on dynamic binary translation to achieve a reasonable speed. The core of QEMU is Tiny Code Generator (TCG). It is a code generator which translates code fragments (basic blocks) from target code to a code representation which can be run on a host. In our case where x86 platform is used for the emulation, the code generator is responsible for translating Microblaze’s code to code representation which can be run on x86 architecture.

Since linux kernel is to be executed in QEMU, it is therefore crucial to verify the correctness of AEMB behavior in QEMU. A test program is compiled with the aim to investigate the behavior in AEMB ported QEMU.


#include <stdio.h>
#include <stdlib.h>
#include "aemb/core.hh"
#include "simboard.hh"

return 0;
}


aemb/core.hh and simboard.hh are AEMB library. They are mainly used for thread locking and defining stdio addresses. MSR and interrupt operations are defined by preprocessor macro. The program is started by setting carry bit, followed reading and storing MSR in variable beforeInt. Interrupt is enabled, and it is disabled after some delay implemented using for loop.

When interrupt is enabled, the program jumps to interrupt handler, which clearing the carry bit and acknowledge the interrupt. After interrupt is disabled, MSR is read and stored in afterInt. The MSR before and after interrupt are printed out. The output of QEMU for the test program:


MSR before interrupt : 20000404
MSR after interrupt : 20000404


The test program shows that CC bit is not set when C bit is set. This problem must be solved, because many operations depend on CC bit in MSR. As the result, the codes in QEMU that perform operation on MSR have to be modified, so that QEMU is mimicking the correct behavior of AEMB.

After much investigation, the function that causing CC bit not set is found to be dec_msr, where the decoding of MSR happens. In dec_msr, the operation of setting or clearing a bit is determined by decoding the op-code, where a ’1′ in bit 15 is msrclr, and ’0′ is msrset operation. The most important operations are done by following codes:


if (clr) {
tcg_gen_not_tl(t1, t1);
tcg_gen_and_tl(t0, t0, t1);
} else
tcg_gen_or_tl(t0, t0, t1);
msr_write(dc, t0);


The bit location is determined by immediate value encoded in the op-code. The immediate value and MSR are first stored in t1 and t0, respectively. clr determines whether the op-code is msrset or msrcls. If the op-code is msrcls operation, if (clr) statement will be executed. The immediate value is inverted, followed by AND operation with MSR to mask the cleared bit. On the other hand, if op-code is msrset, the immediate value is OR-ed with MSR, and the corresponding bit in MSR is set. However, in the case of setting carry, i.e. msrset r0, 4, only carry bit is set, and CC bit in MSR remained untouched.

The problem can be solved by first checking the immediate value for msrset operation. If the immediate value is 4 (C bit in MSR), MSR is OR-ed with 0×80000004, which is the mask for setting C and CC bit. If the operation is not setting carry bit, the immediate value is just OR-ed with MSR so that the corresponding bit is set in the MSR.

if (clr) {
tcg_gen_not_tl(t1, t1);
tcg_gen_and_tl(t0, t0, t1);
} else {
if (sr==4)
tcg_gen_ori_tl(t0,t0,MSR_CCC_mask);
else
tcg_gen_or_tl(t0, t0, t1); }
msr_write(dc, t0);


Having the modification, the output of QEMU for the test program now becomes:

MSR before interrupt : A0000404
MSR after interrupt : A0000404

where CC and C bit are both set, and MSR before and after interrupt are the same.

Z: Doesn’t She Look Good

Anyone who has a hobby would understand the satisfaction of completing something on which he or she enjoyed working. It doesn’t always look marketable, it doesn’t always look fashionable, it doesn’t always look picture-worthy. But it always looks good to the creator. Anyone who has a job would understand that that is never enough. Anything that looks good only to its creator has little value to the rest of the world and is largely irrelevant in the grand scheme of things. That is partly why we work hard. As creators of beauty, we want to share our creation with the rest of society and want society to find value in our work.

Over the past 2 months, I have created a virtual machine that emulates the AEMB on QEMU with basic IO support. I think it looks good. I think it that others think it looks good too. How do I have this confidence? Well, my code works. My code is modular. My code is documented. My code is expansible. My code…rocks.

I wonder about why I feel so happy when my code works or does what I want it to do elegantly. I wonder why I feel proud of my code. I wonder why I am willing to spend long periods of time typing away—sometimes not even typing but thinking and probing inspiration to hit me. Could this be passion?

define: passion
1 OBSOLETE: suffering
2 a strong liking or desire for or devotion to some activity, object, or concept

It’s interesting how we forget that passion used to mean suffering. It probably inherited the modern-day meaning because people attributed the willingness to undergo such suffering to devotion and strong desire; yet passion will not forget that it means suffering. There will be endless nights and heartless cruelty, unseen tears and hidden frailty. Creators still go on with what they do. Regardless of what comes their way, those who have passion continue to tread the unwalked path and swim the uncharted waters…so that some day, the work of their hands will be seen as something precious and valuable to the world.

The work of my hands is, by the way, never complete. I can only make sure that what I can do is usable and presentable at each stage of ‘completion’. Does she look good? I think so. Yes, I do.

Z: More Than Distance

Programming is bridging the gap between what the code does not and what it should do once it’s complete. Yet there is the age-old adage that code is never complete. It only gets close and then you realize greater potential for improvement—which means you start over from that point on. It’s been 4 weeks since I last blogged. It’s been a whirlwind of 4 weeks since I last blogged.

In the 28 days of not posting on here, much has been attempted and a little less has been accomplished. QEMU on AEMB can now—potentially—support 4 threads. It can also handle basic IO requests; the irony exists because usually printing “Hello world!” is the first piece of code that a programmer writes—now it is a milestone somewhat far in the development of my project. It also is equipped with ethernet and interrupt-handling support although neither situation has been tested at this point. Much effort has been put into compiling test benches to verify the performance of the virtual machine. So many directions, so much development…but they are all so vague, mysterious, and seemingly untestable (until other people create the tests).

How come when I reach out my fingers it feels like more than distance between us?

The complete code is so far away from where I am. I can’t touch it but I can keep writing to get there. But there’s so much to write. And there’s so little that is observable that I wouldn’t be able to pin down the source of errors in the future should I attempt to blaze through everything now. Oh, sigh. Yes, there is more than distance between me and the complete code. There’s hesitation and fear: I should not write too much too fast. Yes, before things grow too big to be out of control. Yes, before bugs grow too deep to warrant a revert.

This project is a journey for me. As evident from this post and the past few posts, it’s been a good one. The ups and downs, the going forwards and the turning backwards…they’ve taught me about myself, about programming, and about life. Is not this just like life? Sometimes you feel strong and confident, and sometimes you feel weak and vulnerable when things start to seem to overwhelm you.

And then you plug in your earphones, play a few songs, pick yourself up, and continue that good work you’ve been doing. Tomorrow will come, and distance will disappear with time.

In this California king bed
We’re ten thousand miles apart
I’ve been California wishing on these stars
For your heart for me
My California king

Z: Revenge Is Sweeter (Than You Were Before)

You might have realized from my previous post that I often bring a lot of emotion to programming. I code best and come up with the best designs when I’m happy and on a roll, but that’s also when I miss the most blatant bugs. When I’m down and struggling, I take longer to synthesize information, but because I force myself to inch my way toward progress, I sometimes discover things I had never known and would never have known had I assumed a working knowledge of what to do next.

Over the past 13 work days, I’ve been working on porting the AEMB to QEMU, an open-source processor emulator. The 100-over hours since receiving the assignment have been a collection of ecstasy (the happy feeling) and head-banging (the sucky feeling). Why those two terms would be associated with the same illegal narcotic is interesting, because they—as I have demonstrated in the parenthetical—are somewhat at odds with each other. Why they would possibly be used to describe my experience at Aeste has nothing to do with their hallucinogenic relation but has everything to do with how I work.

When my code works, I’m happy. When my code doesn’t work but I know what’s wrong, I’m happy. When my code doesn’t work but I have no idea what’s wrong, I start to feel a little frustrated. After a long while of getting nowhere, I wage war with the code. I disown what I wrote and take it apart vehemently in order to expose its weaknesses. I show no mercy and often decide to torture the code: peeling off layer by layer, slicing away veil by veil, having it shout out more and more information at each level until it finally breaks; hopefully by that time it would have given me the intelligence I needed. If not, I modify my tactics and make it go through a more intensive interrogation. “You are my code, how dare you break on me?”

Debugging is a cruel process, like war. It drains my energy and it doesn’t make my opponent (code) feel any better. It, however, is the only option to fix broken code. Given this inevitability, my response is to make programming an experience, not just a task. I approach vanilla code with a shyness, slowly attempting to understand what it does and how it does it. Later on, after knowing it better, I make more demanding requests until it breaks on me and decides to stay unfixed.

Then my debugging response kicks in. This has no bearing whatsoever on how I make friends, by the way. I’ve had great moments of euphoria when I fixed a big bug, but also of prolonged pain when I introduced too many changes in too short a time, resulting in a situation where I spent a full day debugging to no avail. No amount of coaxing would make the code work, and I drastically decided to revert to a previous version and work from a different angle of attack. After a few more hours of modifying-testing-committing, the desired change was introduced without bugs. That was a moment of immense relief. That was a moment of precious victory. That was a moment of sweet revenge.

The AEMB emulator on QEMU is now dual-threaded. It took a toll on me, but there rarely is too high a price to pay for victory in war. There is also a joy often undocumented when the final level is cleared and the final boss is defeated. You look back at the time you spent playing the game, writing the code, or fighting the dragons, and sigh a sigh of satisfaction. A tear wells up as you look at the work of your hands: beautiful. Then you turn around to face the sunset and wonder what challenge awaits you next.

Z: 99 Red Balloons

Some people observe that life is an uphill journey and all that matters is The Climb. I believe no such simple analogy for my career here at Aeste. You may remember that my task is to port the AEMB to QEMU and that I have successfully replicated an existing architecture as a first step. I was under no illusion that what was to come after that would not be much more difficult—but to say that I was completely prepared would be to give an undeserved compliment to my professionalism. Of course, given the style in which I have blogged thus far, you might already have figured out that my professionalism is by no means in accordance with the traditional model of stoicism. My work ethic lies in the key idea that I strive to enjoy all I do and be proud of what I accomplish in the end.

After such an introduction, I think I must continue to demonstrate exactly (to floating-point accuracy) how much I enjoy myself here at Aeste. By the way, Aeste’s hiring and you can join in the enjoyment of an employment that welcomes individual excellence and communal sharing!

In this second phase of my porting the AEMB to QEMU, I have been taking working code apart to analyze, modify, and put back together. Sometimes I discarded the old code after analyzing because writing new code was much faster and cleaner. As programmers well know, changing anything that already works—no matter drastically or not—often invites bugs. In response to the analogy of The Climb, I find that this new world of bugs is more like Duck Hunt or a desert paradise where 99 Red Balloons appear out of nowhere, never at the same time, and never with the same magnitude. I like balloons, but for the sake of argument, I shall be the hunter who attempts to shoot down the floating bubbles. I don’t get to pick my targets, but I get to decide which balloons I attempt to obliterate first.

Hey, if one is able to view all work as play (in professional moderation, of course), one must have achieved a Zen in the office, yes? Not quite. Those who think that the world of play contains no ill-feeling must never have played hard. In some people is an inner drive to challenge limits continuously. In some others is a desire to showcase their skill, art, and finesse publicly. In another set of people is a great fear of screwing up and failing. Most people have a combination of these symptoms (and other quirks not listed here). I have the best disease: I feed off many of these little motivations and say “at least I’m not so extreme in [insert quirk here] that I [insert corresponding stereotype here]“. This infection is great, because I get to work my socks off and still feel good about my comparative normalcy. I still feel frustrated from time to time, but I bounce back quick enough.

Quick enough to shoot them balloons down before they…well…cloud my vision; before I’m overwhelmed by the sheer amount of work I have to do. At time of press, yours truly has a semi-functioning, semi-complete model of an AEMB system on QEMU that can boot up a binary executable. And he is rather proud of it. His socks are still on, which probably means that he has a long way to go before he is overworked.