On 22/10/2009 18:06, Denis Koroskin wrote:
On Thu, 22 Oct 2009 19:59:04 +0400, Yigal Chripun <yigal...@gmail.com>
wrote:
Tomas Lindquist Olsen Wrote:
This locks D to the LLVM backend, things like that is never a good idea.
you could say the same thing about .net and Java -
Java locks you to .class files and .net locks you to assemblies.
there are many JVMs from different vendors for different platforms
which are interoperable because of this. IIRC Mono can work with MS
assemblies and also there's the interoperability between different
.net languages.
Also, LLVM bitcode files produced both by LDC and Clang/llvm-gcc are
platform specific. Sure you can process them on any platform, but the
source code they were compiled from was platform specific, and so is
the resulting bitcode. Using LLVM bitcode as a replacement format for
native OMF/COFF/ELF objects, does not give us platform neutrality.
I don't know llvm that well but it seems that for clang/llvm-gcc the
reason for this is because of the source language (c/c++) which is
platform specific. Can you elaborate about this for LDC? where are the
problematic parts and what can be done to make the output
platform-neutral?
I read that platform specific things like sizeof where hardcoded in
the resulting bit-code but now they replaced it with a sizeof
intrinsic so that the resulting bit-code would not depend on this. are
there any other problematic cases like this still remaining?
-Tomas
D source code:
void main()
{
version (Windows) {
writefln("Windows");
} else {
writefln("not Windows");
}
}
Using the same LLVM IR for both platforms would be a mistake in the case
above.
The only solution would be to carry version and such stuff in IR, too,
and resolve at later stages, but this is also problematic.
I think that postponing conditional compilation to a later stage is a
reasonable solution.
