CRiSP Weblog

Waited for the new JellyBean Galaxy Note I download. Finally available.

Lets download it. 538MB later....

FAILED: I am not going to tell you why, but sorry. I am really stupid.

Hm. Ok, may its me that is stupid. Lets try again. 538MB later...

FAILED: I am not going to tell you why, but sorry. I am really stupid.

This time, *you* are really stupid. Why did you download a whopper of an upgrade and discard it, only to download again? Why not do a validation *before* downloading 538MB file?

Why not actually tell me what is wrong? Is that too much to ask?

So, off to the ROM/rooting sites, and see if I can get it another way.

(My Note is rooted, but why cant the Samsung firmware updater tell you what it didnt like?)

Oh well.

The C programming language is 40 odd years old. In the last two decades, the number of new programming languages has raced ahead - each with their own look and feel.

C is a low level language - as CPU speed increases have stagnated, people have looked at C for more gains in performance. C++ to a large extent improves on C, and negates much of the need for the preprocessor.

But one has to laugh at how much attention is given to compilers, optimisations, libraries and standards. The preprocessor is treated like a diseased lovechild.

In all these decades, the preprocessor has barely gotten any feature enhancements - except for varargs and the # and ## operators.

What is it missing? Well, for one, *intelligence*. Anything. Please.

#include "filename"

Such a great function, but so badly designed. What is the one thing every serious application does? Uses some form of autoconf, so you can do:

#ifdef SOMETHING
#  include "filename"
#endif

Why cant that be in the language?

#include_only_if_exists "filename"

There. That wasnt hard, was it?

Ok, so lets try one more. Assume a header file defines a value, lets call it REG_R0. Another header file defines an enum for REG_R0. Consider the following:

#define REG_R0 0
enum { REG_R0 = 0 };

Of course thats a syntax error above. We can do:

#define REG_R0 0
#if !defined(REG_R0)
enum { REG_R0 = 0 };
#endif

If that enum appears in a header file, we have no way to put the #if statement in there. We might do something like:

#define REG_R0 0
#include_but_hide REG_R0, REG_R1, ... "filename"
#endif

This might mean, pretend the specified values are not defined for the duration of including filename, so we can hide and avoid the syntax error that will result.

Why do I care? Well, DTrace is fighting issues with ARM register names with the "ucontext.h" file which seemingly wants to define register names via an enum. I havent worked out how to resolve this, portably and at the point of issue (rather than modify every source file to change the way #includes are done).

Really, every language implements string and file parser as the day-1 feature, and then adds bells and whistles for the rest of its life to handle this.

C, being a "portable assembler" chooses to ignore the compilation environment, and expects every developer to build inconsistent tools because of the shortcomings of the preprocessor and environment detection.

Why cant we do something like in Perl?

#if $ENV{COMPILER_FLAGS} =~ /-O3/
...
#endif

Oh well.

I've put out a new release of DTrace - this one compiles on my ARM virtual machine (armel architecture - seems to be ARMv5).

This is a major achievement, although the code is ugly and broken. Many areas where we have __i386 or __amd64 are changed to handle __arm__ specific code or are simply left blank.

The interrupts are not plumbed in; SMP isnt handled (my VM is a single-cpu VM).

Theres also issues with the pieces of code which are heavy in x86 assembler (eg syscalls.c).

Dont expect to use this for anything useful, other than a starting point. Having got a complete driver, next is to debug piece by piece these blank holding areas.

One of my little projects was to get DTrace ported to ARM. People using Android, RaspberryPi or other ARM related tools could get the benefit of DTrace.

Now this is not a simple project - but I have started some of the work to prove this.

I had originally intended to use the RaspberryPi to do a lot of the heavy lifting, but was not happy with the RPI as a reliable hardware device and have issues with some of the kernels.

Last week, I took a look at qemu/arm - and can actually run an ARM based virtual machine on my x86 Linux machine. Performance isnt brilliant, but its palatable.

After spending ages getting the network to work - so I could get the requisite packages, I have been updating the scripts and headers/source code to fill in the gaps for ARM. At this point, we are about half way through the user land compilation. Some of the things are annoyances due to the Linux distro (debian 2.6.32 kernel). E.g. the handling of ucontext.h seems to be different.

Once I have user land compiling, I can move onto the kernel - obviously there is a fair amount of 386/x64 code to write for ARM, but am hoping that its viable - especially given that the i386/x64 code is on top of the original SPARC architecture - i.e. we know roughly the bits needing attention.

If I am lucky, at the end of this exercise, it will work on my ARM based VM; it almost certainly wont work on other ARM CPUs or other kernels (ie Android), but at least the heavy lifting will have been done, and it makes it more palatable to target the other platforms (or people may do this for themselves).

I'll put out a new release, which includes some Linux 3.7/3.8 fixes (thanks to those that contributed the fixes or highlighted some of the broken build things in my code).