2

I know machine language and assembly are specific to the hardware and different hardware involves different machine and assembly code, so Higher-level languages were invented to solve of these problems. It might be very basic but i want to know, should a high-level language be translated to each assembly language to support it's related hardware?

samira riazati
  • 515
  • 7
  • 21

3 Answers3

2

The compiler is the bridge between the langauge and the specific platform, it's the compiler that translates the higher level language to machine code for a specific platform.

Generally a compiler only produces an executable for one specific platform, so for languages that actually work on different platforms (which is not always the case) there is one compiler for each platform.

Although there are languages that have compilers for many platforms (most notably C), there is no language that works on all platforms.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005
  • Are there some microcontrollers that don't have C compilers? Or are you thinking of something like an FPGA that doesn't run sequential code? – Peter Cordes Oct 27 '15 at 08:44
  • @PeterCordes: I don't know, but just because there is a C compiler for it doesn't mean that you can port any C program to it. When the hardware capabilities differ too much the question of whether it's the same programming language becomes moot. – Guffa Oct 27 '15 at 08:54
  • Right, you can have a C compiler even if most of the C standard library is unimplemented (e.g. stdio facilities would be a common thing to omit for a microcontroller). C (without the standard library) is just one step up from asm on typical processors ([by design](http://stackoverflow.com/questions/27977522/how-are-c-data-types-supported-directly-by-most-computers)). e.g. one of [godbolt's](http://gcc.godbolt.org/) targets is an 8-bit [AVR](https://en.wikipedia.org/wiki/Atmel_AVR) microcontroller, where most headers aren't available. – Peter Cordes Oct 27 '15 at 09:09
  • So my complaint is your last paragraph: bare ANSI C (or even C99 these days) pretty much *does* work on all platforms. That's a very different statement from saying that all C programs are portable to every platform. That's obviously not true, because it's really easy to use non-portable stuff in C. e.g. just assuming 2's complement signed integers (no good workaround is available) or 8-bit bytes (use `CHAR_BIT` instead of 8) makes your C program non-portable. More commonly, don't assume `int` is wider than 16bits, or that it can hold a pointer. Let alone system calls / paths... – Peter Cordes Oct 27 '15 at 09:12
  • Probably the best way to phrase it is: you can have a **C compiler** without having a full C99-compliant implementation / platform / system, because the C standard includes the standard library. Also, I think I've heard that the only available compilers for some microcontrollers are developed by the vendor, and are often pretty terrible (i.e. don't support C99). One SO comment I saw recently said that one vendor's C compiler will only compile without optimization unless you pay for a license. – Peter Cordes Oct 27 '15 at 09:18
  • I see that your answer and your comments are most C-centric. The OP specifically asked about high level languages in general, not only one language. How C works doesn't reflect on how most other high level languages work. – Guffa Oct 27 '15 at 11:13
  • High-level languages are usually implemented in C. Getting a C compiler up and running on new hardware gives you all the higher level languages. If it's also a new OS, then most high level languages will need their standard libraries ported, too, which I did gloss over. Like I said in my answer, by historical accident, C is the language of choice for writing compiled-to-machine-code programs that are highly portable, esp. on Unix. – Peter Cordes Oct 27 '15 at 13:42
  • @PeterCordes: Just because a compiler is implemented in C doesn't mean that it *is* C. I wish that it would be as easy as implementing a C compiler and you would get all other languages, but that's not how it works. – Guffa Oct 27 '15 at 13:47
  • I know that in practice it ends up taking some work to port things to a new architecture, usually because some `#ifdef` conditions need to account for a new case. We're talking about same OS, different hardware, like porting GNU/Linux to x86-64 when amd64 was new. Making a good complete performance-competitive port requires implementing a JIT-compiler for the new system (for language implementations that use that), but just getting up and running can happen with a portable interpreter. Can you give a specific example of a HLL that's labour-intensive to port? I'm prob. overlooking something. – Peter Cordes Oct 27 '15 at 13:57
  • 1
    @PeterCordes: Well, that wasn't what we were talking about, but even in such a specific case implementing a C compiler only helps to implement other languages when they are actually based on the C compiler. An example of a language that isn't would be Free Pascal, which is implemented in Free Pascal. To port it to a new platform it has no use for a C compiler for that platform. – Guffa Oct 27 '15 at 16:20
2

A high-level language either has an interpreter (typically written in portable C), or it has a compiler which outputs assembly or machine-code (essentially equivalent). These days, compilers for various high-level languages are often front-ends to gcc or LLVM, to take advantage of the optimization and code-generation capabilities of those tools.

So to make software run on a given platform, you need a C compiler that can make binaries for that platform. This lets you build an interpreter, or directly build binaries for the target platform. C, by an accident of history, is the primary language for highly-portable software development.

Some languages have a self-hosting compiler. e.g. the Free Pascal compiler is implemented in Free Pascal, and thus need to ported separately. Fortran has an f2c "compiler" which translates fortran to C, to be compiled by a C compiler. (gfortran is part of the Gnu Compiler Collection (gcc), though, so f2c is not widely useful.)

Note that different OSes on the same hardware often have different ABIs (Application Binary Interface). A Windows binary runs on the same hardware as an x86-64 Linux binary, but makes different system calls. An x86-64 FreeBSD binary makes very similar system calls, and only requires a very lightweight translation layer to run on a Linux kernel.

Some interpreters (Oracle / OpenJDK, python, and some others) have optimizations for some specific platforms. e.g., when running on an x86 or x86-64 system, a good JVM will Just-In-Time compile the java bytecode to native machine code as it's running. On platforms where it doesn't have a JIT engine, it falls back to normal interpreting. This allows much higher performance than a traditional interpreter on platforms where optimization work has been done, but still keeps everything portable.

A good port to a new platform requires porting code-generation engines to the new target. Also, some C software will need its #ifdefs tweaked to pick the right branch for the new target, or even have some new code written if it didn't previously support all combinations of endian and type sizes.

Let's take a Linux distribution like Debian as an example of a huge collection of software written in many different languages as an example.

First you'd build gcc as a cross-compiler (run on your normal system, but generate binaries for the target system). Then you'd write Linux drivers for any different hardware in the new platform, and anything you needed for the bootloader to load a Linux kernel.

Once you've built enough binaries to boot Linux on the new hardware and run gcc, the new port is self-hosting and bootstrapping a full environment with compilers and interpreters for all high-level languages can begin in earnest.

I'm omitting a lot of details because there's a 30k character limit on answers, and I don't feel like hitting it. There's some discussion in comments on Guffa's answer that paints a much less rosy picture than this ideal-world picture, where all the language interpreters in question have a platform-independent portability fallback.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
0

I believe that the issue of "All hardware" is solved by issuing specific binaries for each hardware platform. You have a separate binaries for Mac and PC, for example.

Atul Kumar
  • 421
  • 3
  • 12