[ANN] Squeak on Android

 
Folks -

Sorry for being quiet over the weekend but I was busy with my new toy -
a shiny new unlocked Nexus One which arrived last week fresh from the
Google store.

As a result of my weekend distraction you can now download and run
Squeak on any Android based phone. If you have an Android phone, simply
search for "squeak" in the Android market place and it should find it
right there (sorry, Google doesn't seem to give web access to the apps
in the store so I can't send a link).

Please be aware that this is not a full port yet. It's a weekend effort
to show the basic feasibility. Lots (and I mean *lots*) of things are
still missing from a full port (among those is text input and network
support to name just two of the more glaring ones). However, I would be
*very* interested to hear if (and how well) it works for other
Android-based cell phones. So if you have a Motorola Droid or or a
T-Mobile G1 give it a shot and post some benchmark results.

Performance on the Nexus One is about what one would expect: With
roughly 1M sends/sec and 30M bytecodes/sec it's not exactly rocking but
it's quite usable for most tasks on a mobile device. (Input is
*terrible* though; Squeak's UI is not made for fat-fingered clicks like
mine :-)

Since the code itself is quite messy at this point, it isn't published
anywhere yet. If people are interested in contributing, please let me
know and I'll share what I have even before it's cleaned up. Be warned
though, unless you know how to deal with both the Android SDK and NDK,
Java, JNI, and the Squeak VM it will be a very steep learning curve.

And of course, attached a little screenshot (taken on the emulator; I
haven't found out how to use my phone to make pictures of my phone :)

Cheers,
   - Andreas

PS. I don't recall micro benchmarks on the iPhone - John can you repost
those to see how well the hardware stacks up?

 

On 2010-01-17, at 10:18 PM, Andreas Raab wrote:

> Performance on the Nexus One is about what one would expect: With roughly 1M sends/sec and 30M bytecodes/sec it's not exactly rocking but it's quite usable for most tasks on a mobile device. (Input is *terrible* though; Squeak's UI is not made for fat-fingered clicks like mine :-)

> PS. I don't recall micro benchmarks on the iPhone - John can you repost those to see how well the hardware stacks up?

A dull iPhone 2nd generation gives
21,548,821 bytecode/sec; and 564,465 sends/sec

a shinny newish iPhone 3G S gives:
42,xxxx,xxx bytescodes/sec; and 1,1xx,xxx sends/sec.

Also how many frames per second can it do?  higher performance turned on, oh say bouncing atoms up...


--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================

 
John M McIntosh wrote:
> A dull iPhone 2nd generation gives
> 21,548,821 bytecode/sec; and 564,465 sends/sec
>
> a shinny newish iPhone 3G S gives:
> 42,xxxx,xxx bytescodes/sec; and 1,1xx,xxx sends/sec.

Interesting! I think that means I need to play with optimizations a bit
more - from what I see it looks like the 3GS runs a 600MHz ARM where the
Nexus runs a 1GHz. Did you apply any optimizations i.e., gnuify, or any
ARM specific stuff?

> Also how many frames per second can it do?  higher performance turned on, oh say bouncing atoms up...

Can't do those yet. I'm using an event VM for the Android and haven't
gotten around to integrating timer events. At this point the VM requires
touch input for *any* operation :-) Plus, every cycle is a fullscreen
update both from Squeak to Java and from Java to the display. A bit more
optimization work to be left done here.

Cheers,
   - Andreas

On 2010-01-18, at 7:36 PM, Andreas Raab wrote:

> John M McIntosh wrote:
>> A dull iPhone 2nd generation gives 21,548,821 bytecode/sec; and 564,465 sends/sec
>> a shinny newish iPhone 3G S gives: 42,xxxx,xxx bytescodes/sec; and 1,1xx,xxx sends/sec.
>
> Interesting! I think that means I need to play with optimizations a bit more - from what I see it looks like the 3GS runs a 600MHz ARM where the Nexus runs a 1GHz. Did you apply any optimizations i.e., gnuify, or any ARM specific stuff?

Well yes, I'm sure there has to be a beer in here somewhere, don't see it tho...

No ARM specific stuff unless you consider it might have more registers than an i386...

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================

 
John M McIntosh wrote:
> On 2010-01-18, at 7:36 PM, Andreas Raab wrote:
>
>> John M McIntosh wrote:
>>> A dull iPhone 2nd generation gives 21,548,821 bytecode/sec; and 564,465 sends/sec
>>> a shinny newish iPhone 3G S gives: 42,xxxx,xxx bytescodes/sec; and 1,1xx,xxx sends/sec.
>> Interesting! I think that means I need to play with optimizations a bit more - from what I see it looks like the 3GS runs a 600MHz ARM where the Nexus runs a 1GHz. Did you apply any optimizations i.e., gnuify, or any ARM specific stuff?
>
> Well yes, I'm sure there has to be a beer in here somewhere, don't see it tho...

If you're going to C5 we can take care of it there :-)

> No ARM specific stuff unless you consider it might have more registers than an i386...

Nah, I was just wondering if there was something specific to learn about
compiler switches on ARM in terms of optimizations, say
-fwoohoo-enable-super-fast-arm-dispatch or something :-)

