www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Official DMD compiler written in D

reply "Tim Krimm" <twkrimm gmail.com> writes:
Now that D 2.0 is fairly stable, are there any plans of writing 
the official DMD compiler with the D 2.0 language vs the present 
language of C++?

DMD 2.0 would have to be feature frozen and then DMD 3.0 could be 
written with the previous DMD 2.0 compiler.

What are your thoughts?
Jan 08 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/08/2013 10:48 AM, Tim Krimm wrote:

 Now that D 2.0 is fairly stable, are there any plans of writing the
 official DMD compiler with the D 2.0 language vs the present language of
 C++?

 DMD 2.0 would have to be feature frozen and then DMD 3.0 could be
 written with the previous DMD 2.0 compiler.

 What are your thoughts?


There is Denis Koroskin's ddmd:

   http://forum.dlang.org/thread/i4obl3$kgk$1 digitalmars.com?page=1

If this page is up to date, ddmd is currently at dmd 2.040's level:

   http://www.dsource.org/projects/ddmd

Ali
Jan 08 2013
parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Tue, Jan 8, 2013 at 8:18 PM, Ali =C3=87ehreli <acehreli yahoo.com> wrote=
:


 On 01/08/2013 10:48 AM, Tim Krimm wrote:


 Now that D 2.0 is fairly stable, are there any plans of writing the
 official DMD compiler with the D 2.0 language vs the present language of
 C++?

 DMD 2.0 would have to be feature frozen and then DMD 3.0 could be
 written with the previous DMD 2.0 compiler.

 What are your thoughts?


 There is Denis Koroskin's ddmd:

   http://forum.dlang.org/thread/**i4obl3$kgk$1 digitalmars.com?**page=3D1=


<http://forum.dlang.org/thread/i4obl3$kgk$1 digitalmars.com?page=3D1>

 If this page is up to date, ddmd is currently at dmd 2.040's level:

   http://www.dsource.org/**projects/ddmd<http://www.dsource.org/projects/=


ddmd>

 Ali


Isn't SDC also in D? (Bernard Helyer and friends)
https://github.com/bhelyer/SDC


Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
past, but did not provide any link to it.


But, to answer the OP question: no, there are no plan to switch to D for
the reference compiler in the near future, as far as I can tell.
Jan 08 2013
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/08/2013 01:06 PM, Philippe Sigaud wrote:

 On Tue, Jan 8, 2013 at 8:18 PM, Ali Çehreli<acehreli yahoo.com>  wrote:



 There is Denis Koroskin's ddmd:





    http://www.dsource.org/**projects/ddmd<http://www.dsource.org/projects/ddmd>





 Isn't SDC also in D? (Bernard Helyer and friends)
 https://github.com/bhelyer/SDC


And Aziz Köksal's dil:

   https://github.com/azizk/dil

Ali
Jan 08 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/08/2013 10:06 PM, Philippe Sigaud wrote:

 ...

 Isn't SDC also in D? (Bernard Helyer and friends)
 https://github.com/bhelyer/SDC


 Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
 past, but did not provide any link to it.


Yes, it is in D. Nothing is released yet. It needs to be polished a 
little so that there are no known embarrassing shortcomings anymore.
(eg. the parser cannot parse extern(...) declarations in alias 
declarations yet, and I need to finish making a minor tweak to how 
template instances are analyzed in order to get circular dependency 
detection to work reliably. Furthermore, examples like the following are 
currently rejected, while I want it to work:

enum x = "enum xx = q{int y = 0;};";

struct S{
     mixin(xx);
     mixin(x);
}

<mixin mxin.d:5>:1:6: error: declaration of 'xx' smells suspiciously fishy
enum xx = q{int y = 0;};
      ^~
mxin.d:4:11: note: this lookup should have succeeded if it was valid
     mixin(xx);
           ^~


It shouldn't be a too large change, as eg. this already works:

struct S{
     enum z = y;
     enum x = "enum xx = q{immutable y = 123;};";
     mixin(xx);
     mixin(x);
     static assert(z == 123);
}

(DMD chokes on both.)

Furthermore, I need to implement exceptions, modules, and some parts of 
compile time reflection + tons of really small features. (Where all 
ambiguities and contradictions are detected according to well-defined 
rules instead of resolved or choked on randomly as DMD likes to do.)

Also, it obviously needs a repl. :-)

CTFE is basically done (as a portable byte code interpreter, but other 
strategies, such as JIT, could be easily plugged). This is a snippet of 
my regression test suite:

auto dynRangePrimes(){
     DynRange!int impl(int start)=>
 
dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
     return impl(2);
}

static assert(array(take(dynRangePrimes(), 20)) == 
[2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);

)

I also need to decide on a licence. I assume that the alpha will be out 
in late spring. (I am busy until early spring.)


 But, to answer the OP question: no, there are no plan to switch to D for
 the reference compiler in the near future, as far as I can tell.
Jan 09 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-09 12:05, Timon Gehr wrote:


 Yes, it is in D. Nothing is released yet. It needs to be polished a
 little so that there are no known embarrassing shortcomings anymore.


I've might have missed this front end. Any links ?

-- 
/Jacob Carlborg
Jan 09 2013
prev sibling next sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Wed, Jan 9, 2013 at 12:05 PM, Timon Gehr <timon.gehr gmx.ch> wrote:

 Yes, it is in D. Nothing is released yet. It needs to be polished a little
 so that there are no known embarrassing shortcomings anymore.


What? That's FOSS, release early, release often!


 (DMD chokes on both.)

 Furthermore, I need to implement exceptions, modules, and some parts of
 compile time reflection + tons of really small features. (Where all
 ambiguities and contradictions are detected according to well-defined rules
 instead of resolved or choked on randomly as DMD likes to do.)


Makes me salivate.



 Also, it obviously needs a repl. :-)


Obviously.

And direct programmatic access to the lexer and the parser. I'm coding
a macro system for D right now, as an over-layer above DMD (like rdmd)
and having to create the AST by myself to transform them according to
the user-defined macros is a pain.


 CTFE is basically done (as a portable byte code interpreter, but other
 strategies, such as JIT, could be easily plugged).


