Rockbox Development > Starting Development and Compiling

Why C?

<< < (6/7) > >>

Llorean:
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.

GodEater:

--- Quote from: Llorean on December 04, 2007, 08:31:14 PM ---Then comes interpreted programs. These are generally the least efficient. They're never directly turned into machine code.
--- End quote ---

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.

MaW:
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.

AlexP:

--- Quote from: MaW on December 18, 2007, 09:39:19 AM ---Probably best to ignore all that though. I don't develop against Rockbox at the moment, and I may well never start.

--- End quote ---

I don't know, seems a pretty good explanation to me :)

safetydan:
I'd object to the comment about Java not being well designed, but that's getting really off topic  ;)

Navigation

[0] Message Index

[#] Next page

[*] Previous page