Rockbox Technical Forums
Rockbox Development => Starting Development and Compiling => Topic started by: zajacattack on December 03, 2007, 08:39:42 PM
-
Why is rockbox still using the old C code? Why hasn't it upgraded to a newer language, e.g. C++, Java? Wouldn't that make it easier to manage and more consistent?
-
I would recommend this article:
http://en.wikipedia.org/wiki/C_(programming_language)
-
Zajackattack, have you considered starting a blog?
-
Upgrade? Java?
-
Zajackattack, have you considered starting a blog?
OK, I'm zajacattack, not zajackattack (actually, it's a common misconception; my last name is Zajac and people always want to spell it with a "k" or "ck").
Beside that point, why? I don't think there's any reason for me to, do you?
-
Why is rockbox still using the old C code? Why hasn't it upgraded to a newer language, e.g. C++, Java? Wouldn't that make it easier to manage and more consistent?
Could you explain why that would make it easier to manage and more consistent? We may have missed something...
-
Also, converting a couple of thousand lines of code to another language is not exactly fun or something you do in a weekend...
-
A couple of thousand ?
Try nearly 481,000 according to ohloh,
and according to me :
wc -l `find . -regex ".*\.\([ch]\|cxx\|cpp\)"`
I get 649,287, though this is probably including a lot of revision history too.
-
The answer is this in my view:
Small embedded systems require small binaries written by cluefull people. The original Rockbox firmware binaries had to be less than 200K. Java is just not fast enough, not portable enough, wasn't free enough and isn't small and lean enough to be a good embedded choice for tiny devices. And there aren't many skilled java- programming people around in the embedded open source world.
C++ is not a good choice simply because several of us who started Rockbox just don't like C++ (nor java actually), and the fact that lots and lots of the 3rd party libs we use are plain C and we use them as unmodified as possible.
Java and C++ may have more hype and people who doesn't know things properly talk about them, but the way of C is the raw, fast, powerful and mighty way things get done in the embedded and open source world.
-
A couple of thousand ?
Try nearly 481,000 according to ohloh,
a couple of thousand, a couple of hundred thousand...
you say tomato, I say tomato ;)
(was too lazy to check it out myself)
-
Also not all compilers are available for Java or other programming languages, while C is supported by almost any compiler...
-
OK, so I know Java is out of the question, but what is the problem with C++?
-
I think Bagder already answered that question.
-
C++ is not a good choice simply because several of us who started Rockbox just don't like C++
Well, I was curious to whether there was an actual reason other than "not liking" C++.
-
C++ tends to result in large programs. This is fine on a desktop computer with gigs of processor power, gigs of RAM and gigs of hard disk space, but is a problem on a battery powered DAP with a lot less power and capacity.
-
C++ is not a good choice simply because several of us who started Rockbox just don't like C++
Well, I was curious to whether there was an actual reason other than "not liking" C++.
Well, yes there was:
...and the fact that lots and lots of the 3rd party libs we use are plain C and we use them as unmodified as possible.
FYI, some (performance-critical) parts of Rockbox are written in assembly. Now that's a proper programming language, none of these silly abstractions and high-level functions... ;)
-
As well, a lot of C++ features require dynamically allocated memory - which of course Rockbox :
a) Doesn't do.
and
b) Will never do.
-
OK, I see now. So, C++ is better for high-power computers, but not efficient enough for MP3 players, right? Also, I know some is written in assembly, as that is the most efficient code (exact control over processor, smallest executables, etc.). And, I read about the dynamic allocation of memory. So, I'm curious, why will rockbox never do that?
-
http://www.rockbox.org/twiki/bin/view/Main/WebHome?topic=WhyNoMalloc
-
In line with the assembly comments above, programming languages are just a convenient way of writing assembly, just more abstraction, so less lines to write and this makes complex code easier to understand for most programmers.
The compiler then turns the code written in other languages into the actual instructions that the cpu executes.
So in an ideal world C, C++, Java and all the other compilers would produce the same executable code. However this is not always the case....
h
-
No, JAVA would never produce the same executable code, because java (when used as intended) isn't compiled to assembly, it's compiled to byte code which then an interpreter deals with and executes code, which is one of the primary reasons it's essentially physically impossible for java to be as efficient at C or C++.
Edit for technical correctness: java can be faster than C or C++, in some general use, because the interpreter can be pre-optimized in some ways. But a C or C++ program properly handled should always be able to perform faster than a JAVA program doing the same thing, if enough time and effort is spent, while ava has some advantages for the more general cases.
In an ideal world C and C++ would be create identical executable code when given identical algorithms, but then identical algorithms in C and C++ would probably *be* identical code. ;)
But yeah, the distinction between C and C++ is more that C, being a "simpler" language keeps the coder more explicit, while C++ lends one to abstractions that, while often making the code "easier" to read (I put such words in quotes, because they're very subjective) tends to leave the code less explicit and more generalized, as the intent with C++ is for the programmer to write in an "object oriented" manner.
-
No, JAVA would never produce the same executable code, because java (when used as intended) isn't compiled to assembly, it's compiled to byte code which then an interpreter deals with and executes code,
But doesnt this ultimately have to be approximately the same code? (It has been 20 years since I studied programming in any formal sense.)
h
-
Well sort of, but Java takes the long way round to get there. C/C++ will be much closer to the final machine code representation. Assembly closer still.
-
So, the lower-level the code, generally, the closer to exact machine code right? The most efficient would be to program in machine code, but as this is pretty much impossible, the code ends up being, in order from most to least efficient:
(1) Assembly
(2) C
(3) C++
(4) Java
(5) C#
...
I am correct, right?
-
Well it also depends on the compiler. If you had a real crappy C compiler, and an awesome Java compiler, the Java code would run faster.
You could write something in assembly badly, or write something in C, that the compiler optimises very well.
-
It's more like there are tiers.
Machine Code / Assembly leave you in more or less exact control of what the processor does.
Compiled languages that are compiled directly to executable code like C / C++ / Fortran and others are turned into machine code, so you're pretty close to direct control, but have to depend on the compiler to make the right choices during conversion. The smarter the compiler, the better.
Then comes languages compiled into bytecode like C# and java. These languages are sort of a halfway point between the last tier and what will be the next tier. Their nature allows them to be optimized in some ways that allow them to be much faster than a purely interpreted language, in general, while at the same time keeping their compiled form from being specific to one hardware. This means if you have a java program it should run on any computer with the appropriate version java installed, independent of where it was compiled originally, for example.
Then comes interpreted programs. These are generally the least efficient. They're never directly turned into machine code. Instead essentially a program reads them line by line, and then goes and does what that line said, then comes back and gets the next line it's supposed to get, and does that. This does mean though that in testing you don't have to recompile every time, you just have to make your changes and start running again. These are also sometimes referred to as "scripting languages" though there can be subtle distinctions that people will make, and I won't go into here.
Generally speaking the further you move down that list, the less direct control you have over what's done, and the more you have to trust in someone else for your optimizations.
-
Then comes interpreted programs. These are generally the least efficient. They're never directly turned into machine code.
Except at runtime. Otherwise they wouldn't work at all. Computers don't run anything that isn't machine code.
They get parsed turned into machine code all at run time, hence they're slower than things like Java and C#, which get parsed and turned into bytecode once when you "compile" them. Then the bytecode is turned directly into machine code by the virtual machine which runs the program.
-
Well technically speaking the Java->bytecode or C#->bytecode phase is indeed compilation, it's just that it doesn't target the language which is spoken by the processor on the system which the program is intended to run on. This bytecode is then either interpreted at runtime, or compiled down to machine code just before runtime by a JIT compiler (or sometimes in advance, if you want to save some startup time and don't need the distributables to be portable). Ultimately, if you've got a good VM and a good JIT, you can get something close enough to the performance possible with a lower-level language to suit ordinary desktop applications very well, and that efficiency loss is usually acceptable in exchange for the programmer productivity boost from using a modern, well-designed high-level programming language.
I'm obviously not referring to Java when I say 'well-designed' though.
C is a good language. You can do pretty much anything you want in it, and you can do a lot of things well (although not necessarily easily). A superb choice for programming something like Rockbox though. How can you write the kernel of an operating system in a language which requires a virtual machine to run? What would the VM run on? Being close to the hardware there really really helps.
I wouldn't dismiss C++ myself, but that's probably because I'm a C++ programmer. Rockbox's decision not to provide malloc() rather nukes most of C++'s easy features though. In an environment which does have full memory management, it's quite capable of being just as fast and lean as C. You do have to be careful with it of course.
Ultimately though, Rockbox just had to be written in C. Multiple architectures (rules out using all assembler, along with an assumed desire from the developers to preserve their remaining hair), tight memory limits, tight hardware limits... if you're not in a reasonably low-level language, you just don't have enough control to pull it off.
Probably best to ignore all that though. I don't develop against Rockbox at the moment, and I may well never start.
-
Probably best to ignore all that though. I don't develop against Rockbox at the moment, and I may well never start.
I don't know, seems a pretty good explanation to me :)
-
I'd object to the comment about Java not being well designed, but that's getting really off topic ;)
-
Well you're entitled to your opinion on the matter of course...
You're right, a debate about the relative merits of Java would be wayyy off topic. Not going there now. Quite a few of my colleagues took their SCJP 5 exams yesterday, so I suspect the topic will come up at work and satisfy my urge to moan :)