Great!


 This is a snippet of my regression test suite:

 auto dynRangePrimes(){
     DynRange!int impl(int start)=>

 dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
     return impl(2);
 }

 static assert(array(take(dynRangePrimes(), 20)) ==
 [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);


Lazy recursive range, right? As the usual Haskell definition for a
prime generator. Nice!


 I also need to decide on a licence.


Unless you've reason not to, I'd advise using the same as Phobos: Boost.


 I assume that the alpha will be out in late spring. (I am busy until early
spring.)


You can count me in to test it (I gather to prefer to code this as you
see fit, right now). You could also present it at the D conf.


In any cases, congratulations for what seems to be a elegantly done D
implementation.
Jan 09 2013
parent "Timon Gehr" <timon.gehr gmx.ch> writes:
On Wednesday, 9 January 2013 at 12:29:07 UTC, Philippe Sigaud 
wrote:

 On Wed, Jan 9, 2013 at 12:05 PM, Timon Gehr <timon.gehr gmx.ch> 
 wrote:

 Yes, it is in D. Nothing is released yet. It needs to be 
 polished a little
 so that there are no known embarrassing shortcomings anymore.


 What? That's FOSS, release early, release often!


I want to release it at a time when I am ready to cope with 
reactions and bug reports.


 Also, it obviously needs a repl. :-)


 Obviously.


