View mode: basic / threaded / horizontal-split · Log in · Help
September 07, 2008
Re: D parser in tango or phobos
Sascha Katznerz:
> After that we could also finally get rid of the C runtime library on 
> this way and reduce the overall size of the compiled applications. These 
> are two further important points - at least in my opinion.

How much big is the C runtime compared to the D runtime (GC, etc)?

Bye,
bearophile
September 07, 2008
Re: D parser in tango or phobos
bearophile wrote:
> Sascha Katznerz:
>> After that we could also finally get rid of the C runtime library on 
>> this way and reduce the overall size of the compiled applications. These 
>> are two further important points - at least in my opinion.
> 
> How much big is the C runtime compared to the D runtime (GC, etc)?

It's small, of course, but it's there, hanging around actually 
unnecessarily since all functionality can be implemented in D, too 
(syscalls, anyone? - there's even a project already doing this to avoid 
having to use the C runtime).

Kind regards,
Alex
September 08, 2008
Re: D parser in tango or phobos
2008/9/6 Bruce Adams <tortoise_74@yeah.who.co.uk>:

> Python has a python parser written in python. The main interpreter is
> written in C for portability.
> That is a good reason and the same reason applies for D. Why in this day and
> age C++ isn't considered
> portable by most such project is beyond me.
> I particularly like gcc's approach of bootstraping itself to full
> functionality. Its a shame the insides
> are so gnarly.

FYI, one of the GCC maintainers (Ian Lance Taylor) recently created a
branch of GCC that begins to introduce template usage in the GCC
source itself.

http://www.airs.com/ian/cxx-slides.pdf


David

>
> Regards,
>
> Bruce.
>
>
September 08, 2008
Re: D parser in tango or phobos
On Mon, 08 Sep 2008 04:38:34 +0100, David Wilson <dw@botanicus.net> wrote:

> 2008/9/6 Bruce Adams <tortoise_74@yeah.who.co.uk>:
>
>> Python has a python parser written in python. The main interpreter is
>> written in C for portability.
>> That is a good reason and the same reason applies for D. Why in this  
>> day and
>> age C++ isn't considered
>> portable by most such project is beyond me.
>> I particularly like gcc's approach of bootstraping itself to full
>> functionality. Its a shame the insides
>> are so gnarly.
>
> FYI, one of the GCC maintainers (Ian Lance Taylor) recently created a
> branch of GCC that begins to introduce template usage in the GCC
> source itself.
>
> http://www.airs.com/ian/cxx-slides.pdf
>
>
> David
>
Its been suggested before. I even wanted to do it myself but I never had  
sufficient
time or inclination. I, probably like many others, went for a roll your  
own approach instead
before being distracted. Someone at google might actually have the  
resources to do it.
But come on its 2008. If it was going to happen it should have been years  
ago.
Still relating to this article are a few more links:

http://www.airs.com/blog/archives/187
http://gcc.gnu.org/ml/fortran/2008-06/msg00218.html
http://scaryreasoner.wordpress.com/2008/08/21/so-theyre-going-to-rewrite-gcc-in-c-eh/
http://lwn.net/Articles/286539/

Notice how quickly the language war started.
Now the really interesting question is what progress has been made since  
June 18th?

Anyone have time to check the source tree for bookins?
September 08, 2008
Re: D parser in tango or phobos
On Mon, Sep 8, 2008 at 4:47 PM, Bruce Adams <tortoise_74@yeah.who.co.uk> wrote:
> On Mon, 08 Sep 2008 04:38:34 +0100, David Wilson <dw@botanicus.net> wrote:
>
>> 2008/9/6 Bruce Adams <tortoise_74@yeah.who.co.uk>:
>>
>>> Python has a python parser written in python. The main interpreter is
>>> written in C for portability.
>>> That is a good reason and the same reason applies for D. Why in this day
>>> and
>>> age C++ isn't considered
>>> portable by most such project is beyond me.
>>> I particularly like gcc's approach of bootstraping itself to full
>>> functionality. Its a shame the insides
>>> are so gnarly.
>>
>> FYI, one of the GCC maintainers (Ian Lance Taylor) recently created a
>> branch of GCC that begins to introduce template usage in the GCC
>> source itself.
>>
>> http://www.airs.com/ian/cxx-slides.pdf
>>
>>
>> David
>>
> Its been suggested before. I even wanted to do it myself but I never had
> sufficient
> time or inclination. I, probably like many others, went for a roll your own
> approach instead
> before being distracted. Someone at google might actually have the resources
> to do it.

The funny thing to me is that the difference in code shown in that
presentation doesn't really strike me as much of an improvement.   If
that's the best one can come up with as a justification for moving to
C++, then perhaps it's not really worth the effort.

--bb
September 10, 2008
Re: D parser in tango or phobos
Fawzi Mohamed wrote:
> I think that having a compiler of a language written in itself is 
> certainly nice from the intellectual point of view, but not immediately 
> useful in any sense, and frankly unimportant for most people, even if it 
> gives some real benefits to the language development.

Actually, I was mulling over the idea this afternoon, and I think there 
actually could be some major advantages to having the compiler 
implemented in D.

Depending on the architecture, of course, it might be much easier to 
load the compiler as a library. Then you could do all sorts of neat 
things like compiling and loading code on the fly.

   char[] sourcecode = getSourcecodeFromSomewhere();
   ASTCodeModule myModule = parser.parse(sourcecode);

