Re: Translator design decisions

Hans-Peter Diettrich <>
Wed, 23 Jan 2008 13:37:02 +0100

          From comp.compilers

Related articles
Translator design decisions (Mario Suvajac) (2008-01-19)
Re: Translator design decisions (Hans-Peter Diettrich) (2008-01-20)
Re: Translator design decisions (Chris F Clark) (2008-01-21)
Re: Translator design decisions (Tony Finch) (2008-01-22)
Re: Translator design decisions (Ken Rose) (2008-01-22)
Re: Translator design decisions (Chris F Clark) (2008-01-23)
Re: Translator design decisions (=?ISO-8859-1?Q?Pertti_Kellom=E4ki?=) (2008-01-23)
Re: Translator design decisions (Hans-Peter Diettrich) (2008-01-23)
Re: Translator design decisions (2008-01-26)
| List of all articles for this month |

From: Hans-Peter Diettrich <>
Newsgroups: comp.compilers
Date: Wed, 23 Jan 2008 13:37:02 +0100
Organization: Compilers Central
References: 08-01-050 08-01-054 08-01-062 08-01-063
Keywords: UNCOL
Posted-Date: 23 Jan 2008 12:24:34 EST

Ken Rose wrote:

> I've long wondered why UNCOL is such a problem, when just about any
> assembly language you could name is capable of supporting any
> programming language, limited only, it seems, by address space and the
> size of the runtime system.

This direction is easy, because assembly language is insensitive to
data structures and runtime libraries. Data structures are decomposed
down to byte level by the compiler, and the runtime libraries, which
often are written in assembly language, simply become part of every
program. As long as a language supports pointers, foreign data
structures can be handled in that language like they are handled in
assembly language. But the runtime libraries, in detail for strings,
filehandling and I/O, differ widely across languages. You may have
recognized already that file handling is very platform dependent, so
that HLL code already must contain different code for different
platforms. Almost the same for the low level RTL functions, which are
not easily portable across HLL languages.

When you try to convert a Lisp or Forth program into e.g. C, you'll
have to implement a whole virtual machine for that language in C,
because the subroutine calls and argument passing are implemented so
differently in these languages. The same can happen with other
functionality, that cannot be expressed in a specific high level
language, other than the original language.

Or simply take strings, which can be either counted or zero
terminated. When C code appends a '\0' to an string, doing the same
in Pascal will have an different effect. This means that some
statements cannot be translated literally into another language, but
instead must be analyzed and translated into a functionally equivalent
construct. Or an UNCOL must support multiple versions of strings and
stringhandling, and for many more data types, when a semantical
analysis of the input code shall be avoided. Here C code turns out to
be a special nasty thing to convert, because much work is done in a
very low-level way of coding, where other languages provide specific
functions for the same tasks, with immediately recognizeable


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.