llvm dev - Sep 2003 - [LLVMdev] languages, semantic trees, LLVM interfaces

Hello LLVM fathers,

1. "languages, semantic trees"

   what do you think ideally, do languages implementations based on
   LLVM need internal semantic tree or they should rather try to use
   LLVM directly in/after syntax parsing?

   For languages like C++ the expected answer is "of course we need
   an internal semantic tree between parsing and LLVM!"
   But I am still wondering what are your strategic plans conserning
   this issue.

2. For other (not C/C++) languages there should be some interface
   solution in order to use LLVM from their parsers (e.g. ocamlyacc).
   So, what about that?

Thank you.

-- 
Best regards,
Valery                          mailto:khamenya at mail dot ru

Valery,

For any language with relatively sophisticated syntax and semantic
rules, you will probably need a higher-level representation like an
Abstract Syntax Tree in order to do type-checking and other kinds of
checking.  For OCAML, for example, the front-end is quite sophisticated
and complex and the LLVM representation would not be suitable for
supporting all the checking and translation.  It would also be difficult
to do these tasks directly within the parser if you parsed directly into
LLVM.  So a higher-level representation is necessary.

After the front-end tasks are done, another interesting issue is what
happens with languages compiled to a well-defined bytecode language
(e.g., JVM or MSIL).  For such cases, our aim is to allow a fast,
simple, runtime translation from bytecode to LLVM, and then to do all
machine-dependent code generation and optimization, including runtime
optimization, on LLVM.  In fact, these "back-end" mechanisms would be
language-independent, i.e., they would be common for different bytecode
languages.  Of course, the JVM or the CLR virtual machines will still be
needed to implement the runtime systems, but they would run on top of
LLVM and use the common back-end mechanisms for code generation.  (In
fact, nearly all of the JVM or CLR system would be machine-independent
this way.)  This is a long-term goal; Alkis Evlogimenos is a new student
in my group and is just starting work on this general direction.

--Vikram
http://www.cs.uiuc.edu/~vadve

> -----Original Message-----
> From: llvmdev-admin at cs.uiuc.edu 
> [mailto:llvmdev-admin at cs.uiuc.edu] On Behalf Of Valery A.Khamenya
> Sent: Saturday, September 06, 2003 7:15 AM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] languages, semantic trees, LLVM interfaces
> 
> 
> Hello LLVM fathers,
> 
> 1. "languages, semantic trees"
> 
>    what do you think ideally, do languages implementations based on
>    LLVM need internal semantic tree or they should rather try to use
>    LLVM directly in/after syntax parsing?
> 
>    For languages like C++ the expected answer is "of course we need
>    an internal semantic tree between parsing and LLVM!"
>    But I am still wondering what are your strategic plans conserning
>    this issue.
> 
> 2. For other (not C/C++) languages there should be some interface
>    solution in order to use LLVM from their parsers (e.g. ocamlyacc).
>    So, what about that?
> 
> Thank you.
> 
> -- 
> Best regards,
> Valery                          mailto:khamenya at mail dot ru
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Hello Vikram,

Saturday, September 6, 2003, 9:10:45 PM, you wrote:

VSA> For any language with relatively sophisticated syntax and semantic
VSA> rules, you will probably need a higher-level representation like an
VSA> Abstract Syntax Tree in order to do type-checking and other kinds of
VSA> checking.

OK, concerning AST -- I see. Thank you.

VSA> For OCAML, for example, the front-end is quite sophisticated
VSA> and complex and the LLVM representation would not be suitable for
VSA> supporting all the checking and translation.

But I have just meant ocamlyacc, i.e. ocaml clone of the yacc.
And here my question was: what kind of interface is expected to use
from within ocml, CommonLisp implementations, Haskel and other nice
language implementations? What is the expected way of interfacing
LLVM for those non-C language implementations? shared libraries with
plain C-interface or what?

Kind regards,
--
Valery A.Khamenya                       mailto:khamenya at mail.ru
Local Time: 22:59