GSOC 2011: I Recommend Mono.SIMD

If anyone is looking for a good GSOC 2011 project, I would suggest Mono.SIMD. If you don't already know what SIMD is, then this project probably isn't for you, but you might find it interesting nonetheless. Although the Microsoft .NET version of C# does not explicitly support SIMD, once Mono has it for x86, ARM, and others, Microsoft likely will want it as well. The ARM port is just as important (if not more) important than the x86 port, so please don't ignore it. Buy a BeagleBoard or a PandaBoard to tackle NEON SIMD, (or even buy a Plug Computer or Verdex Pro for iwMMXt) . Although some people may think that iwMMXt is old news, it still lives on with Marvell's Sheeva and ARMADA product lines. You can still do blazingly fast multimedia with iwMMXt (h264, for example) but its limited to integer operations rather than floating-point (which is more efficient for multimedia in any case). 

Chances are you already have a PC with several flavours of SSE, so you should be all set to do add x86 SIMD and at least one flavour of ARM SIMD to the Mono JIT. Read this article to see why it makes sense.

PS: Good luck to all volunteering organizations and students this year!

The Future of Android and the Chrome OS

Apparently I'm not the only one to have some innovating thoughts about Android and the Chrome OS. Slashdot has a story that mentions how the two should be merged in the near future. Furthermore, Paul Buchheit, the creator of Gmail, also seems to agree. I'm still a little bit hesitant to disclose all of the technical details publicly, but it would seem that Google is starting to take some steps in the right direction. My plan essentially boils down to taking the Android userspace back to the desktop and incorporating an Android App Screen, much like what Apple showcased at their Back to the Mac event, but also modifying apps so that they are literally write-once, run-anywhere - on any architecture. Incidentally, it would also enable users to run any of the tens of thousands of amazing open-source applications already available, and potentially tie in a revenue system for open-source projects via the Android app store.

Perhaps it was slightly selfish to come up with these ideas - I really just wanted to beautify Linux in both software and hardware, and make the user experience just as enjoyable as it is on a Mac (minus the annoying hard-coded settings). Could 2011 finally be the Year of the Linux Desktop?

Oracle vs. Google, Apache Resigns from JCP

Now that the Apache Software Foundation has officially resigned from the Java Community Process, I think it's fair to say that Oracle has passively waged a war on any entity pairing the terms "open" and "java".

Most people are unaware at just how large and far-reaching of an impact this has. What it boils down to is this

• Oracle is unwilling to participate responsibly for the community revision and release process that they wholeheartedly bought into with their acquisition of Sun Microsystems
• thus, anyone wanting to use a certified Java environment to run their code must obtain that Java environment from Oracle
• therefore, Java, as a specification, will be 100% controlled, owned, and steered by Oracle

This effects everything from the software you can run on your mobile phone, to the software that you can run on your corporate servers - so yea, it's pretty far-reaching. Furthermore, there are probably millions of companies that rely on (open source!) Java technology to do their day-to-day business whose livelihoods are now threatened.

Oracle's only "open source" offering of Java, is OpenJDK, which is completely inadequate in MOST of the cases where I would ever use Java. Let me elaborate. 

I use Java to program for two platforms mainly. The first is a barebones Linux system running on an ARMv4T processor with 32MB of storage. I actually tried to run OpenJDK on it over an NFS root - let me tell you how much of a freaking joke that was. OpenJDK used over 110MB of storage space. My preferred JVM, on the other hand, is JamVM paired with the GNU Classpath, which can be tuned to use as little as 7MB of storage. OpenJDK is bloated, and I'm putting that as euphemistically as I can. OpenJDK takes a century to do anything on this platform. JamVM on the other hand is practically like lightning. In short, OpenJDK is only for desktops and servers. I've never even attempted to use J2ME due to its long list of shortcomings (just google j2me shortcomings, e.g. this).

My second platform for programming in Java is Android, which (openly and welcomely) borrows its Java base from the Apache Harmony Project. I think Harmony has some serious potential on ARM, considering what I've seen so far with Android. Anyone who knows me, knows that I like Android and I think it's a great piece of work. I have personally hacked Android onto several devices, and continually find that it's doing great things with both the native code and Dalvik / Java. One could arguably say, that Android was the best thing to happen to Java in the last decade. Oracle is suing Google, claiming that Google had copied code directly from them (or Sun) somehow, and put it right into the Apache Harmony Project. This is completely ridiculous because Harmony was, in fact, created before Sun made any of its source open. 

Oracle also owns a few patents covering various 'inventions' in the form of software (originally filed by Sun) and they're incorporating claims of patent violation in to the Android / Google lawsuit. Let me be (hopefully not the first) to reveal something here. Sun's original strategy, by filing these patents, was to prevent any kind of patent-related lawsuit that might be inflicted upon Java or any of its users. Indeed, the Sun patents were only originally intended to be defensive in nature. Oracle has turned that around 180 degrees and started using those patents offensively to sue companies that actually do innovative things with Java.