Actually, at this point, the main challenge is getting the 
interactive code editing to work.


 And direct programmatic access to the lexer and the parser. I'm 
 coding
 a macro system for D right now, as an over-layer above DMD 
 (like rdmd)
 and having to create the AST by myself to transform them 
 according to
 the user-defined macros is a pain.


 CTFE is basically done (as a portable byte code interpreter, 
 but other
 strategies, such as JIT, could be easily plugged).


 Great!


 This is a snippet of my regression test suite:

 auto dynRangePrimes(){
     DynRange!int impl(int start)=>

 dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
     return impl(2);
 }

 static assert(array(take(dynRangePrimes(), 20)) ==
 [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);


 Lazy recursive range, right? As the usual Haskell definition 
 for a prime generator. Nice!


It uses the usual range templates + dynRange, which wraps a range 
using delegates in order to hide some static type information and 
allow recursion.


 I also need to decide on a licence.


 Unless you've reason not to, I'd advise using the same as 
 Phobos: Boost.


I'll need to give it some thought, my knowledge about licensing 
is still rather limited.


 I assume that the alpha will be out in late spring. (I am busy 
 until early spring.)


 You can count me in to test it (I gather to prefer to code this 
 as you see fit, right now).


Thanks!


 You could also present it at the D conf.


I'd like to, but I probably cannot make it.


 In any cases, congratulations for what seems to be a elegantly 
 done D implementation.


Thanks! (Well, it makes extensive use of string mixins to 
simulate a coroutine-based system with low overhead.)
Jan 09 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 9 January 2013 at 11:05:56 UTC, Timon Gehr wrote:

 I also need to decide on a licence. I assume that the alpha 
 will be out in late spring. (I am busy until early spring.)


I'm not really a specialist in terms of license, but it'd be nice 
if it is compatible with SDC's.
Jan 09 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-09 13:54, deadalnix wrote:


 I'm not really a specialist in terms of license, but it'd be nice if it
 is compatible with SDC's.


SDC uses the MIT license.

-- 
/Jacob Carlborg
Jan 09 2013
parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Wed, Jan 9, 2013 at 1:58 PM, Jacob Carlborg <doob me.com> wrote:

 On 2013-01-09 13:54, deadalnix wrote:


 I'm not really a specialist in terms of license, but it'd be nice if it
 is compatible with SDC's.



 SDC uses the MIT license.


Well, I'd use (and hack) any D compiler written in D, whatever the
license. Let Timon code it, when the only left is the license, all
will be well and good.
Jan 09 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/9/13 5:10 AM, Philippe Sigaud wrote:

 On Wed, Jan 9, 2013 at 1:58 PM, Jacob Carlborg<doob me.com>  wrote:

 On 2013-01-09 13:54, deadalnix wrote:


 I'm not really a specialist in terms of license, but it'd be nice if it
 is compatible with SDC's.



 SDC uses the MIT license.


 Well, I'd use (and hack) any D compiler written in D, whatever the
 license. Let Timon code it, when the only left is the license, all
 will be well and good.


Once http://d.puremagic.com/issues/show_bug.cgi?id=9285 is done we'll 
have a realistic means to progressively port dmd's official front end 
into D by translating one module at a time and linking together C++ and 
D code. dtoh would serve as the bridge generator and would allow us to 
avoid maintaining duplicate declarations.

Andrei
Jan 09 2013
prev sibling next sibling parent reply "Tim Krimm" <twkrimm gmail.com> writes:
O

 Yes, it is in D. Nothing is released yet. It needs to be 
 polished a little so that there are no known embarrassing 
 shortcomings anymore.
 (eg. the parser cannot parse extern(...) declarations in alias 
 declarations yet, and I need to finish making a minor tweak to 
 how template instances are analyzed in order to get circular 
 dependency detection to work reliably.


How are you implementing the code generating back-end for the 
compiler?

In your design, I would recommend keeping the front-end separate 
from the back-end so that maybe the front-end can be connected to 
the LDC or GDC back-ends.
Jan 09 2013
parent reply "Timon Gehr" <timon.gehr gmx.ch> writes:
On Wednesday, 9 January 2013 at 15:45:15 UTC, Tim Krimm wrote:

 O

 Yes, it is in D. Nothing is released yet. It needs to be 
 polished a little so that there are no known embarrassing 
 shortcomings anymore.
 (eg. the parser cannot parse extern(...) declarations in alias 
 declarations yet, and I need to finish making a minor tweak to 
 how template instances are analyzed in order to get circular 
 dependency detection to work reliably.


 How are you implementing the code generating back-end for the 
 compiler?


Currently, not at all. It's just a front-end.


 In your design, I would recommend keeping the front-end 
 separate from the back-end so that maybe the front-end can be 
 connected to the LDC or GDC back-ends.


Yes, the goal is to have the back-end be fully separate. It 
should also work with no back end at all, eg. for highlighting in 
code editors.
Jan 09 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-10 04:49, Timon Gehr wrote:


 Yes, the goal is to have the back-end be fully separate. It should also
 work with no back end at all, eg. for highlighting in code editors.


That's always nice to hear.

-- 
/Jacob Carlborg
Jan 09 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 09, 2013 at 12:05:55PM +0100, Timon Gehr wrote:

 On 01/08/2013 10:06 PM, Philippe Sigaud wrote:


[...]

Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
past, but did not provide any link to it.


 
 Yes, it is in D. Nothing is released yet. It needs to be polished a
 little so that there are no known embarrassing shortcomings anymore.


[...]

 CTFE is basically done (as a portable byte code interpreter, but
 other strategies, such as JIT, could be easily plugged). This is a
 snippet of my regression test suite:
 
 auto dynRangePrimes(){
     DynRange!int impl(int start)=>
 
 dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
     return impl(2);
 }
 
 static assert(array(take(dynRangePrimes(), 20)) ==
 [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);
 
 )


Whoa!!! Now you really caught my interest!

Can it handle CTFE-computed mixins that declare and reference variables?
If it can, I will finally be able to write a library AA implementation
that allows static AA literals (no runtime init/allocation needed)!


T

-- 
Meat: euphemism for dead animal. -- Flora
Jan 09 2013
parent reply "Timon Gehr" <timon.gehr gmx.ch> writes:
On Wednesday, 9 January 2013 at 18:45:56 UTC, H. S. Teoh wrote:

 On Wed, Jan 09, 2013 at 12:05:55PM +0100, Timon Gehr wrote:

 On 01/08/2013 10:06 PM, Philippe Sigaud wrote:


 [...]

Also, Timon Gehr spoke of his own front-end (assumed to be in 
D) in the
past, but did not provide any link to it.


 
 Yes, it is in D. Nothing is released yet. It needs to be 
 polished a
 little so that there are no known embarrassing shortcomings 
 anymore.


 [...]

 CTFE is basically done (as a portable byte code interpreter, 
 ...
 
 static assert(array(take(dynRangePrimes(), 20)) ==
 [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);
 
 )


 Whoa!!! Now you really caught my interest!

 Can it handle CTFE-computed mixins that declare and reference 
 variables?
 If it can, I will finally be able to write a library AA 
 implementation
 that allows static AA literals (no runtime init/allocation 
 needed)!


Probably yes, but I am not sure what you mean. Can you provide an 
example?
Jan 09 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 10, 2013 at 04:51:35AM +0100, Timon Gehr wrote:

 On Wednesday, 9 January 2013 at 18:45:56 UTC, H. S. Teoh wrote:


[...]

Whoa!!! Now you really caught my interest!

Can it handle CTFE-computed mixins that declare and reference
variables?  If it can, I will finally be able to write a library AA
implementation that allows static AA literals (no runtime
init/allocation needed)!


 
 Probably yes, but I am not sure what you mean. Can you provide an
 example?


The basic idea behind static AA literals is to use CTFE to compute the
hashes of the keys, and therefore which slot(s) they will fall in, at
compile time. Armed with this information, we can create an array of
slots at compile-time that contains the AA entries by declaring each
slot as a static variable and using the slot assignment information to
initialize the hash table (array of pointers to slots) to point to these
slots.

Now, there are some challenges to be overcome here. For example, the
slots need to be declared as local variables, and therefore need unique
names (the hash table array needs to be able to refer to the addresses
of these variables), so the only way I can think of to do this at
compile-time is to have the CTFE code generate mixins to declare those
variables. So here's the tricky part. Suppose you have this CTFE code:

	// Not the real code, just a rough sketch to give the idea
	string aaComputeAASlots(K,V)(K[V] aaLiteral) {
		// Create slots
		string slotVars;
		foreach (key, value; aaLiteral) {
			size_t slotNum = hashOf(key) % numKeys;
			string slotName = "aaSlot" ~ slotNum;
			slotVars ~= "immutable Slot " ~ slotName ~
				" = Slot(" ~ key ~ ", " ~ value ~ ");";
		}

		string mainTable = q{
			immutable Slot*[] aaTable = {
				&aaSlot0,
				&aaSlot1,
				... // generate these programmatically
			};
		};

		return slotVars ~ mainTable;
	}

	// Instantiate AA here, at compile time.
	mixin(aaComputeAASlots(myLiteral));

The mixin string would look something like this:

	"immutable Slot aaSlot0 = Slot(..., ...);
	 immutable Slot aaSlot1 = Slot(..., ...);
	 immutable Slot*[] aaTable = {
	 	&aaSlot0, &aaSlot1, ...
	 }"

The question is, will the compile be able to resolve &aaSlot0, &aaSlot1,
etc., at compile-time?

Obviously, this code works if you copy-n-paste it into a .d source file.
It also works if I write it as a string literal, then use mixin().
However, on DMD, if the string is returned by a CTFE function that
builds it using ~, for some reason all the pointers in aaTable are null.
Strangely enough, if I assign the returned string to a string variable
and print it out at runtime, the correct string is produced.

So I concluded that somehow, DMD was unable to correctly interpret
&aaSlot0 inside a mixin string at compile-time.


T

-- 
It's bad luck to be superstitious. -- YHL
Jan 09 2013
next sibling parent "Timon Gehr" <timon.gehr gmx.ch> writes:
On Thursday, 10 January 2013 at 05:47:01 UTC, H. S. Teoh wrote:

 ...

 So I concluded that somehow, DMD was unable to correctly 
 interpret
 &aaSlot0 inside a mixin string at compile-time.


 T


If so, then that is a bug.
Jan 09 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 10 January 2013 at 05:47:01 UTC, H. S. Teoh wrote:

 On Thu, Jan 10, 2013 at 04:51:35AM +0100, Timon Gehr wrote:

 On Wednesday, 9 January 2013 at 18:45:56 UTC, H. S. Teoh wrote:


 [...]

Whoa!!! Now you really caught my interest!

Can it handle CTFE-computed mixins that declare and reference
variables?  If it can, I will finally be able to write a 
library AA
implementation that allows static AA literals (no runtime
init/allocation needed)!


 
 Probably yes, but I am not sure what you mean. Can you provide 
 an
 example?


 The basic idea behind static AA literals is to use CTFE to 
 compute the
 hashes of the keys, and therefore which slot(s) they will fall 
 in, at
 compile time. Armed with this information, we can create an 
 array of
 slots at compile-time that contains the AA entries by declaring 
 each
 slot as a static variable and using the slot assignment 
 information to
 initialize the hash table (array of pointers to slots) to point 
 to these
 slots.

 Now, there are some challenges to be overcome here. For 
 example, the
 slots need to be declared as local variables, and therefore 
 need unique
 names (the hash table array needs to be able to refer to the 
 addresses
 of these variables), so the only way I can think of to do this 
 at
 compile-time is to have the CTFE code generate mixins to 
 declare those
 variables. So here's the tricky part. Suppose you have this 
 CTFE code:

 	// Not the real code, just a rough sketch to give the idea
 	string aaComputeAASlots(K,V)(K[V] aaLiteral) {
 		// Create slots
 		string slotVars;
 		foreach (key, value; aaLiteral) {
 			size_t slotNum = hashOf(key) % numKeys;
 			string slotName = "aaSlot" ~ slotNum;
 			slotVars ~= "immutable Slot " ~ slotName ~
 				" = Slot(" ~ key ~ ", " ~ value ~ ");";
 		}

 		string mainTable = q{
 			immutable Slot*[] aaTable = {
 				&aaSlot0,
 				&aaSlot1,
 				... // generate these programmatically
 			};
 		};

 		return slotVars ~ mainTable;
 	}

 	// Instantiate AA here, at compile time.
 	mixin(aaComputeAASlots(myLiteral));

 The mixin string would look something like this:

 	"immutable Slot aaSlot0 = Slot(..., ...);
 	 immutable Slot aaSlot1 = Slot(..., ...);
 	 immutable Slot*[] aaTable = {
 	 	&aaSlot0, &aaSlot1, ...
 	 }"

 The question is, will the compile be able to resolve &aaSlot0, 
 &aaSlot1,
 etc., at compile-time?

 Obviously, this code works if you copy-n-paste it into a .d 
 source file.
 It also works if I write it as a string literal, then use 
 mixin().
 However, on DMD, if the string is returned by a CTFE function 
 that
 builds it using ~, for some reason all the pointers in aaTable 
 are null.
 Strangely enough, if I assign the returned string to a string 
 variable
 and print it out at runtime, the correct string is produced.

 So I concluded that somehow, DMD was unable to correctly 
 interpret
 &aaSlot0 inside a mixin string at compile-time.


 T
Jan 10 2013
prev sibling next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
  Eep, seems I hit send...

On Thursday, 10 January 2013 at 05:47:01 UTC, H. S. Teoh wrote:

 The basic idea behind static AA literals is to use CTFE to 
 compute the hashes of the keys, and therefore which slot(s) 
 they will fall in, at compile time. Armed with this 
 information, we can create an array of slots at compile-time 
 that contains the AA entries by declaring each slot as a static 
 variable and using the slot assignment information to 
 initialize the hash table (array of pointers to slots) to point 
 to these slots.


  Hmmm somehow that doesn't seem like a good idea; I mean it will 
work....

  Alternative is to sorta have a pair of static arrays, then 
either use a balanced tree, or a modulus to best hold (and 
separate) the values.

  Modulus based: It could be like...

   //T obviously replace with appropriate type
   ref T AA_lookup(name publicName)(uint hash) {
     //offset for part1
     //could be external to..
     immutable static int offsets[];  //no need for pointers, 
right?
     immutable static T values[]; //contains actual item data

     enum mod; //divider for table.
     uint result = hash % mod;

     //or branch to return empty? But can't be ref then...
     assert(offsets[result] != -1);

     return values[offsets[result]];
   }

  Then your CTFE increases the mod in it's calculations until 
every element can fit only once, and make the offsets based on 
them. Default values would be -1 (range error if called), course 
if it's mod is rather large and wastes a lot of space then 
perhaps it falls back on the tree structure (in those cases, > 3x 
of array size)


  Tree: I don't mind a minor performance hit, log(n) is a very 
small hit in my mind. In that case a statically created tree is 
rather easy. AA's created ahead of time are likely rather small 
(<1 Million elements). So a tree structure of:

  struct Node(T) {
    //pointers don't seem like they are needed;
    //Can even be ushorts or ubytes if small enough.
    uint left, right;
    T* value;
  }

  You get the idea.
Jan 10 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 10, 2013 at 08:38:08PM +0100, Era Scarecrow wrote:

  Eep, seems I hit send...
 
 On Thursday, 10 January 2013 at 05:47:01 UTC, H. S. Teoh wrote:

The basic idea behind static AA literals is to use CTFE to compute
the hashes of the keys, and therefore which slot(s) they will fall
in, at compile time. Armed with this information, we can create an
array of slots at compile-time that contains the AA entries by
declaring each slot as a static variable and using the slot
assignment information to initialize the hash table (array of
pointers to slots) to point to these slots.


 
  Hmmm somehow that doesn't seem like a good idea; I mean it will
 work....
 
  Alternative is to sorta have a pair of static arrays, then either
 use a balanced tree, or a modulus to best hold (and separate) the
 values.


[...]

The issue here is that I wanted to avoid the complication of having a
separate set of functions to lookup the AA literal vs. a runtime AA (and
trust me, things get *very* hairy if you go that route -- it requires
non-trivial compiler hacks to make things work with two distinct AA
types), so whatever is generated at compile-time must be the same
structure as runtime AA's so that the same AA methods will work on both.

If this is unimportant, then I would've done it another way.


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Jan 10 2013
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
10-Jan-2013 09:45, H. S. Teoh пишет:

 On Thu, Jan 10, 2013 at 04:51:35AM +0100, Timon Gehr wrote:

 On Wednesday, 9 January 2013 at 18:45:56 UTC, H. S. Teoh wrote:


 [...]

 Whoa!!! Now you really caught my interest!

 Can it handle CTFE-computed mixins that declare and reference
 variables?  If it can, I will finally be able to write a library AA
 implementation that allows static AA literals (no runtime
 init/allocation needed)!


 Probably yes, but I am not sure what you mean. Can you provide an
 example?


 The basic idea behind static AA literals is to use CTFE to compute the
 hashes of the keys, and therefore which slot(s) they will fall in, at
 compile time.


Why not try to make an AA literal a universal entity for all kinds of 
user-defined associative arrays? Then the actual construction of AA is 
done via constructor taking some type like AALiteral!(Key, Value) which 
is a sequence of Key, Value pairs. It could be even presorted.


 Armed with this information, we can create an array of
 slots at compile-time that contains the AA entries by declaring each
 slot as a static variable and using the slot assignment information to
 initialize the hash table (array of pointers to slots) to point to these
 slots.

 Now, there are some challenges to be overcome here. For example, the
 slots need to be declared as local variables, and therefore need unique
 names (the hash table array needs to be able to refer to the addresses
 of these variables), so the only way I can think of to do this at
 compile-time is to have the CTFE code generate mixins to declare those
 variables. So here's the tricky part. Suppose you have this CTFE code:

 	// Not the real code, just a rough sketch to give the idea
 	string aaComputeAASlots(K,V)(K[V] aaLiteral) {
 		// Create slots
 		string slotVars;
 		foreach (key, value; aaLiteral) {
 			size_t slotNum = hashOf(key) % numKeys;
 			string slotName = "aaSlot" ~ slotNum;
 			slotVars ~= "immutable Slot " ~ slotName ~
 				" = Slot(" ~ key ~ ", " ~ value ~ ");";
 		}

 		string mainTable = q{
 			immutable Slot*[] aaTable = {
 				&aaSlot0,
 				&aaSlot1,
 				... // generate these programmatically
 			};
 		};

 		return slotVars ~ mainTable;
 	}

 	// Instantiate AA here, at compile time.
 	mixin(aaComputeAASlots(myLiteral));

 The mixin string would look something like this:

 	"immutable Slot aaSlot0 = Slot(..., ...);
 	 immutable Slot aaSlot1 = Slot(..., ...);
 	 immutable Slot*[] aaTable = {
 	 	&aaSlot0, &aaSlot1, ...
 	 }"

 The question is, will the compile be able to resolve &aaSlot0, &aaSlot1,
 etc., at compile-time?

 Obviously, this code works if you copy-n-paste it into a .d source file.
 It also works if I write it as a string literal, then use mixin().
 However, on DMD, if the string is returned by a CTFE function that
 builds it using ~, for some reason all the pointers in aaTable are null.
 Strangely enough, if I assign the returned string to a string variable
 and print it out at runtime, the correct string is produced.


Seems like a bug.


 So I concluded that somehow, DMD was unable to correctly interpret
 &aaSlot0 inside a mixin string at compile-time.



-- 
Dmitry Olshansky
Jan 10 2013
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 10 January 2013 at 19:57:29 UTC, Dmitry Olshansky 
wrote:

 Why not try to make an AA literal a universal entity for all 
 kinds of user-defined associative arrays? Then the actual 
 construction of AA is done via constructor taking some type 
 like AALiteral!(Key, Value) which is a sequence of Key, Value 
 pairs. It could be even presorted.


  Only problem I would see with that, is trying to give something 
to a non-template function.

auto x = AALiteral!(string, string)([]);

void func(string[string] something);

func(x); // x is not type string[string], is type 
xxx!string,string

  Course that brings up problem(s) with my own idea thrown out 
there.

  Seems like the problem is just determining storage type, at CTFE 
it calls one type of constructor while the non-CTFE calls 
another; So long as the structure is the same then passing it 
around wouldn't matter.
Jan 10 2013
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 10 January 2013 at 20:48:12 UTC, Era Scarecrow wrote:


 func(x); // x is not type string[string], is type 
 xxx!string,string


  Thinking about it, if the AA is just syntactical sugar for a 
struct (say defined in core.memory) which handles that then the 
problem goes away.
Jan 10 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11-Jan-2013 00:49, Era Scarecrow пишет:

 On Thursday, 10 January 2013 at 20:48:12 UTC, Era Scarecrow wrote:


 func(x); // x is not type string[string], is type xxx!string,string


   Thinking about it, if the AA is just syntactical sugar for a struct
 (say defined in core.memory) which handles that then the problem goes away.


+ user defined implicit conversion so that AALiteral(K,V) 
--*implicitly*!--> AA!(K,V)


The other use case for user-defined implicit conversion were already 
outlined before so I hope it will make its way in one day.

-- 
Dmitry Olshansky
Jan 10 2013
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 10 January 2013 at 22:02:17 UTC, Dmitry Olshansky 
wrote:

 + user defined implicit conversion so that AALiteral(K,V) 
 --*implicitly*!--> AA!(K,V)


 The other use case for user-defined implicit conversion were 
 already outlined before so I hope it will make its way in one 
 day.


  I thought I heard talk of possibly moving AA's to a library 
implementation rather than a built in feature (Still 'built in' 
technically).
Jan 10 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 10, 2013 at 11:18:07PM +0100, Era Scarecrow wrote:

 On Thursday, 10 January 2013 at 22:02:17 UTC, Dmitry Olshansky
 wrote:

+ user defined implicit conversion so that AALiteral(K,V)
--*implicitly*!--> AA!(K,V)


The other use case for user-defined implicit conversion were
already outlined before so I hope it will make its way in one day.


 
  I thought I heard talk of possibly moving AA's to a library
 implementation rather than a built in feature (Still 'built in'
 technically).


That's my plan, and Andrei's hope. But it's not going to be easy. The
current AA implementation is split between object_.d and aaA.d in
druntime, with bits scattered throughout the compiler. Cleaning all of
that up is going to be a big job.


T

-- 
No! I'm not in denial!
Jan 10 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 10 January 2013 at 22:28:46 UTC, H. S. Teoh wrote:

 On Thu, Jan 10, 2013 at 11:18:07PM +0100, Era Scarecrow wrote:

 On Thursday, 10 January 2013 at 22:02:17 UTC, Dmitry Olshansky
 wrote:

+ user defined implicit conversion so that AALiteral(K,V)
--*implicitly*!--> AA!(K,V)


The other use case for user-defined implicit conversion were
already outlined before so I hope it will make its way in one 
day.


 
  I thought I heard talk of possibly moving AA's to a library
 implementation rather than a built in feature (Still 'built in'
 technically).


 That's my plan, and Andrei's hope. But it's not going to be 
 easy. The
 current AA implementation is split between object_.d and aaA.d 
 in
 druntime, with bits scattered throughout the compiler. Cleaning 
 all of
 that up is going to be a big job.


You may want to look at this : 
http://preshing.com/20130107/this-hash-table-is-faster-than-a-judy-array

Additionally, can you show me what you have so far ? I'd be 
interested in using it directly for SDC without using the 
existing one at all.
Jan 10 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 11, 2013 at 08:47:19AM +0100, deadalnix wrote:

 On Thursday, 10 January 2013 at 22:28:46 UTC, H. S. Teoh wrote:

On Thu, Jan 10, 2013 at 11:18:07PM +0100, Era Scarecrow wrote:

On Thursday, 10 January 2013 at 22:02:17 UTC, Dmitry Olshansky
wrote:

+ user defined implicit conversion so that AALiteral(K,V)
--*implicitly*!--> AA!(K,V)


The other use case for user-defined implicit conversion were
already outlined before so I hope it will make its way in one
day.


 I thought I heard talk of possibly moving AA's to a library
implementation rather than a built in feature (Still 'built in'
technically).


That's my plan, and Andrei's hope. But it's not going to be easy.
The current AA implementation is split between object_.d and aaA.d in
druntime, with bits scattered throughout the compiler. Cleaning all
of that up is going to be a big job.


 
 You may want to look at this :
 http://preshing.com/20130107/this-hash-table-is-faster-than-a-judy-array
 
 Additionally, can you show me what you have so far ? I'd be
 interested in using it directly for SDC without using the existing
 one at all.


https://github.com/quickfur/New-AA-implementation

It's basically just a refactoring of the current AA code to hoist it
into object_.d; I didn't introduce any new algorithms or data
structures.


T

-- 
This is a tpyo.
Jan 11 2013
prev sibling parent reply "Rob T" <alanb ucora.com> writes:
On Thursday, 10 January 2013 at 22:18:08 UTC, Era Scarecrow wrote:

 On Thursday, 10 January 2013 at 22:02:17 UTC, Dmitry Olshansky 
 wrote:

 + user defined implicit conversion so that AALiteral(K,V) 
 --*implicitly*!--> AA!(K,V)


 The other use case for user-defined implicit conversion were 
 already outlined before so I hope it will make its way in one 
 day.


  I thought I heard talk of possibly moving AA's to a library 
 implementation rather than a built in feature (Still 'built in' 
 technically).


I was wondering the same thing: Why do AA's have to be built 
directly into the language rather than implemented within the 
standard library?

AA's may be nice to have, but are they really all that 
fundamental? For example, everyone uses strings, but I suspect 
not everyone will use AA's.

It could however be that some fundamental constructs in the D 
language make use of the built in AA's (tuples?), so if that is 
the case I can understand why they would be built in, but I do 
not know if this is the case or not.

On a side note, I'm wondering if this may be a way that can help 
decide what should or should not be made a built in component of 
the language, i.e, If the language itself can make good use of 
the feature internally, then it's a good candidate for being 
built in, but if not, then it's a good candidate for being left 
out and instead implemented in the std lib or elsewhere.

--rt
Jan 10 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/10/13 4:21 PM, Rob T wrote:

 I was wondering the same thing: Why do AA's have to be built directly
 into the language rather than implemented within the standard library?

 AA's may be nice to have, but are they really all that fundamental? For
 example, everyone uses strings, but I suspect not everyone will use AA's.

 It could however be that some fundamental constructs in the D language
 make use of the built in AA's (tuples?), so if that is the case I can
 understand why they would be built in, but I do not know if this is the
 case or not.


The only distinguishing feature is literal syntax. Everything else is a 
mistake in language design or an insufficiency in the state of the art.


 On a side note, I'm wondering if this may be a way that can help decide
 what should or should not be made a built in component of the language,
 i.e, If the language itself can make good use of the feature internally,
 then it's a good candidate for being built in, but if not, then it's a
 good candidate for being left out and instead implemented in the std lib
 or elsewhere.


Long discussion. Very long.


Andrei
Jan 10 2013
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
09-Jan-2013 15:05, Timon Gehr пишет:

 On 01/08/2013 10:06 PM, Philippe Sigaud wrote:

 ...

 Isn't SDC also in D? (Bernard Helyer and friends)
 https://github.com/bhelyer/SDC


 Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
 past, but did not provide any link to it.


 Yes, it is in D. Nothing is released yet. It needs to be polished a
 little so that there are no known embarrassing shortcomings anymore.
 (eg. the parser cannot parse extern(...) declarations in alias
 declarations yet, and I need to finish making a minor tweak to how
 template instances are analyzed in order to get circular dependency
 detection to work reliably. Furthermore, examples like the following are
 currently rejected, while I want it to work:


[snip]


 CTFE is basically done (as a portable byte code interpreter, but other
 strategies, such as JIT, could be easily plugged). This is a snippet of
 my regression test suite:

 auto dynRangePrimes(){
      DynRange!int impl(int start)=>

 dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
      return impl(2);
 }

 static assert(array(take(dynRangePrimes(), 20)) ==
 [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);

 )


Cool! I'd love to take even the very preliminary peek at the speed 
profile of this CTFE engine.

If you are interested I'd love to test a small (the code though contains 
a lot of static data) CTFE benchmark that is the bottleneck in the 
compilation of current ctRegex.

See the attachment here:
http://d.puremagic.com/issues/show_bug.cgi?id=7442

would be nice to see some rough numbers for this vs DMD.


 I also need to decide on a licence. I assume that the alpha will be out
 in late spring. (I am busy until early spring.)


Eagerly waiting to play with it.

-- 
Dmitry Olshansky
Jan 10 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/10/2013 08:52 PM, Dmitry Olshansky wrote:

 09-Jan-2013 15:05, Timon Gehr пишет:

 On 01/08/2013 10:06 PM, Philippe Sigaud wrote:

 ...

 Isn't SDC also in D? (Bernard Helyer and friends)
 https://github.com/bhelyer/SDC


 Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
 past, but did not provide any link to it.


 Yes, it is in D. Nothing is released yet. It needs to be polished a
 little so that there are no known embarrassing shortcomings anymore.
 (eg. the parser cannot parse extern(...) declarations in alias
 declarations yet, and I need to finish making a minor tweak to how
 template instances are analyzed in order to get circular dependency
 detection to work reliably. Furthermore, examples like the following are
 currently rejected, while I want it to work:


 [snip]


 CTFE is basically done (as a portable byte code interpreter, but other
 strategies, such as JIT, could be easily plugged). This is a snippet of
 my regression test suite:

 auto dynRangePrimes(){
      DynRange!int impl(int start)=>

 dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
      return impl(2);
 }

 static assert(array(take(dynRangePrimes(), 20)) ==
 [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);

 )


 Cool! I'd love to take even the very preliminary peek at the speed
 profile of this CTFE engine.

 If you are interested I'd love to test a small (the code though contains
 a lot of static data) CTFE benchmark that is the bottleneck in the
 compilation of current ctRegex.

 See the attachment here:
 http://d.puremagic.com/issues/show_bug.cgi?id=7442

 would be nice to see some rough numbers for this vs DMD.


I'll let you know as soon as the example runs. Currently this is blocked 
by the missing implementation for the following language features:

- import declarations
- UFCS
- Optional parens on function calls
- Struct literals
- Static struct data
- debug declarations
- Some of the built-in array operations
- Missing object.d (no string, size_t, hash_t alias.)
- (static) foreach
- __ctfe

I will prioritize those features. Except import declarations, they are 
mostly easy to implement, but I haven't gotten around to them yet.

For the meantime, maybe these quick measurements are somewhat useful:

int[] erathos(int x){
	bool[] p;
	for(int i=0;i<=x;i++) p~=true;
	for(int i=3;i*i<=x;i+=2){
		if(p[i]) for(int k=i*i;k<=x;k=k+i) p[k]=false;
	}
	int[] r;
	if(x>=2) r~=2;
	for(int i=3;i<=x;i+=2) if(p[i]) r~=i;
	return r;
}

pragma(msg, "erathos: ",erathos(40000).length);


The frontend (32-bit dmd build, without -inline, otherwise DMD ICEs):
$ time ./d erathos.d
erathos: 4203U

real	0m0.077s
user	0m0.076s
sys	0m0.000s


DMD 2.060 (64 bit):
$ time dmd -o- erathos.d
erathos: 4203u

real	0m2.594s
user	0m0.716s
sys	0m1.696s


...

pragma(msg, "erathos: ",erathos(400000)); // (that is one 0 more)

The frontend:
erathos: 33860U

real	0m0.662s
user	0m0.660s
sys	0m0.000s

DMD: brings down the machine

pragma(msg, "erathos: ",erathos(4000000)); // (yet another 0 more)

The frontend:
erathos: 283146U

real	0m6.867s
user	0m6.832s
sys	0m0.016s

// pragma(msg, "erathos: ",erathos(4000000));
void main(){
     import std.stdio;
     writeln(erathos(4000000).length);
}

$ dmd -O -release -inline -noboundscheck erathos.d && time ./erathos
dmd: module.c:829: void Module::semantic3(): Assertion `semanticstarted 
== 2' failed.

(I'll see if it also fails with DMD 2.061.)

$ dmd -O -release -noboundscheck erathos.d && time ./erathos
283146

real	0m0.144s
user	0m0.132s
sys	0m0.008s

So CTFE in the front end seems to be ~50 times slower than a optimized 
DMD build of the same code in this case. But note that it is powered by 
a simple-minded bytecode interpreter I hacked together mostly during two 
weekends. (the array append is the one from druntime) A lot more is 
possible. I guess it is already fast enough to power std.regex.
Jan 10 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11-Jan-2013 05:43, Timon Gehr пишет:

 On 01/10/2013 08:52 PM, Dmitry Olshansky wrote:


[snip]

 Cool! I'd love to take even the very preliminary peek at the speed
 profile of this CTFE engine.

 If you are interested I'd love to test a small (the code though contains
 a lot of static data) CTFE benchmark that is the bottleneck in the
 compilation of current ctRegex.

 See the attachment here:
 http://d.puremagic.com/issues/show_bug.cgi?id=7442

 would be nice to see some rough numbers for this vs DMD.


 I'll let you know as soon as the example runs. Currently this is blocked
 by the missing implementation for the following language features:

 - import declarations
 - UFCS
 - Optional parens on function calls
 - Struct literals
 - Static struct data
 - debug declarations
 - Some of the built-in array operations
 - Missing object.d (no string, size_t, hash_t alias.)
 - (static) foreach
 - __ctfe


I guess that core.bitop intrinsics too. Either way, thanks in advance.


 I will prioritize those features. Except import declarations, they are
 mostly easy to implement, but I haven't gotten around to them yet.

 For the meantime, maybe these quick measurements are somewhat useful:


They truly are. As I've been long wondering that CTFE could be quite 
fast if it wasn't for it's current architecture in DMD. Just needed the 
hard data to go by.


 int[] erathos(int x){
      bool[] p;
      for(int i=0;i<=x;i++) p~=true;
      for(int i=3;i*i<=x;i+=2){
          if(p[i]) for(int k=i*i;k<=x;k=k+i) p[k]=false;
      }
      int[] r;
      if(x>=2) r~=2;
      for(int i=3;i<=x;i+=2) if(p[i]) r~=i;
      return r;
 }

 pragma(msg, "erathos: ",erathos(40000).length);


 The frontend (32-bit dmd build, without -inline, otherwise DMD ICEs):
 $ time ./d erathos.d
 erathos: 4203U

 real    0m0.077s
 user    0m0.076s
 sys    0m0.000s


 DMD 2.060 (64 bit):
 $ time dmd -o- erathos.d
 erathos: 4203u

 real    0m2.594s
 user    0m0.716s
 sys    0m1.696s


 ...

 pragma(msg, "erathos: ",erathos(400000)); // (that is one 0 more)

 The frontend:
 erathos: 33860U

 real    0m0.662s
 user    0m0.660s
 sys    0m0.000s

 DMD: brings down the machine

 pragma(msg, "erathos: ",erathos(4000000)); // (yet another 0 more)

 The frontend:
 erathos: 283146U

 real    0m6.867s
 user    0m6.832s
 sys    0m0.016s

 // pragma(msg, "erathos: ",erathos(4000000));
 void main(){
      import std.stdio;
      writeln(erathos(4000000).length);
 }

 $ dmd -O -release -inline -noboundscheck erathos.d && time ./erathos
 dmd: module.c:829: void Module::semantic3(): Assertion `semanticstarted
 == 2' failed.


I bet this one was fixed in 2.061, I've recently seen the similar bug as 
resolved "works for me".


 (I'll see if it also fails with DMD 2.061.)

 $ dmd -O -release -noboundscheck erathos.d && time ./erathos
 283146

 real    0m0.144s
 user    0m0.132s
 sys    0m0.008s



 So CTFE in the front end seems to be ~50 times slower than a optimized
 DMD build of the same code in this case. But note that it is powered by
 a simple-minded bytecode interpreter I hacked together mostly during two
 weekends.


Yes, yes and yes! Simple bytecode interpreter is what I've been waiting 
for :)


 (the array append is the one from druntime) A lot more is
 possible. I guess it is already fast enough to power std.regex.


Sure and a simple threaded-code interpreter should make it fly (when D 
has e.g. explicit tail call).

-- 
Dmitry Olshansky
Jan 11 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 08, 2013 at 07:48:58PM +0100, Tim Krimm wrote:

 
 Now that D 2.0 is fairly stable, are there any plans of writing the
 official DMD compiler with the D 2.0 language vs the present
 language of C++?
 
 DMD 2.0 would have to be feature frozen and then DMD 3.0 could be
 written with the previous DMD 2.0 compiler.
 
 What are your thoughts?


Philosophically, I like this idea. D should eat its own dogfood to prove
its own worth. :)

However, having the D compiler itself written in D, means we will have
trouble bootstrapping it on new platforms. The advantage of having a C++
implementation is that C/C++ compilers are almost the first thing that
gets implemented on a new platform, so you can almost always count on
their existence. So you can just compile DMD and away you go.

We *could* write a cross-compiler, of course, but it still requires that
you first target the D compiler (written in D) to the new platform, and
then cross-compile itself to that platform.  Whereas with DMD, you just
use the target platform's C++ compiler and you're up and running.


T

-- 
What's a "hot crossed bun"? An angry rabbit.
Jan 08 2013
next sibling parent "Nicolas Sicard" <dransic gmail.com> writes:
On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:

 On Tue, Jan 08, 2013 at 07:48:58PM +0100, Tim Krimm wrote:

 
 Now that D 2.0 is fairly stable, are there any plans of 
 writing the
 official DMD compiler with the D 2.0 language vs the present
 language of C++?
 
 DMD 2.0 would have to be feature frozen and then DMD 3.0 could 
 be
 written with the previous DMD 2.0 compiler.
 
 What are your thoughts?


 Philosophically, I like this idea. D should eat its own dogfood 
 to prove
 its own worth. :)

 However, having the D compiler itself written in D, means we 
 will have
 trouble bootstrapping it on new platforms. The advantage of 
 having a C++
 implementation is that C/C++ compilers are almost the first 
 thing that
 gets implemented on a new platform, so you can almost always 
 count on
 their existence. So you can just compile DMD and away you go.

 We *could* write a cross-compiler, of course, but it still 
 requires that
 you first target the D compiler (written in D) to the new 
 platform, and
 then cross-compile itself to that platform.  Whereas with DMD, 
 you just
 use the target platform's C++ compiler and you're up and 
 running.


 T


I think the OP implied that we could build DMD2 from its C++ 
source on any platform and then DMD3 from its D source with DMD2.
Jan 08 2013
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:

 We *could* write a cross-compiler, of course, but it still 
 requires that
 you first target the D compiler (written in D) to the new 
 platform, and
 then cross-compile itself to that platform.  Whereas with DMD, 
 you just
 use the target platform's C++ compiler and you're up and 
 running.


…except that you can't actually use that compiler for anything, 
because – wait for it – it still needs to be retargeted for the 
new platform. What kind of new system are you thinking of for 
which the first use case would be compiling x86 executables?

David
Jan 08 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 09, 2013 at 01:33:35AM +0100, David Nadlinger wrote:

 On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:

We *could* write a cross-compiler, of course, but it still requires
that you first target the D compiler (written in D) to the new
platform, and then cross-compile itself to that platform.  Whereas
with DMD, you just use the target platform's C++ compiler and you're
up and running.


 
 …except that you can't actually use that compiler for anything,
 because – wait for it – it still needs to be retargeted for the new
 platform. What kind of new system are you thinking of for which the
 first use case would be compiling x86 executables?


[...]

Heh, you're right. I appear to be having a streak of making a fool of
myself today.


T

-- 
Today's society is one of specialization: as you grow, you learn more
and more about less and less. Eventually, you know everything about
nothing.
Jan 08 2013
parent 1100110 <0b1100110 gmail.com> writes:
On 01/08/2013 06:38 PM, H. S. Teoh wrote:

 On Wed, Jan 09, 2013 at 01:33:35AM +0100, David Nadlinger wrote:

 On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:

 We *could* write a cross-compiler, of course, but it still requires
 that you first target the D compiler (written in D) to the new
 platform, and then cross-compile itself to that platform.  Whereas
 with DMD, you just use the target platform's C++ compiler and you're
 up and running.


 …except that you can't actually use that compiler for anything,
 because – wait for it – it still needs to be retargeted for the new
 platform. What kind of new system are you thinking of for which the
 first use case would be compiling x86 executables?


 [...]

 Heh, you're right. I appear to be having a streak of making a fool of
 myself today.


 T


I'm embarrassed to admit that I didn't understand the problem until I 
read your response...

I love the idea of a D compiler in D.
Walter might have issues with working on any other compiler backend 
other than digitalmars, wasn't that what was determined by previous threads?
Jan 08 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:

 Philosophically, I like this idea. D should eat its own dogfood



+11111!1!!1eleven1!!!!1!
Jan 08 2013
prev sibling parent "Tim Krimm" <twkrimm gmail.com> writes:
On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:


 We *could* write a cross-compiler, of course, but it still 
 requires that
 you first target the D compiler (written in D) to the new 
 platform, and
 then cross-compile itself to that platform.  Whereas with DMD, 
 you just
 use the target platform's C++ compiler and you're up and 
 running.


 T


I think LDC 2.0 or GDC 2.0 might be able to serve this purpose.
Jan 09 2013