Skip to content
Archive of entries posted on May 2009

Using ARM Memory Barrier in Symbian OS

Today I have been digging the methods to  to make a gpSP( I think this is the best GBA emulator) port to Symbian OS.Thanks to the Exophase for developing this wonderful piece of software and for ZodTTD for the awesome ARM port! The gpSP is running “generated” ARM binary in the ARM processor’s memory, so the Memory Barrier has to be used. The next problem is to get the code running on the ARM under Symbian OS.

The ARM9 reference manual tells this about Memory Barrier.

Whenever code is treated as data, for example self-modifying code, or loading code into
memory, then a sequence of instructions called an Instruction Memory Barrier (IMB)
operation must be used to ensure consistency between the data and instruction streams
processed by the ARM926EJ-S processor.

Usually the instruction and data streams are considered to be completely independent
by the ARM926EJ-S processor memory system, and any changes in the data side are
not automatically reflected in the instruction side. For example if code is modified in
main memory then the ICache might contain stale entries. To remove these stale entries
part or all of the ICache must be invalidated.

In Symbian OS the Kernel should take care about ICache invalidation. The Symbian has User library for user side interaction with the Kernel. If we want to generate our own code and run it in specific memory are, we have to first tell to the kernel to threat this area as code. The code example for doing this is below.

RChunk codechunk;
TInt error = codechunk.CreateLocalCode(codechunk_size,codechunk_siz);
void* codechunk_ptr = codechunk.Base();

Now the codechunk is created. The ARM documentation told that ICache must be invalidated before executing the code. The Symbian should take care for invalidating the ICache, when IMB_Range is called.

void CLEAR_INSN_CACHE(void* code, int size)
User::IMB_Range( code, (void*)(code + size));

QT Mobile UI design

I have been lately prototyping new SW with QT4 and I have some thoughts about mobile UIs. The QT was originally developed for desktops, so it doesn’t yet have all features required for mobile UI’s. The current literature about QT4 is not very well suitable for mobile development, since the books mainly focus on desktop UI programming. Phones with small screens are very different environment, and you should design the UI very carefully before implementing it.


Tabs are widely used in desktop environment, and I’m not sure how well they fit in mobile devices. It’s already possible to do tabs in S60 Avkon UI, so it should be OK with QT too.

Using different windows/views

In S60 we have views based architecture architecture. Using different views in mobile SW feels like a pretty good idea to me. Most of S60 software uses views, and it’s working really well with small displays. Perhaps you don’t have to create many views with  devices equipped with large screen like Nokia’s tablets with Maemo, but for S60 3.x devices you definitely should use views for them.

In QT4 the views can be implemented with QMainWindow, The QMainWindow can have one menu and several widgets on it. Changing the view is easy, just change the mainwindow on the screen, by deleting the old one, or calling hide() function when you want to change view.

Using keys

All QT4 enabled devices doesn’t have touch screen, so you should also make it possible to use the application with keys only.

Continue reading ‘QT Mobile UI design’ »