The state of Oracle vs. Google puts Google in a really tight position. I agree (and so do several now-resigned members of the JCP EC) that Oracle has done the worst possible thing that they can with Java as a platform and specification. Oracle's position threatens people from modifying and redistributing Java for whatever purpose they want (source required), which is the fundamental attribute for any piece of open source software according to the definition by Bruce Perens. This means, that Oracle's "open source" offering of OpenJDK might as well be binary-only for any meaningful purpose. 

Now, the Android community, who has had enough vision to do something genuinely new and useful with Java, are relying on a possible court ruling that Oracle's software patents are invalid. In my opinion, they are, but that's only because I think all software patents are invalid. The USPTO, on the other hand, has traditionally given out software patents like business cards. The USPTO is getting more reasonable, and is even revoking software patents in some cases but I feel that it's a dangerous position at large for Google, the Open Handset Alliance, and the Android developer community.

I recently submitted several ideas to Google that should appease both Oracle (from a legal standpoint) and Google in this whole fiasco while simultaneously injecting Android with enough adrenaline, marketability, and sex-appeal to push it even past OS X, the iPhone, and the iPad. I've put in a fair amount of the technical legwork in my free time to see just how realizable this is - and it is very realizable. I've communicated some of these ideas with various developers of original software components and have had very positive feedback. It is doable. Google even responded to me but it's been a couple of weeks and I haven't heard back from them for a while. These suggestions could literally be the best thing to happen to Linux and Android in a long time. I realize that Google is busy (trust me, I understand what its like), but I do hope they reply. I freely offered these suggestions to Google, purely for the sake of securing Android w.r.t. Java. Whether they wanted to give me a job for implementing all of it was irrelevant - I keep myself busy doing the things that I love regardless of who I'm working for.

The solution that I presented to Google was only good for temporary purposes - it still doesn't address the issue of Java as an open specification or Java as an open piece of software. For those reasons, I was saddened today by the announcement of the ASF because it only confirmed Oracle's passive-aggressive position... and potentially the end of Java as a good choice for a programming language.

Edit: I just thought I would point out the self-contradiction of Oracle as well; if you make e.g. OpenJDK available to the public under the GPL, then how can you say that you withhold the right for people to modify it and redistribute it when they provide the source. In this sense, there could be absolutely no wrong done by Google considering they didn't even base their code on OpenJDK but rather on Harmony.

Could Google's Nexus One be Available as Soon as January 5th?

Just as many of you have undoubtedly read, Google released a new handset before Christmas to all of its employees for testing. The device is called Nexus One. A decent video introduction can be found here. One thing to note is that the 3D gaming demo (2nd video) shows Qualcomm's logo, which leads me to believe that the Nexus One most likely packs a 1GHz Snapdragon SoC under the hood. I'm very interested to say the least and am eagerly awaiting the rumored January 5th release date.

Google Chrome Beta on Gentoo Linux

I had already tried the Google's Chrome browser (the developer edition was called Chromium) and thought it was great, aside from a few minor bugs. For  example, sometimes drop-down lists would not have any entries, the menu for the flash plugin would not respond, etc. It looks like yesterday, Google released a beta version for Linux that fixed several of the minor bugs that I noticed.

I modified an ebuild to download an install Chrome from the debian package. In any event, you can put it in your own portage overlay under www-client/google-chrome-bin/, and it should do the trick. You might have to add 'www-client/google-chrome-bin' to your /etc/portage/package.keywords file. To install Chrome, just run PORTDIR_OVERLAY="/path/to/my/portage/overlay" emerge -av google-chrome-bin.

Overall, the Chrome experience is quite good. It's very fast, and I haven't encountered any errors or bugs so far. Most pages render perfectly. You might also want to install FlashBlock.

NVidia Prefers WinCE to Android

There have been hordes of ARM-powered netbooks that have been popping out of the woodworks of Computex this year. One of which was touting the new NVidia ARM Tegra chip.

Here's a link to an article on Slashdot which reports that NVidia is not ready to back Android as a capable platform for Netbooks.

I unfortunately say that I must agree - although its not completely Google, or the Open Handset Alliance, or Linux that is truly at fault - or NVidia for that matter.

The problem is that NVidia would need to expose yet another kernel and user-space ABI (for their latest, integrated Tegra GPU no-less), and they are not prepared to do so. Aside from that, Android performs much of the hardware acceleration (a.k.a. DSP algorithms) for graphic and audio in a completely re-done set of non-portable libraries (the last time I saw the code), rather than using a single, portable abstraction layer such as OpenGL.

My recommendation? End-users should stick with WinCE (as well as the NVidia-modified UI) that will ship with the NVidia-based netbooks - IF THEY CHOOSE TO BUY A NETBOOK THAT USES AN NVIDIA TEGRA CHIP. Certainly, there are many other, more mature ARM chip vendors that will be offering netbook platforms (e.g. Qualcomm, TI, etc).

However, for almost all other ARM cores with unencumbered ABI's and API's for hardware acceleration - by all means use Android! The Android community, which is composed of literally thousands of developers, will have an exponentially greater ramp-up on new technology and software integration speed than NVidia & MS will, as single entities. Plus, as we have seen in the past, the release cycle for Android will likely be more frequent and since it's Open Source. Furthermore, there is less likelihood that Android will fall behind and become unmaintained (which was the whole purpose of the OHA in the first place), while the NVidia & WinCE combination will likely become unsupported and outdated at some point.

