On 23-02-2012 07:51, Walter Bright wrote:
On 2/22/2012 7:51 PM, bearophile wrote:
Andrei says that some new languages suffer because they have a poor
implementation, because creating the base for a language is a lot of
work.
Today this is issue is much less of a problem, new languages are
implemented
on the JavaVM,
Using the JVM forces your program into Java semantics. For example,
there are no structs in the JVM bytecode. No pointers, either. Nor
unsigned types. Your new language is fairly boxed in to being a rehash
of Java semantics.
I still cannot fathom how the Scala guys thought using the JVM was a
good idea.
DotNetVM.
Cristi's D compiler on .NET had large problems because array slicing was
not expressible in the .NET intermediate code. It's not nearly as bad as
the JVM in that regard, but it's still limited.
I assume the problem here was the .ptr property? I can't think of
anything else about array slices that would be problematic in CIL.
> System languages are implemented with LLVM.
That works if your language is expressible as C, because LLVM is a C/C++
back end. If your language has different semantics (like how Go does
stacks), using LLVM can be a large problem.
I don't think that's true. D, Rust, C# (CIL in general), Cray,
ActionScript, Python, Java, Lua, Haskell, and many others have been
compiled with LLVM successfully.
LLVM is very much engineered for C and C++, but it has many other
features that those languages don't make use of at all (see for example
the precise GC support; and this is not even something Apple uses, as
their Obj-C GC is conservative). There is also the language-specific
support for OCaml's precise stack maps. Also, LLVM has segmented stacks
on x86 these days. That said, LLVM is definitely not as easy to use for
managed languages as it is for systems/native languages.
So, while the design of LLVM certainly is driven by Clang primarily,
it's not as if they don't welcome non-C family features.
Note that early C++ compilers suffered badly when they were forced into
using C back ends, because C++ wanted new features (like COMDATs) which
are not expressible in C and so not supported by C back ends. Ditto for
any language feature that needs something in the back end that C/C++
doesn't need.
Regarding the comparison between dynamic languages like Python or Ruby
and D:
what Andrei has said is not fully fair. A simple common scripting
task: read
the lines of a text file and put them in a hash. This is probably
faster in
Python compared to D. I am willing to write a benchmark too, if asked.
That would be comparing library code, not language code. Much of
Python's implementation is in C, not Python.
Regarding what Walter has said, that most of the code of D
applications will
be @safe: if safe code gets (or has to get) so common as he says, then it
will be good for the D compiler to learn some tricks to avoid
(optimize away)
array bound tests in some cases.
I looked into this years ago. Very little of array bounds checking can
be optimized away. I've been working on optimizers for 25 years now,
including a native code generating Java compiler, and I do know a few
things about how to do arrays.
In Mono, we found that ABC removal was actually beneficial in some code;
consider for example allocating small static arrays locally and indexing
them with constants (or very simple expressions).
Clang has some pretty good ideas, like the spell checker on undefined
identifiers. But others talked about in the spiel at GoingNative have
been in compilers for 30 years.
--
- Alex