BTW, one of the things I'm considering is to change the event type for
touch events. That's mostly because it seems like on Android you
actually get a coverage for a touch event, i.e., how many pixels were
covered by your fatty fingers. And what I'm thinking here is that
interaction could be *greatly* improved if the dispatch of such events
would take coverage of the target area into account. That means that
even if a click doesn't land "on" a relatively small button that the
button will get the click if it's the ui element with the largest
coverage in the region. I could see this working very well for
relatively small UI elements. However, that does require extra
information (pressure, coverage) and I'm wondering if it's worthwhile to
package and dispatch those events separately. How does this level of
stuff work on the iPhone? Are you dispatching touch events ore are you
dispatching mouse events? Any additional parameters you're passing along?

Cheers,
   - Andreas

In

MCHttpRepository
    location: 'http://www.squeaksource.com/iPhone'
    user: ''
    password: ''

Name: iPhone-VMMaker-Only-JMM.1


I had some changes to handle:

(a) readImageFromFile: f HeapSize: desiredHeapSize StartingAt: imageOffset
This was to handle mmap allocation, but it's obsoleted and replaced a year back with the macros we talked about earlier on image reading

(b) primitiveGetNextEvent

I have a change here where eventTypeIs == 6  if so that's a complex event and you'll find a description of that in the sq.h that I submitted in my microsecond clock changes last week or so.
One of the issues is that the event type coming up is assumed to be an integers.  However I change slot 4 to point to an oops.   What is in the oops is platform dependent.  I did have some
constants I added for iphone touchs, and the generic location, acceleration data.

The ioGetNextEvent then is responsible for population slot 4 with smalltalk object.   Althought the engineers at Apple tell me there *might* be touch area & pressure data, it's not accessible
so you get the four types of events, the object is a set containing one or more items to enable the handling of 4 fingers down... 2 fingers up... with twist rotation on the other two fingers.
Then in EventSensor(whatever) I deal with the interpretation of the complex object type.  So no decision is done in the VM.

 
typedef struct sqComplexEvent
        {
                int type; /* type of event;  EventTypeComplex */
                unsigned int timeStamp; /* time stamp */
                /* the interpretation of the following fields depend on the type  of the event */
                int action;        /* one of ComplexEventXXX (see below) */
                usqInt objectPointer; /* used to point to object */
                int unused1; /*  */
                int unused2; /*  */
                int unused3; /*  */
                int windowIndex; /* host window structure */
        } sqComplexEvent;

#define ComplexEventTypeTouchsDown 1 /*  */
#define ComplexEventTypeTouchsUp 2 /*  */
#define ComplexEventTypeTouchsMoved 3 /*  */
#define ComplexEventTypeTouchsStationary 4 /*  */
#define ComplexEventTypeTouchsCancelled 5 /*  */
#define ComplexEventTypeAccelerationData 6 /*  */
#define ComplexEventTypeLocationData 7 /*  */
#define ComplexEventTypeApplicationData 8 /*  */



On 2010-01-18, at 11:30 PM, Andreas Raab wrote:

> BTW, one of the things I'm considering is to change the event type for touch events. That's mostly because it seems like on Android you actually get a coverage for a touch event, i.e., how many pixels were covered by your fatty fingers. And what I'm thinking here is that interaction could be *greatly* improved if the dispatch of such events would take coverage of the target area into account. That means that even if a click doesn't land "on" a relatively small button that the button will get the click if it's the ui element with the largest coverage in the region. I could see this working very well for relatively small UI elements. However, that does require extra information (pressure, coverage) and I'm wondering if it's worthwhile to package and dispatch those events separately. How does this level of stuff work on the iPhone? Are you dispatching touch events ore are you dispatching mouse events? Any additional parameters you're passing along?
>
> Cheers,
>  - Andreas

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================