frontend support for MLIR? - clang

Is there any frontend that will generate MLIR (not LLVM) code currently? I am interested in parsing C/C++ or Java code in particular. Does clang support this now? This page doesn't list any at the moment.

As of Oct 2020, compiling C++ into CIL (C intermediate language) mlir dialect is not public yet. But they will be making it available "soon".
This was hinted on this year on LLVM developers meeting (http://llvm.org/devmtg/2020-09/program/) on the following talk:
CIL : Common MLIR Dialect for C/C++ and Fortran - P. NR; V. M; Ranjith; Srihari
In case people are not aware, as an alternative if you just want your C/C++ code in the mlir environment is to compile your program into LLVM with clang -S -fno-discard-value-names -emit-llvm and then later use mlir-translate --import-llvm to transform your .ll file into a .mlir file. But you do lose some higher level information and the opportunity for higher level optimizations.

Related

Are there macros which can be used to test Erlang version in driver C code?

Erlang R15B added ErlDrvSSizeT typedef, and R16B added erl_drv_output_term function and deprecated the old equivalent. Is there a way to test for these differences with preprocessor macros in order to support older Erlang versions with the same code?
You can use the ERL_DRV_EXTENDED_MAJOR_VERSION and ERL_DRV_EXTENDED_MINOR_VERSION macro values, supplied in erl_driver.h, to make decisions about features. Whenever the driver API changes, these values are suitably incremented. These increments are always explained in the Erlang/OTP release notes.
For example, Erlang/OTP R15B changed some API function parameter types from int to a new type ErlDrvSizeT to better cope with 64-bit platforms. You can test for this and compensate for it for older pre-R15B versions using the code below:
#if ERL_DRV_EXTENDED_MAJOR_VERSION < 2
typedef int ErlDrvSizeT;
#endif
This typedef allows you to use the type ErlDrvSizeT even for older driver versions.
As of this writing, Erlang/OTP version 17.3 and version 6.2 of the Erlang runtime system (erts) are current. For erts 6.2, ERL_DRV_EXTENDED_MAJOR_VERSION and ERL_DRV_EXTENDED_MINOR_VERSION have the values 3 and 1, respectively. The changes in this Erlang/OTP commit created these version values.

What is the (# ... #) syntax seen in F# standard library implementation?

Reading sources of Array2D module, I've stumbled upon this interesting construct in implementation of many core functions, for example:
[<CompiledName("Get")>]
let get (array: 'T[,]) (n:int) (m:int) = (# "ldelem.multi 2 !0" type ('T) array n m : 'T #)
I can only assume that this is the syntax to inline CIL and is used here obviously to gain performance benefits. However, when I've tried to use this syntax in my program, I get an error:
warning FS0042: This construct is deprecated: it is only for use in the F# library
What exactly is this? Is there any detailed documentation?
I think that this has 2 purposes:
These functions compile down to exactly 1 CIL instruction which has to be encoded somewhere, so encoding at the source seems best.
It allows for some extra trickery with defining polymorphic Add functions in a high performance way which is hard with the F# type system.
You can actually use this but you have to specify the --compiling-fslib (undocumented) and --standalone flags in your code.
I've found some details in usenet archives: http://osdir.com/ml/lang.fsharp.general/2008-01/msg00009.html
Embedded IL in F# codes. Is this feature officially supported
Not really. The 99.9% purpose of this feature is for operations defined
in FSharp.Core.dll (called fslib.dll in 1.9.2.9 and before).
Historically it has been useful to allow end-users to embed IL in order
to access .NET IL functionality not accessible by F# library or
language constructs using their own embedded IL. The need for this is
becoming much more rare, indeed almost non-existent, now that the F#
library has matured a bit more. We expect this to continue to be the
case. It's even possible that we will make this a library-only feature
in the "product" version of F#, though we have not yet made a final
decision in this regard.
This was a message from Don Syme, dated January of 2008.

Automatically create Delphi/Freepascal interface unit from C header file

Is it possible to automatically generate interface units from C header files? In particular, I want to wrap the HDF5 library, and it would be great if I could avoid writing the interface unit manually.
The free pascal includes the H2PAS tool.
h2pas attempts to convert a C header file to a pascal unit. it can
handle most C constructs that one finds in a C header file, and
attempts to translate them to their pascal counterparts.
Bob Swart (Dr Bob) has a utility which will convert a lot of header files (although there's usually some manual work involved as well) called HeaderConvert. I've never compared it to the tool #RRUZ links, but it's another option.
Project JEDI has one as well; I've never tested it. You can find it here.
In general fully automated translating of C headers to something else (that isn't an effective superset of the needed C functionality) is hard to impossible.
This because due to macros one can't see how to translate them. Macros often only get their meaning from context. Example
#define uglymacro 1,2,3,4
but also (and this one is more common):
SCARYAPIMACRO void func(int c);
SCARYAPIMACRO is then often a macro that tests OS defines to select the right calling convention for the right OS/architecture.
Still, that doesn't mean that the tools are not real timesavers. But the result is more semiautomatic, I've the most and best experience with h2pas.
I've translated a lot of Windows headers (including FPC's commctrl which has a sendmessage macro every few lines).
What I usually do is craft a small pascal program that scans the source linebased and uses heuristics to split it into parts that are mostly homogeneous (all structs or constants,macros, procedure declaration etc). Then I look at the source and often do some global substitutes.
Only then I run it through the translator, the process is often iterative (refine separation, do global substitutions, try to translate, if it fails, try again etc).
The process unfortunately does require a good grasp of C, pragma stuff included.
You can download HDF5 API header Delphi translations, Delphi XE2 HDF5 table test program with source code and somewhat modified hdf5dll from my page:
http://www.astro.ff.vu.lt/index.php?option=com_content&task=view&id=46&Itemid=63

Go uses Go to parse itself?

I am starting a class project that regards adding some functionality to Go.
However, I am thoroughly confused on the structure of Go. I was under the impression that Go used flex and bison but I can't find anything familiar in the Go source code.
On the other hand, the directory go/src/pkg/go has folders with familiar names (ast, token, parser, etc.) but all they contain are .go files. I'm confused!
My request is, of anyone familiar with Go, can you give me an overview of how Go is lexed, parsed, etc. and where to find the files to edit the grammar and whatnot?
The directory structure:
src/cmd/5* ARM
src/cmd/6* amd64 (x86-64)
src/cmd/8* i386 (x86-32)
src/cmd/cc C compiler (common part)
src/cmd/gc Go compiler (common part)
src/cmd/ld Linker (common part)
src/cmd/6c C compiler (amd64-specific part)
src/cmd/6g Go compiler (amd64-specific part)
src/cmd/6l Linker (amd64-specific part)
Lexer is written in pure C (no flex). Grammar is written in Bison:
src/cmd/gc/lex.c
src/cmd/gc/go.y
Many directories under src/cmd contain a doc.go file with short description of the directory's contents.
If you are planning to modify the grammar, it should be noted that the Bison grammar sometimes does not distinguish between expressions and types.
lex.c
go.y
The Go compilers are written in c, which is why you need flex and bison. The Go package for parsing is not used. If you wanted to write a self hosting compiler in Go, you could use the Go parsing package.

List of Lua derived VMs and Languages

Is there a compendium of virtual machines and languages derived or inspired by Lua? By derived, I mean usage beyond embedding and extending with modules. I'm wanting to research the Lua technology tree, and am looking for our combined knowledge of what already exists.
Current List:
Bright - A C-like Lua Derivative http://bluedino.net/luapix/Bright.pdf
Agena - An Algol68/SQL like Lua Derivative http://agena.sourceforge.net/
LuaJIT - A (very impressive) JIT for Lua http://luajit.org
MetaLua - An ML-style language extension http://metalua.luaforge.net/
There's a good list of Lua implementations on the lua users wiki, including compilers/interpreters, languages implemented in lua and languages based on lua.
Luaforge might also be a good resource.
Squirrel -- high level imperative/OO programming language
GSL Shell -- interactive CLI with easy access to the GNU Scientific Library (GSL)
Objective Lua -- almost pure superset of Lua that welds the Objective C object orientation system and syntax on top of the classic Lua language
Jill -- Java Implementation of Lua Language
Dao -- OO programming language with soft (or optional) typing, BNF-like macro system
MoonScript -- CoffeeScript inspired language that compiles into lua
It's just an implementation, not a list, but there's Lua-ML. There's an application paper and a technology paper.
The code is a little out of date; apparently the nightly build at http://www.cminusminus.org/ is broken.

Resources