3
$\begingroup$

Is there any hardware device inside computer that helps to convert high level language into machine, like compiler and assembler ?

$\endgroup$
  • $\begingroup$ Are you asking whether the processor in the computer is used to run the compiler and the assembler? yes. $\endgroup$ – Wandering Logic Oct 16 '14 at 0:10
  • 1
    $\begingroup$ In a sense, the CPU helps by allowing the compiler and assembler to run. That is, anything software's doing is ultimately done by hardware. Of course, I think your real question is whether there's special-purpose hardware, to which I believe the answer is no. $\endgroup$ – Patrick87 Oct 16 '14 at 15:18
  • $\begingroup$ Would the row of switches / buttons on the Altair (1000?) qualify? $\endgroup$ – Kelly S. French May 15 at 20:36
7
$\begingroup$

No, and yes.

The answer is "no", in the sense that the vast majority of computers have no hardware that does what you typically expect a compiler to do; compilers are written in software. Obviously this ultimately runs on hardware, but we're talking general-purpose hardware.

However, the answer is "yes", in the sense that the machine code that is actually executed often isn't the same as the machine code that a programmer sees (i.e. the instruction set architecture, or ISA for short). Almost all modern CPUs do some degree of dynamic translation of the "machine code" into a form that is more suited for out-of-order execution.

Intel/AMD-type CPUs, for example, translate machine code into RISC micro-operations (called "uops"). It is these instructions which are scheduled and executed.

ARM has something similar. Its ISA is much closer to the format that's executed, but ARM also features Thumb instructions, which are dynamically translated into "core" instructions. The short-lived Jazelle DBX/ThumbEE did a similar thing with direct execution of JVM bytecode.

Almost all modern high-performance CPUs do this to varying degrees. Indeed, there is a fuzzy line between "dynamic translation" and "instruction decoding".

$\endgroup$
1
$\begingroup$

To complement the very good answer by Pseudonym (this was initially intended as a comment, but became long).

As Pseudonym said, all CPUs can be considered has having some form of translation process of code into more elementary steps, of for more elementary cicuit, and there is a fuzzy distinction between "dynamic translation" and "instruction decoding".

But if you go one level up, you have byte-code interpreters. Byte code interpreters translate byte-code (i.e. source code at this level) into machine instructions. The first byte code interpreters were written as software programs. Then people started making specilized computers which looked like their machine code was the byte-code. They actually had byte-code interpreters inside, implemented in microcode residing on high-speed memory. Now again, the line is fuzzy: is an unchanging program in microcode on high speed memory to be considered hardware or or precompiled software. But then, in what sense would it be different from other programmable logic device found in various hardware pieces, and in what sense would these be different from hardware assembled from logical gates with a soldering iron. Actually microcode is often stored in a ROM (read-only memory) or PLA (programmable logic array) structure, or a combination of both.

The concept of bytecode dates back to the 1960s, and it was much developed for Pascal implementations in the 1970s as p-code (often understood at the time as Pascal-code, though meaning now portable code) leading to what is probably the first byte-code machine: the Pascal MicroEngine in 1979. Its p-code was, effectively, its native machine language.

Around the same time, the Lisp machine was developed, using microcode to implement an instruction set specialized for Lisp.

To my knowledge, this is about as high as hardware will go in the code ecology, but it does make some room for various translations: what is object code for one level is source code for the level below. From a conceptual point of view, there is no difference between hardware and software as to what they can do. It is mostly an issue of flexibility, speed, reliability and cost-effectiveness. And you prefer to have highly complex structures in software so as to be able to debug them and correct them: hardware bugs can be very expensive to deal with. These parameters also fix the level of programmability from very hard circuitry, to programmable logic, to microcode and read-only memory to standard dynamically programmable memory that may contain the code for a compiler.

These remarks about hierarchical, multi-level translation structures also apply to some extent at the program design level, when the translation from general specification to architecture, to algorithms, to source code is done by humans. The same is or can be true for other concepts such as memory management, caching, parallel processing, communications.

However, this answer has been cheating a bit in the sense that it talks only of interpretation, not compilation. Interpretation is pretty much an on the fly translation process, but often (not always: it can be memoized) executes the resulting code immediately without memorizing it as a compiler would. Then, the question is only about conversion, not memorization or compilers. Furthermore, interpreters are usually also considered as program translators.

$\endgroup$
  • $\begingroup$ This lecture slide set mentions (in the context of "semantic gap") under "Stranger than fiction": "People once thought computers would execute language directly" and "Fortunately, never materialized (but keeps coming back around)". This abstract mentions "direct execution" high-level language computer architecture. $\endgroup$ – Paul A. Clayton Oct 16 '14 at 12:50
  • $\begingroup$ @PaulA.Clayton I have no access to this paper, and am not sure how to interpret the abstract. Also ACM SIG newsletters are not peer-reviewed publications. The slides look interesting, but I do not believe they contradict what I said. It is probably the case though that specialized harware has been a recurring dream that never really materialized durably, probably because porting software is expensive and hardware evolves fast. Not a specialist, but I suspect that C is the hardware lingua franca. But it is immaterial from users point of view. Whatever works. What do you think? $\endgroup$ – babou Oct 16 '14 at 13:09
  • $\begingroup$ I was just bringing up that direct (hardware) execution of high level languages was proposed but never really had any practical application. Ditzel & Patterson's "Retrospective on High-Level Language Computer Architecture" (1980) presents a RISC view of HLLCA. Colwell et al.'s "Performance Effects of Architectural Complexity in the Intel 432" presents some HLLCA-related issues from that particular implementation. $\endgroup$ – Paul A. Clayton Oct 16 '14 at 13:47
  • $\begingroup$ @PaulA.Clay I agree with you. It even started with the Burroughs machines architecture in 1961 that were intended for Algol-like languages. I do not think any was intended to execute source code directly, though (possibly the Lisp machine, but I never used it and have some doubts). I was only answering a question. I might have stressed that it mostly failed, for good reasons (time cost of specialization vs fast evolution). I preferred to give criteria, and the answer is long already. The only apparent success are the graphics CPU, more a computation model than a HLLCA. Do I say anything wrong? $\endgroup$ – babou Oct 16 '14 at 14:06
  • $\begingroup$ No, you did not say anything wrong, I was merely pointing to further information. (I am fairly certain that none of the LISP machines directly executed source code.) $\endgroup$ – Paul A. Clayton Oct 16 '14 at 14:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.