CODEWITHSUNDEEP
compiler-constructionarchitectureprogramming-languagesemulation
Harvinder
Harvinder

Reputation: 274

Programming language evolution vs underlying architecture

Let's say we have a programming language foo. foo has a compiler for System A but not for System B. Now the System B developer can either write his/her own compiler for foo or write a System A emulator that runs on System B and can make use of the compiler written for System A. An obvious advantage of the emulator is that it's not limited to running the compiler and opens up System B to other System A specific programs. The obvious disadvantage in most cases is performance and complexity depending on the systems.

What I'm interested in finding out is which one of these approaches is easier to maintain. For example, let php be the language in question and lets assume that phc is the only compiler available for the language. This compiler only works on Unix-like environments. So the question is, is it easier to maintain a new compiler for Windows (e.g. phc-win)? or maintain a Unix-like environment that works on Windows (e.g. Cygwin)?

Upvotes: 1

Views: 155

Answers (1)

Ira Baxter
Ira Baxter

Reputation: 95334

For the System A instruction set, the emulator is easier to write and maintain. But you always pay a performance penalty, so you have saved on engineering effort for a small number of people, by making the larger number of users less productive.

However, systems are not just instruction sets. The application runs on a virtual machine consisting of the System A machine instructions it uses directly, and the System A OS calls it makes. To run System A applications on system B, you have not only emulate system A instructions, but System A operating system calls. And given the complexity of modern operating systems, this can be a very big effort.

The Linux WINE (WINdows Emulator) does exactly this; this runs Windows binaries under Linux (in various forms). WINE emulates Windows x86 instructions by virtue of running on x86 only Linux systems which means it lets the CPU do the instruction emulation work. Then it emulates a lot of Windows OS calls. Its a big program, under continuous development (for over a decade I think), and has to continually change just to keep up with changes in Windows that Microsoft makes. And it still has a wish/bug list for things it does not do well.

While WINE does pretty well, the effort to build and maintain it are pretty big. You don't see a lot of competition, which suggests that the effort is daunting.

I will note that building a compiler doesn't solve the OS emulation problem either; source code of the application may now compile to native System B instructions, but the OS calls it makes .... the compiler doesn't handle. As compiler engineers, you solve the code portability problem by pushing the OS emulation problem on the application owners. That's an easier problem: they only have emulate the aspects of the System A OS calls on which they depend; they don't have to emulate every aspect of those calls.

Upvotes: 3

Related Questions