Subject: Pondering Compilation Accelarating Hardware

From: Shlomi Fish <[email-masked]>
Date: Mon, 7 Mar 2005 21:05:15 +0200

Hi all!

I once talked with someone (privately) and he suggested there that in the 
future we may see compilers implemented in hardware. I said it was not very 
realistic because compilers are very complicated and memory hungry, and so 
implementing them in transistors would be very difficult and error prone.

However, it got me thinking: what about compilation-accelarting hardware? I 
mean specialized hardware that can be programmed to implement various 
functions of a compiler in a faster way than it can execute it itself.

Is this realistic? Are there any methods done by compilers (or interpreters) 
that allow hardware acceleration?

Regards,

	Shlomi Fish

---------------------------------------------------------------------
Shlomi Fish      [email-masked]
Homepage:        http://www.shlomifish.org/

Knuth is not God! It took him two days to build the Roman Empire.

---

From: Omer Zak <[email-masked]>
Date: Mon, 07 Mar 2005 21:26:24 +0200

> implementing them in transistors would be very difficult and error prone.

Today's technology is sufficiently advanced that money hungriness for
this kind of application is not an issue anymore.  Chips (integrated
circuits) with order of 10^9 transistors are commercially produced.

The problem is that compilers are complicated - but in the sense that
they have bugs which need to be fixed once they are found.  Their
feature set is also a moving target (new compile-time flags, new
optimization approaches, new machine language instructions in future
generations of the target processor, etc.).

> that allow hardware acceleration?

I suppose that the parts of tokenization (lexical analysis) and parsing
can take advantage of specialized hardware.  The code generation and
optimization part is probably more difficult.

But, what is the point of this?
Compilation of a specific piece of software is not an operation, which
is performed that frequently. (Organizations with code base having 10^9
source code lines are a different story.)

Interpreters are a different story altogether.  But even with
interpreter based languages (like Perl and Python), adequate performance
has been obtained with virtual machines.  Critical operations are
performed anyway by code directly executed by processor, and invoked by
function calls from the interpreted code.

Then what you need (if at all) is hardware optimized for your problem
domain - for your own software - rather than for the
compiler/interpreter which you happen to use.
                                                     --- Omer

-- 
My own blog is at http://www.livejournal.com/users/tddpirate/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html

---

From: Elad Efrat <[email-masked]>
Date: Tue, 08 Mar 2005 19:22:41 +0200

[mail from shlomi fish and omer zak truncated]

i believe you are not too familiar with the code
of a compiler.

unlike encryption, which is math and "unified",
compiling is not something that is done the
same even across two compilers.

"tokenization" is a nice way to put one of many
phases of compilation, unfortunately there are
too many algorithms - as previous threads that
*you* participated on in this list show - of
implementing the same goal.

bottom line - i dont see anyone producing any
sort of "compilation accelerating hardware".

-e.