At this point, with the compiler exposing a well-defined API for all of 
its internal representations, you could add your own hooks to operate on 
AST nodes between those phases.

   foreach (ClassDeclaration clazz; myModule.classes) {
      FunctionDeclaration[] methods = clazz.publicFunctions;
      foreach (auto method; methods) {
         decorateMethodWithTraceLogging(method);
      }
   }

And, if the linker & loader were also written in D, you could take those 
runtime-parsed and dynamically-modified pieces of code, immediately 
lining and loading them right into the application.

   SharedLib library = compiler.toLib(myModule);

   // Maybe write the library to a file
   library.emit(`C:\path\to\my-library.lib`);

   // ...Or execute the code directly
   void delegate() entry = library.entryPoint;
   entry.execute();

The .NET framework has some of this kind of functionality (in 
Reflection.Emit), allowing programmers to build executable code, 
opcode-by-opcode, at runtime.

The resultant code is subject to the same JIT compilation as any other 
.NET code.

A good example of its usage is in the Regex implementation, in the .NET 
standard library. It builds a custom function, with raw GOTO opcodes and 
everything, based on the regex string passed into the constructor at 
runtime. Consequently, the .NET regex engine is very very efficient.

The same kind of thing exists in the Tango regex engine -- you can 
generate and compile D code from a regex -- but only if the regex string 
is known at compile-time.

Furthermore, if the D compiler was written in D, and if it could spawn 
its own subordinate instances of the compiler on the fly, immediately 
loading compiled code into executable memory, think of how that would 
expand the power of CTFE. Any legal function would be callable at 
compile-time just as easily as at runtime.

The opposite would be true too. You'd be able to generate and compile 
templates at runtime, potentially creating whole new Types (which has 
only ever been possible at compile-time). Admittedly, I can't think of 
any actual utility for runtime type-generation, but I'm sure someone 
more clever than me could think of some use for it.

Anyhow, those are the sorts of things that I think would become feasible 
if the D parser, compiler, linker, and loader were all written in D.

Calling the compiler dynamically from user code, or from within the 
compiler itself, could be hugely powerful.

(NOTE: I'm not actually *advocating* any of this. Just musing. There are 
plenty of reasons *not* to write the compiler in D, such as already 
having done ten years of work (more on the backend) to refine the 
existing compiler.)

--benj
September 10, 2008
Re: D parser in tango or phobos
Benji Smith:
> Depending on the architecture, of course, it might be much easier to 
> load the compiler as a library. Then you could do all sorts of neat 
> things like compiling and loading code on the fly.

This is very nice.


> A good example of its usage is in the Regex implementation, in the .NET 
> standard library. It builds a custom function, with raw GOTO opcodes and 
> everything, based on the regex string passed into the constructor at 
> runtime. Consequently, the .NET regex engine is very very efficient.

I don't know how mono Regex are done, but they are quite slow compared to most of the other ones:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=regexdna&lang=all


> (NOTE: I'm not actually *advocating* any of this. Just musing. There are 
> plenty of reasons *not* to write the compiler in D, such as already 
> having done ten years of work (more on the backend) to refine the 
> existing compiler.)

I think your ideas don't touch the backend, so it can be the normal LLVM. A D compiler with a D front-end and a LLVM back-end sounds like a nice idea to me.

And the authors of the hopefully-to-be-compiler 'dil' probably think those ideas aren't that bad :-)

Bye,
bearophile
September 11, 2008
Re: D parser in tango or phobos
bearophile wrote:
> Benji Smith:
>> A good example of its usage is in the Regex implementation, in the .NET 
>> standard library. It builds a custom function, with raw GOTO opcodes and 
>> everything, based on the regex string passed into the constructor at 
>> runtime. Consequently, the .NET regex engine is very very efficient.
> 
> I don't know how mono Regex are done, but they are quite slow compared to most of the other ones:
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=regexdna&lang=all

Well I'll be damned. You're right.

I just wrote a few tests, performing identical regex operations in both 
Java and C#, to compare their running times.

In every test, the C# regex was always between 3 and 7 times slower.

Weird. I wonder why.

--benji
September 11, 2008
Re: D parser in tango or phobos
Benji Smith:

> I just wrote a few tests, performing identical regex operations in both 
> Java and C#, to compare their running times.
> In every test, the C# regex was always between 3 and 7 times slower.

If you have a TCL interpreter close to you, I suggest you to try your benchmarks again, you will see other curious results :-) (If you don't have TCL, or you don't want to learn how to use it, you can also try Python/Perl REs, but they are sometimes less efficient than TCL ones).


> Weird. I wonder why.

I don't know. There are several ways to speed up a RE engine, so maybe Java regex is more refined.

Bye,
bearophile
September 19, 2008
Re: D parser in tango or phobos
bearophile wrote:
> Bruce Adams:
>> One of the first questions some people ask when
>> told about a new language is "what is it written in?"
>> If its not written in itself they ask why. If the answer is not compelling  
>> they may walk away.
> 
> Yet, probably 98% of programmers don't care of that. Like most programmers of C#, Java, Python, Perl, Lua, Ruby, Tcl, etc. I'd like to have a D compiler written in D, but there are more urgent/important things to do, I presume.
> 
> 

Yeah, but none of those languages are languages targeted as substitutes 
of C++. D is. And yet the compiler software is not made in D, nor does 
the language designer use it (extensively at least).
So, that's something that could be improved, and not just for publicity 
reasons (having Walter program more in D would be a bit beneficial I 
think, although I wouldn't expect any major enlightenment out of it).

But I do agree that there are other more urgent/important things to work 
on first.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home