I don’t feel particularly good about the following code:

Button increaseTip = (Button)findViewById(R.id.IncreaseTip);

That’s how you’re supposed to do it, though, I’m pretty sure. That’s how you’re supposed to get access from the objects from the XML-based declarative layout files.

I’m in favor of declarative programming, of making more of what programmers do “configuration” and less of it actual writing of code. I don’t feel comfortable having Rice’s theorem applying to my GUI design files. But if you’re going to do it, integrate it better.

The .xml files in res/layout/ are used to create an automatically-generated class, R.java, where you can get ID numbers for each of your widgets. You must then use those ID numbers to look up the widgets themselves, involving a very ugly cast, and a line of code where I say “Button” twice and “increaseTip” twice. It makes me want to use C-style #define’s to write a macro to say:

GRAB(Button, increaseTip)

But the clincher is, we shouldn’t need a macro here. We’re already automatically generating a Java file: R.java could have been generated in such a way as to contain real code:

public Button getIncreaseTip(Activity fromWhere) {
    return (Button)fromWhere.findViewById(R.id.IncreaseTip);
}

This method would have been easy enough to generate, and it would make my programming easier. I would probably just write:

getIncreaseTip(this).setOnClickListener(new OnClickListener() {

...and not bother with a temporary at all. It would save me typing, it would save me repetition, opportunities to get it wrong, etc. Casts should be a warning flag you’re doing something wrong, not an everyday experience.

We’re already auto-generate code; we might as well auto-generate it to be convenient.

Now, if we had a good programming language here, we’d be able to do something like this:

onNamedButtonClick name action = do
    (Button button) <- getNamedWidget name
    setOnClick button action

setUpActivity = do
    ...
    onNamedButtonClick ”increaseTip” $ do
        updateNamedNumberField ”tip” $ show . (+1) . read

Or similar. Haskell bindings for the Android SDK? So tempting... But no.

So, a few things I’ve learned not to do in Eclipse when developing for an Android:

• Never hit the run button while editing an XML document. This will cause your build to fail.
• It will not rebuild your generated Java files when you save the XML documents they’re generated from. Instead, you must hit run. But due to the point above, you can’t just hit run when you’re done editing said XML file. You must switch to a .java file, which might be showing spurious errors due to the out-of-syncness, and then hit run.
• In general, if the system doesn’t build, don’t assume you’ve coded something wrong. Try restarting Eclipse before you think too hard about fixing the error.

Yeah...

ARM stands for Advanced RISC Machine. In its press releases, ARM refers to its processor architecture as a RISC architecture. And this is seen as a good thing — something to differentiate it from the awful mess that is Intel’s ISA, and the even more convoluted x86-64 extension to it.

But its instruction set has been getting more and more complicated. Granted, it’s not in the ugly, pointless way that IA32 is complicated; each of the design decisions seem quite sensible, and there’s no overall problems with the new features taken together. But while I was reading about the IT instruction in Thumb2, I was suddenly reminded of the SKIP instructions from foregone days of yore, and realized they’d resurrected that ancient ISA mainstay — and had excellent arguments why it was useful! The ARM engineers aren’t idealists.

So according to Wikipedia, RISC architectures normally exhibit the following features:

• Uniform instruction format, using a single word with the opcode in the same bit positions in every instruction, demanding less decoding. As of Thumb2, you can mix 16-bit and 32-bit instructions.
• Identical general purpose registers, allowing any register to be used in any context, simplifying compiler design (although normally there are separate floating point registers). Except for now, only the first 8 registers have easy access in Thumb mode, the higher registers requiring different instructions to access them. Furthermore, the PUSH and POP instructions only work on the stack pointer, and the call instructions only work on the dedicated link register, which, not being one of those first 8, are hard to access for other things. ARM has just about the same number of truly general-purpose registers as Intel.
• Simple addressing modes. Complex addressing performed via sequences of arithmetic and/or load-store operations. Due to LDM and STM and pre- and post-decrement, I would argue this was never true to begin with.
• Few data types in hardware, some CISCs have byte string instructions, or support complex numbers; this is so far unlikely to be found on a RISC. Eh.

With the introduction of bounds-checking in ThumbEE, I am reminded of the IA32 BOUND instruction, one I often saw cited as an instruction that made it abundantly clear that IA32 was very much so CISC. In the section “Non-RISC design philosophy” on the Wikipedia article, it says:

With the advent of higher level languages, computer architects also started to create dedicated instructions to directly implement certain central mechanisms of such languages.

Bounds checking fits that, and thus it is a very CISC-y thing to do, indeed.

So what can we make of this? If this were a liberal arts paper, I would have said that I’ve proven my thesis, even though I’ve given no practical application of this knowledge or reason why anyone should care. I guess my point is that things shouldn’t be designed on ideology. ARM is a great architecture; it manages to maintain many of the advantages of RISC. Its ability to save power is extremely impressive, its decoding is much simpler than Intel’s, it is in general a very well-designed architecture. And they did this without maintaining the religious adherence to RISC principles that seems to have been the basis for the MIPS architecture. They focus on the facts and on the data, and their decisions have an empirical basis.

And that’s how all engineers should work. Aesthetic of ideas is all well and good, but the facts should back it up, and concepts should compete on their merit, not their coolness. RISC has made its contribution to processor design, and the lessons learned from the RISC v. CISC war are rather important — IA32 has so many issues it’s not even funny. But, in the end, I think a pragmatic CISC wins the day, and the lessons from it can be carried over to other branches of engineering.

Welcome to The Coded Message, version 3.0. Perhaps I should say: version 3.0-alpha. As of yet it doesn’t support features as fundamental as RSS and commenting — without commenting, I will have no clue how many people read it, and without RSS I will have no way to connect it to Facebook and therefore no way to get people to read it. It also lacks the ability to paginate; the main blog page will automatically display any article I’ve ever posted. Ouch.

One thing I’m not changing: I decided to use HTML5 features like article and time, along with advanced CSS features. This means my browser support is extremely limited. Please do not complain about the lack of browser support unless you are running an up-to-date Firefox/IceWeasel, Chrome/Chromium, or Safari. It’s not going to be fixed.

The upside is, this time it’s using completely custom software and a completely custom theme. I will be able to implement my own spam-filtering, once I implement comments, hopefully ridding me of one annoying source of spam in my inbox. I will be able to have fun with programming adding new features.

My plan is to go through the blog archives of the old versions of the blog and repost the back entries on this version, so as I can have them all in one place together.