Re: Survey of intermediate program representations?

Hans-Peter Diettrich wrote:
...
> > The beauty of C is that, in spite of its low-level abilities,
> > the code is highly portable....
>
> Due to its low level nature, C code is only as portable as ported
> (compatible) runtime libraries exist. This seems not to be the case
> nowadays, at least the C gurus insist in using automake and other
> tools for preparing and distributing "portable" C code. This way the
> portability is restricted to the platforms known to the developer, so
> that he can implement and conditionally select all required
> workarounds. Most such code just fails to *compile* for Windows,
> because this platform is widely disregarded by GNU people, to put it
> mildly ;-)
>
> I for my part don't understand this problem, because it IMO would be
> not a big deal to implement one common C library interface, with all
> the workarounds residing in the target specific libraries.
...


> [IBM had a successful pair of PL/I compilers in the late 1960s, the
> intrpreted checkout compiler and the native code F compiler. They
> seemed to be reasonably successful.


I don't understand your point. For specific languages such variations
of code production are feasable, of course, even for extensible
languages.


> Re a common C library, that's what POSIX is. What's missing?
> Windowing stuff?


Missing are portable header files, so that ./configure must be run to
adopt the source files to a specific target. Any errors in this phase
will effectively stop the build process. E.g. I got such ridiculous
error messages like "compiler cannot create executables" when
attempting to configure GNU packages on Windows. As outlined before,
this is a packaging problem, not a problem of C itself. It should be
noted that the FSF recommends the use of autoconfig etc., so that
currently it's hard to find otherwise packaged free software.


> Re JAU, common intermediate codes can work OK in limited domains,
> e.g. Fortran-like languages running on Windows, I can believe it'd
> work. -John]


I agree that there exist compiler families, based on the same
back-end, that allow to mix object files from several
languages. Nonetheless I suspect that certain restrictions will apply
to mixed-language applications.


Let me comment on "-like" languages. Even if it looks not so hard to
construct an IL for multiple languages, the meanings will just start
to disagree about the exact behaviour of the opcodes. Such subtle
differences will reduce the number of languages, that are *fully*
compatible with a concrete VM (opcode interpreter). Next comes a
common runtime system - just the I/O part is hard to unify across
languages. Next comes a shareable string format, if ever supported by
a language. Fortran, in detail, has a strange definition for the
handling of constant values, hardly compatible with other
languages. And array indexing etc. pp...


That's why the .NET approach starts with a more or less specified CIL,
CTS and CLR, and the applicable languages *look* "like" some familiar
language, but they differ from their legacy counterparts in many
subtle details.


DoDi

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