Using LiveCode (RunRev) with SDK Platform Android 2.2, API 8, revision 3

The current (LiveCode 4.6.3, Oct 2011) release of LiveCode for Android development does not accept the revision 3 directory structure of the Android 2.2 (Froyo) SDK and needs some directory structure tweaking as below:

Copy the folder




You need to do this when in the Edit menu Preferences dialog for the Mobile Support item, if it fails with an error message saying:
The chosen folder is not a valid Android SDK. Please ensure you have installed it correctly, and enabled support for Android 2.2 (Froyo).


Fragmentation when allocating memory

To reduce fragmentation specially in high-activity code, allocate temporary buffers (buffers that will live only for a short while) from a separate memory pool. The idea is to avoid long-lived buffers and short-lived buffers from being allocated from the same pool.


Coding and Holding The Big Picture in Your Head

I find that I am often unable to complete some piece of code unless I have a mental picture of the whole thing in my head. And this is a huge problem. For small things, it is fairly easy to get a mental picture of what needs to be done and my coding happens fast. But for something that is larger, requiring perhaps a multi-step process with things that can go wrong in each or all of the steps, it is much harder. I keep procrastinating for days on end until my puny brain has wrapped itself around whatever needs be done end-to-end and I feel that I will be able to take care of all the loose ends and all corner cases are considered — mentally. Only then can I start coding.

But this method does not scale and also it’s hard to give a project schedule and tell when you’ll be done with some module :-(.

I need to figure out some way of divide-and-conquer programming where I don’t need to have the entire thing in my head, but have just pieces of it in my head at a time, code that piece and be comfortable that the particular piece has been coded correctly — and that the way it’s been coded it will interact correctly with all the other pieces making the old adage of the sum of the parts being larger than the whole come true.

Oh well. I guess I cannot be everything all the time. Back to wrapping my head around this current problem…why is it that people find web-development easy and I keeping finding it hard and wondering why no-one sees that it is complicated distributed programming? That things can go wrong anytime and everywhere.

How do you deal with coding of such nature? Let me know in the comments.


C Optimization Tips – Dealing with Aliasing

Though in general it is true that you should simply leave C code optimization to the compiler, it sometimes is useful to provide hints to the compiler. This is because when optimizing the compiler has to make a few basic global assumptions so as to generate correct code in all situations, but these assumptions may not be true in your specific code.

A case in point is providing aliasing hints through the use of the C99 restrict keyword or the GCC extension __restrict__. See this excellent article with an easy example that will help you understand aliasing and how to deal with it.


C if-else Optimization

When doing some maintenance work on C code (refactoring!), I wondered if I should code C if-else clauses in some particular way to take advantage of modern processor pipelines and caching.

It seems obvious that if you have multiple else-if clauses, then putting the most likely to execute code in the first if clause would be the best (since it avoids subsequent checks most of the time), but what about the case that you only have a two-way if (cond) {…} else {…}  type of code, should you place the code most likely to be executed in the if clause or in the else clause? It would seem that it shouldn’t matter either way since there is only one condition being checked. But…

I did some experimentation on a system at hand (an Intel Pentium system with a small program compiled using gcc) and found that putting the most likely to be executed code as part of the else clause consistently had better timings. Be warned that this was just a simplistic “add-two-values-stored-in-variables-in-one-line” kind of code — definitely not a good test, but sufficient for me to satisfy my curiousity for the time being.

Google searching seemed to indicate that the performance depended on the ‘branch prediction‘ capability of the processor. I also found out that gcc has a compiler directive (__builtin_expect()) that one can use to provide a hint to the compiler so it knows what is the most likely outcome of a if conditional check and generate code suitable for the branch prediction capability of the target processor. The gcc manual recommends against using this directive though! See more details regarding this directive here.