www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Some new LLVM slides/videos

reply bearophile <bearophileHUGS lycos.com> writes:

Nov 19 2010
parent reply Emil Madsen <sovende gmail.com> writes:
So these sliders are empty - I take it?

On 19 November 2010 22:29, bearophile <bearophileHUGS lycos.com> wrote:



-- 
// Yours sincerely
// Emil 'Skeen' Madsen
Nov 19 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Emil Madsen:

 So these sliders are empty - I take it?
I have just lost them a moment behind the table, sorry. Through Reddit I have found a group of new slides/videos on LLVM ("2010 LLVM Developers' Meeting"), some of them are interesting: http://llvm.org/devmtg/2010-11/ Some comments about the PDF slides: "Implementing Include-What-You-Use using clang": I'd like still D module system to be more tidy and import only the "foo" name when you write: import foo; So you need to use foo.bar and foo.baz. And to import "bar" and "baz" names and not the "foo" name when you write: import foo: bar, baz; And to import all the names from "foo" (but not the "foo" name itself) using some syntax with * or "all" or something similar. This makes code more readable and tidy, and makes the work of D analysis tools simpler. "Polly - Polyhedral optimizations in LLVM" and "Symbolic Crosschecking of Floating-Point and SIMD Code": they remind me something said by Walter too recently. It's stupid to use tons of analysis to extract high-level semantics from low-level C-style code and then compile it again in asm. It's much better to give programmers a (little or big) language that allows to directly express the high level semantics of heavy numerical processing code (that often are some nested loops on arrays and sometimes on trees/graphs). In D this may be done using something like this: mixin(Looper!q{ // high-level numerical processing code here }); That's not a tidy thing, and it asks programmers to learn a special little language, but it seems better than the alternative (unless you are able to use languages like Chapel that allow you to express that semantics already). To implement that in D you need a compile-time compiler that returns a string that contains asm{...} or even normal D code. To implement this compile-time compiler you may "just" need to improve D CTFE so it uses memory better, so it becomes fast enough. Example: processing.js is a large JavaScript file that essentially parses Java code and runs it in JavaScript: http://processingjs.org/ JavaScript today is much faster than D CTFE, but there is more space for improvements in D CTFE because the CTFE code is statically typed D, that's much simpler than JavaScript to run efficiently even in an interpreter. "Creating cling, an interactive interpreter interface for clang": the D front-end already contains a partial D interpreter. If this interpreter gets moved (or copied) inside a library that may be used from D code at runtime, then implementing a D interactive interpreter becomes simple, and enbedding Lua/Python/etc inside D becomes less necessary. Having a partial interpreter inside the compiler and not being able to use it at runtime is a wasted opportunity. "Hardening LLVM With Random Testing": eventually DMD/D compilers will enjoy similar random testing, but probably it's too much early now, it's easy still to find enough bugs manually. Bye, bearophile
Nov 19 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:
 "Implementing Include-What-You-Use using clang": I'd like still D module
 system to be more tidy and import only the "foo" name when you write: import
 foo; So you need to use foo.bar and foo.baz.
D already does this: static import foo;
 And to import "bar" and "baz"
 names and not the "foo" name when you write: import foo: bar, baz;
D already does this, too.
 And to
 import all the names from "foo" (but not the "foo" name itself) using some
 syntax with * or "all" or something similar. This makes code more readable
 and tidy, and makes the work of D analysis tools simpler.
This has been discussed many times, and has been soundly rejected for numerous reasons. For one thing, it does not make analysis easier, because it is unknown what files will actually get imported.
Nov 19 2010