Google Genealogy?

I guess because I became a dad about a 9 months ago, I'm experiencing an even larger curiosity of the origins of my forefathers. So today I created the beginnings of Julien's Family Tree, but spun a different approach on it. I used Google Maps.

If you create a Google account, you can actually have a 'My Maps' section on Google Maps. On Julien's Family Tree, each person is represented by a placemark where that person 'grew up', and each line represents a parent / child relationship. Every placemark has a comment associated with it, in which the birth date (and possibly death date) of each ancestor appears, along with comments about the life of that person. Google Maps also lets the user put links to Wikipedia info, photos, et cetera.

What would be really cool, would be if some clever web developer were to integrate the Google Map API, some AJAXy glue code, and a database.

Having directed line segments joining parent and child would be useful. You could graphically see the journey that your ancestors made throughout their life, with fairly accurate historical info one click away at the Wikipedia. Maybe it would be possible to have a dynamic application built to scan the Wikipedia and narrate based on a combination of historical info and per-person tidbits.

I love hearing the stories that my grandparents tell me to this day - they're full of thrills and drama. Every grandparent should have a book or movie created about their lives, in my opinion. I'm really glad that Julien met his great-grandparents. I sometimes wish that we lived around the block, so that we could hang out every day after work ;-)

Android FreeRunner Updates

Well, I feel as though I've made significant progress in less than one day. I have Android trivially compiling for the ARMv4T / FreeRunner! By saying it compiles 'trivially', i mean that all I've done is remove the ARMv5E instruction extensions and gotten the build process to atually finish without errors. See my post on the android-porting mailing list for further info.

There obviously needs to be a different kernel configuration, but Benno has already done that.

Hello, Open-Source World!

It's official... Google's brainchild, Android, has finally said

Hello, Open-Source World!

I wonder how many hours it will take for the first Neo 1973 or Neo FreeRunner port to surface. The biggest challenge, it will seem, will be to provide a bridge between the (minimal) ARMv5TE instruction set that Android was designed for, and the OpenMoko handsets' ARMv4T instruction set (as present in the Samsung 2442 SoC).

Perhaps the next handset that OpenMoko releases will feature native ARMv5TE compatibility.

Update: I've been building android for the last few hours, having made a few build-oriented changes that I think will help bridge the ARMv5TE - ARMv4T gap. I'm going to list a few of the errors I've been running into below. Please note - although I only list each undefined instruction once, the errors occur in multiplicity and in different subdirectories. I will post ARMv4T compliant work-arounds soon. Please be patient.

• bionic/libc/arch-arm/bionic/memcmp.S:44: Error: selected processor does not support `pld [r0,#0]
• system/core/libpixelflinger/t32cb16blend.S:121: Error: selected processor does not support `smulbb lr,r7,lr'
• system/core/libpixelflinger/t32cb16blend.S ... Error: selected processor does not support `smulbt ...'
• external/jpeg/jidctfst.S:148: Error: selected processor does not support `smlabb r0,r2,r3,r5'
• dalvik/vm/arch/arm/CallEABI.S:239: Error: selected processor does not support `blx ip'
• dalvik/vm/mterp/out/InterpAsm-armv5.S:2653: Error: selected processor does not support `ldrd r2,[r0,#offStaticField_value]'
• dalvik/vm/mterp/out/InterpAsm-armv5.S ... Error: selected processor does not support `strd ...'
• external/sonivox/arm-wt-22k/lib_src/ARM-E_mastergain_gnu.s:77: Error: selected processor does not support `smulwb r4,r4,nGain'
• external/sonivox/arm-wt-22k/lib_src/ARM-E_voice_gain_gnu.s:114: Error: selected processor does not support `smlawb tmp1,gainLeft,tmp0,tmp1'
• external/opencore//codecs_v2/audio/aac/dec/src/calc_auto_corr.cpp
  /tmp/ccBi9nUH.s: Assembler messages:
  /tmp/ccBi9nUH.s:652: Error: selected processor does not support `clz r0,ip'
  
• smultt, smlatt, smlawt, smulwt, qadd, qsub, qdadd, qdsub, smlabt
• etc, etc, etc ...
  

Build problems that were not architecturally related:

• out/target/product/generic/obj/SHARED_LIBRARIES/libdvm_intermediates/Misc.o: In function `dvmAllocBit': dalvik/vm/Misc.c:247: undefined reference to `ffs'

Theoretically, there are three possibilities to in order to have Android on the FreeRunner.

• The first is to ] replace [ the red-highlighted mnemonics using an equivalent ARMv4 or ARMv4T instruction sequence. In some cases, this is impossible without a lot of context information.
  
• The second is to completely re-implement each section from scratch, wherever one of the ARMv5TE instructions are issued, but using an algorithm optimized for the ARMv4 or ARMv4T architecture
• The third option is to just remove it, e.g. for the pld instruction which only optimizes memory fetches by hinting (or not?)