Re: Can someone tell me why N900 and not Android?
 

Aah. I didn't realize Dalvik's VM was that different. I thought that, like the libraries, it was also a subset. (and, yes, I understand register based vs stack based ... I cut my assembly teeth on VAX-11 assembler ... and, RISC vs CISC isn't exactly register vs stack ... there were pre-RISC stack based architectures, and I think (but am not sure) that there are register based RISC architectures, as well)

Re: Can someone tell me why N900 and not Android?
 

Did people see that the Milestone (German version of the Droid) has multitouch, even though the Droid doesn't: http://www.engadgetmobile.com/2009/1...what-droidont/

What's up with that? For entertainment value I like the conspiracy theory that Engadget refers to, that Apple somehow killed it in the U.S., but that doesn't really seem believable. The Milestone is also GSM, with 850/1900/2100 UMTS, so I guess people on AT&T could grab an unlocked one, if they become available.

Re: Can someone tell me why N900 and not Android?
 

It is also kind of a PITA that these android phones require some type of web based account to even 'activate' them. With the G1 you had to either use an existing google account or create one. Not sure how it will be with the droid, but I am sure it is similar if not worse.

Same with the 'motoblur' it is just as much of a service as it is an interface design.

Nokia, I guess, is kind of starting to do this too with Ovi, but at least with their devices you don't HAVE to use the manufacturers or the OS providers web based services just to use the phone.

Re: Can someone tell me why N900 and not Android?
 

Isn't the key purpose for the byte code in Android is so multiple chipsets can be supported? If native, the apps would lose that portability. The apps would probably be more hardware efficient as native, but more specific coding to support multiple chipsets. Lots of splintering. Correct?

Re: Can someone tell me why N900 and not Android?
 

Yeah, I figured you knew that -- edited above for clarity.

Sorry, I just meant to give an analogous, but better known, architecture dispute that was similarly long-running and unwinnable and to avoid people wondering "but which is better", not to suggest they were the same dispute.

And yes, there are register RISCs; you probably have one in your pocket (ARM). ;)

Re: Can someone tell me why N900 and not Android?
 

@john,

Very interesting vision!

My primary goal with the original post was to get interesting feedback as to their predictions of the future of handsets from a architectural perspective, and even more interestingly, what they would do moving forward; in short to put the members of this forum in the role of the OS designer. The 'which do you think is better' is succinct, but too ambiguous and misleading, and more than likely to start a flame war. :p . I will choose more careful wording next time. From this perspective it is nothing more than interesting conversation.

But I appreciate your vision, and your would-be actions given extreme resources.

An interesting side bite:
From what I understand there are provisions for running native code from dalvik (two)bytecode, for increased performance or access to system facilities. This comes in the form of native libs as well as general JNI support. Android actually uses quite a bit of native code throughout (eg. webkit, opengl, freetype, etc), though it may be a bit tricky to install such libraries given the android app/install manger -- which I know nothing about!


@ben,

I'm interested to hear your thoughts!


}:^)~

Re: Can someone tell me why N900 and not Android?
 

@john

Building on your wonderful idea of a multi-platform binary:

It would be interesting to meld the cross-platform characteristics of a bytecode language with the performance of natively compiled code (with the exception of assembly). How? Read on, my good friend!

The bytecode (eg. register-based dalvik) would be compiled (not a new concept at all, I am well aware!) to native code.

But this raises a very large problem. Doing a JIT on large applications or spread across many libraries could eat into performance and memory, especially in a constrained device like a low-power phone running on a 1999 architechture.

The solution is simple: caching. By caching natively compiled code, you gain a large benefit: that you needn't re-compile code for each run. The VM can do a quick check, a quick load, and an update to its offset tables upon execution, and you have the benefit of native execution speed derived from once-was interpreted bytecode.

But there's still a problem! Caching a complete application will invariably result in ~2x the storage requirements of a single app. This especially unnacceptable on a contsrtained device. But there is a solution to this as well!

A special class could be inherited when building an 'to-be-compiled' sub-classes. For these classes, although byte-code would be generated by the compiler, upon execution of the interpreter, a JIT compiler would recognize the class as 'to-be-compiled', compile to native code which would then be cached somewhere on the FS, and stored in memory for the duration of that process. The class could be empty, only its namespace as significant information, and thus be safely passed over by non-compiling interpreters.

The use of a special inherited class is key, as it allows the developer granular control over the code that would be natively compiled and run, which is adequate for speed critical portions of code (ie. inner-loops). Thus the interpreter would flag this code for cached-compilation, leaving the other code for regular vanilla interpretation. This prevents the code-bloat and potential performance losses associated with compiling the entire process bytecode for each instance and only focuses on the areas that are deemed necessary-to-optomize by the developer. The special class (or some similar mechanism) is used by the VM to differentiate code. Also, it maintains 100% backward compatibility with older bytecode that does implement have the special 'compile-flag' class.

This scenario requires a tiny bit of modification from the developers perspective, but could be made easy enough. The benefit though is huge: native execution speed from a universal bytecode.

It's of interest that Googles V8 javascript engine compiles Javascript directly to native code, completely bypassing the need for an interpreter, and increasing the speed of execution *significantly*. Considering that Javascript is a dynamic-typed language, a native compiled static-typed language like Dalvik bytecode should achieve even higher levels of performance, and there's little reason why it cannot match the performance of natively compiled C.

}:^)~

Re: Can someone tell me why N900 and not Android?
 

I seriously hope we get Dalvik for Maemo... Daelvik? Maelvik? Dalmo? It would be wonderful to have that kind of cross-platform compatibility :)

Re: Can someone tell me why N900 and not Android?
 

I also hope that there's an android layer built on top of maemo. It would be awesome to open maemo up to the growing library of android apps, and further empower maemo.

}:^)~

Re: Can someone tell me why N900 and not Android?
 

Maemo + Android > Android