OSDev.org

Hi Fellow Os Developers,
I am an engineering student pursuing my btech in CET,TVM..India,
I have compiler design this sem , I got an idea -- want's to check its
feasibility. The reduction in performace in
java is due to its iterpretative nature.... What i am trying to do
create an object code (which is platform independent) yet cannot
be executed directly on any system.For execution purpose the
this object code is to be linked to get the executable version....
This linker is a specialized linker which is platform dependent...
The above process need to be done only once (while deploying..)

This should be feasible,becasue almost any modern machine can implement basic data structures like stacks ,queue etc...

Plz advize....
I have partially compleated a compiler that produces x86 code( hopelessly inefficent) .. yets it seems to work fine .. Will submit
it when finished.......

I am afraid this has already been done. Check out the Tao Group / elate. They compile code to a "virtual processor", with the translation to native code being done by the loader (on loading from hard drive), or statically by the installer for really critical code parts.

It's been done: http://en.wikipedia.org/wiki/Common_Int ... e_Language

Nope... CIL is source, Tao VP is object code. And I am not sure about the portability of CIL (ignorance, not fact-based doubt).

I have to insist, though, that Tao was earlier. I hate it when Microsoft gets praised for "inventions" that are nothing more than copycat of other's work.

Solar wrote:Nope... CIL is source, Tao VP is object code.

CIL has a source representation, but how is it not object code? You can produce CIL binaries...

And I am not sure about the portability of CIL (ignorance, not fact-based doubt).

All it needs to be portable is a translator for the target architecture. The Mono project supports CIL on Linux -- it's probably portable to at least a reasonable subset of the architectures that Linux supports.

I have to insist, though, that Tao was earlier. I hate it when Microsoft gets praised for "inventions" that are nothing more than copycat of other's work.

I never said MS invented it, just that the OP is too late to invent it.

CIL is source code, but it has a one-to-one mapping to a sort of byte code which is apparently 'easily' translatable to machine code. The object-orientated instructions are less easy to translate, however...

Assuming you believe the wikipedia definition for source code, of course.

Regards,
John.

Ok, my bad... I didn't even read the article. It's definitely wrong -- CIL is itself a bytecode format, not another form of source code (although as I said, it does have a source code representation).

Languages which target the .NET Framework compile to CIL, which is assembled into bytecode.

This is the part that's wrong. CIL is the bytecode, and .NET/CLI compilers target it directly. There is also a CIL "assembler" that can translate CIL source into CIL bytecode, but it isn't used very often...

So the compilers generate bytecode directly, and "CIL source" is actually some kind of back-translation?

Sounds hauntingly similar to what happens when you call gcc with the "-S" option. The assembler source you get this way is never actually created during a normal compilation, because GCC and GAS communicate through a lower-level protocol usually.

Thanks, I think I understand the CIL concept better now.

LLVM has also done it.

...and Java .class files...

Combuster wrote:...and Java .class files...

Yeah i was starting to wonder where Java had got lost on this conversation... clearly this is simply the idea of bytecode with even less fetures than Java/.NET provide. Also, even though there exists no native architecture to run CIL (I thought it was MSIL )... it is still considered Object Code not Source Code because it represents compiled code. It is also designed to be as quickly convertable to many native Machine Codes while still maintaing manageability. This of course goes for all byte code systems.

EDIT : Note Some people claim CIL is compiled into another Bytecode before distribution and then native compile. This comes from possibility to view CIL in Mnemonics... a form of Assembly for CIL. Source Code CIL is similar to Assembly but in the In-House Microsoft Articles i have seen they seem to use the Term CIL for compiled Byte Code also.

I am happy to know that it is feasible....,Still ther wont come a time
when a compiler can generate code better than a master assembly
programmer...? Any takers for this.......

SandeepMathew wrote:Still ther wont come a time when a compiler can generate code better than a master assembly
programmer...?

Since someone has to write the backend for the compiler, there will always be someone who is better at ASM than the compiler is.

But I'd daresay the number of people beating a compiler backend with their "everyday" ASM code recons in the hundreds, at best. And they are getting fewer, simply because the processor architectures grow ever more complex.

SandeepMathew wrote:I am happy to know that it is feasible....,Still ther wont come a time when a compiler can generate code better than a master assembly programmer...? Any takers for this.......

Genetic code?

Solar wrote:But I'd daresay the number of people beating a compiler backend with their "everyday" ASM code recons in the hundreds, at best. And they are getting fewer, simply because the processor architectures grow ever more complex.

As long as you can't sensibly do things with compilers that can be done easily in assembly I think assembly code is in speed superior to compiler code:
Not all compilers are the GCC -O3
You can't tailor register calling conventions, which is especially a burden on x86 where 5 out of 8 registers need to be preserved under standard calling conventions: EBX EBP ESI EDI, and implicitly, ESP
You must help the compiler in order to have it produce SSE code. Even then it's difficult to enforce a memory arrangement that allows optimal vectorisation by the compiler.
You know the exact preconditions and postconditions of function calls, which you can use to your advantage. GCC can only guess at that.
In all, GCC, and virtually all other compilers, are fundamentally limited when it comes to speed.

That said, an asm programmer with some experience will outperform all non-optimizing compilers, with some more experience -O2 gcc can still easily be beaten, and for quite a bit more gurus than you expect -O3 isn't a problem to beat.

Combuster wrote:You can't tailor register calling conventions, which is especially a burden on x86 where 5 out of 8 registers need to be preserved under standard calling conventions: EBX EBP ESI EDI, and implicitly, ESP

This depends a lot on the system. If you're using whole-program optimization, the compiler can use whatever calling convention it wants. It's only at the boundaries with other "unknown" code that this becomes a problem. Compilers can also do inlining to avoid this overhead.

The overhead of saving registers on x86 is probably not as big as you think it is anyway. In reality, a modern x86 processor has over a hundred registers internally, and uses register re-naming to allocate those "physical" registers to the "logical" registers of the x86 programming model. The processor itself can optimize the saving of register state better than an assembly programmer can, and processors these days are designed to optimize the code typically generated by popular compilers.

There is a huge gulf between what assembly programmers see in the programming model and what is actually going on in a typical x86 processor. You'd need to have a very deep understanding of the individual characteristics of each microarchitecture (Core, Athlon, etc.) and how they handle different types of code in order to optimize your code fully.

for quite a bit more gurus than you expect -O3 isn't a problem to beat.

So, maybe 990 out of the 1000 such gurus in the world instead of 900? If it takes such guru power, then like Solar said, the gurus are probably already working on compiler back-ends.