Reverse-engineering seem to be this big misunderstood mystery to a lot of people, even to some of the wiser ones so let’s make this clear once and for all:
Decompilation of arbitrary machine code in the sense machine code to any high level language is possible. It is not an easy task but still very much possible and it doesn’t matter what language, which compiler or what interpreter that was used in the process of creating the machine code - it still can be reversed engineered to any other language supporting the corresponding function.

Think of it like this: Your machine code gets interpreted by the processor all the time, it won’t care about what is code and what is data it only need to understand directives and rules but don’t need comments on how anyone wrote the code or what the naming convention was used on variables or types - this is the type of code you will able to get if you decompile; an uncommented, generically named, indifferent to data and function since these instructions are gone. The outcome will have little or no similarities with the original source code of the program beeing reversed engineered. Any decompiler will most probably have a problem understanding some assembly lines so it will need to be able to run inline assembly in the high level language, even statically linked types or methods might cause some head rush to any decompiler.

In the end a few lines of reversed engineered C will still need a lot of attention and probably won’t succeed all the way leaving you with a headache - but still, its very much possible.
So you could create a generic decompiler of machine code for any processor type and to any high level language that would support the function of the machine code (Please, time travelers of the future; if you read this, we need this program ASAP, stop hogging it!).

Since Java and .NET are JIT compiled mid-level language, they are much easier to decompile than machine code. Here are some tools for you:
Reflector for .NET
Mocha for Java

Learn more:
Martin Ward - Pigs from Sausages? Reengineering from Assembler to C via FermaT Transformations
http://www.reverse-engineering.net
http://www.openrce.org

/ itcommie

In 2003 processor manufacturers hit the wall, it was clear that you simply cannot produce a processor much faster at reasonable costs. Intel first delayed its planned introduction of a 4GHz chip until 2005, and then in fall 2004 it officially abandoned its 4GHz plans entirely. The solution was the multicore processor and today most servers and even workstations are already running multicore processors but allmost no applications take advantage of the technique.

The free lunch is over, Dr. Dobb’s Journal stated in 2005, continuing:

Chip designers are under so much pressure to deliver ever-faster CPUs that they’ll risk changing the meaning of your program, and possibly break it, in order to make it run faster 

The key to performance improvement and the survival in a multicore enviroment is simply to write programs that naturally scale up to multiple processors. Unfortunately, it is still very hard to write parallel algorithms that actually take advantage of such architectures, and it’s very hard to write concurrent code that scales dynamically (without recompilation) as more parallelism becomes available in the hardware. Parallel programming has been around for quite some time, just not the in modern meaning of the word. In the old days, parallel programming where simply math based operations parallelized over a number of computers, not cores.

Some rendering, encoding and math operations has already adopted the parallel programming technique over multiple cores, this is because scaling these operations over multiple cores is fairly easy in relation to some other types - such as modern applications reading data from external source.
For example; when an application call a database the operation becomes really hard to scale. For these types of operations we should start looking at async and threading instead of the usual sequential database calls - this way we can apply parallel operations to threads instead, which is much easier. Here is an example of this in the C# language trough the .NET Framework.
By parallelizing threads we can also, for example, make loops which normally are sequential operations very effective. These operations would in any language be similar to math calculations in gain of speed where each core reduces the load by 2 (In a perfect scenario that is).

So, evaluate your need for multicore processing applications, find out how your active and/or new solutions can implement it using its current language and/or framework, do this today and you can sleep well assured you’ll still be having your free lunch every day of the week.

More on this topic later, bye for now.

Libraries:
Microsoft Research has developed a .NET library to help exploit multi-cores chip, it called the Parallel FX Library.
OpenMP is a parallel programming library intended for the C language even if its parallelization is intended for multiprocessor environments it has the potential for multicore processing.

Learn more:
http://en.wikipedia.org/wiki/Parallel_computing
http://en.wikipedia.org/wiki/Parallel_programming_model

/ itcommie