www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D.NET website

reply Deja Augustine <deja scratch-ware.net> writes:
Okay... I swear to God this is the last time I'm going to post this...

http://www.scratch-ware.net/D/main.html

Here's the code test file that I'm using to test out D.NET.  Someone was 
nice enough to point out that I can make it pretty using SciTE and thus 
I have done so.  Enjoy

Deja
Aug 03 2004
next sibling parent Juanjo =?ISO-8859-15?Q?=C1lvarez?= <juanjuxNO SPAMyahoo.es> writes:
Deja Augustine wrote:


 Okay... I swear to God this is the last time I'm going to post this...
 
 http://www.scratch-ware.net/D/main.html
 
 Here's the code test file that I'm using to test out D.NET.  Someone was
 nice enough to point out that I can make it pretty using SciTE and thus
 I have done so.  Enjoy
 
 Deja


Wow man, you're fast!

The question now don't seems to be what does D.NET supports but what it
lacks :)
Aug 04 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Deja Augustine wrote:


 Okay... I swear to God this is the last time I'm going to post this...
 
 http://www.scratch-ware.net/D/main.html
 
 Here's the code test file that I'm using to test out D.NET.


<snip>

Is D.NET the name of a file that is one of:
- FileMaker Pro Networking Module
- netViz Project
- Network Configuration
- OrCad Netlist Output File

Or a domain that IANA has reserved for you?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Aug 04 2004
parent reply Deja Augustine <deja scratch-ware.net> writes:
Stewart Gordon wrote:


 Deja Augustine wrote:
 

 Okay... I swear to God this is the last time I'm going to post this...

 http://www.scratch-ware.net/D/main.html

 Here's the code test file that I'm using to test out D.NET.


 
 <snip>
 
 Is D.NET the name of a file that is one of:
 - FileMaker Pro Networking Module
 - netViz Project
 - Network Configuration
 - OrCad Netlist Output File
 
 Or a domain that IANA has reserved for you?
 
 Stewart.
 



I'm not quite sure I understand what you're asking.

D.NET is a D compiler that I'm writing (I'd call it a back-end, except 
that it's reaching the point where I'm almost forking the front-end 
because I've had to modify it so much).

D.NET compiles standard D code into MSIL which is the .NET intermediate 
language used to create .NET compatible assemblies. The assemblies 
generated by D.NET are usable in other .NET languages such as Managed 


I hope that helps,

Deja
Aug 04 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Deja Augustine wrote:
<snip>

 D.NET is a D compiler that I'm writing (I'd call it a back-end, except 
 that it's reaching the point where I'm almost forking the front-end 
 because I've had to modify it so much).


I still haven't quite figured out how the terms "front-end" and 
"back-end" work with compilers, or if there's an exact definition. 
Presumably at least some have a middle-end as well....


 D.NET compiles standard D code into MSIL which is the .NET intermediate 
 language used to create .NET compatible assemblies. The assemblies 
 generated by D.NET are usable in other .NET languages such as Managed 



I see.  I don't know why M$ decided to name a platform after a top-level 
domain, rather as if it owns the TLD....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Aug 04 2004
parent reply Deja Augustine <deja scratch-ware.net> writes:
Stewart Gordon wrote:


 Deja Augustine wrote:
 <snip>
 

 D.NET is a D compiler that I'm writing (I'd call it a back-end, except 
 that it's reaching the point where I'm almost forking the front-end 
 because I've had to modify it so much).


 
 
 I still haven't quite figured out how the terms "front-end" and 
 "back-end" work with compilers, or if there's an exact definition. 
 Presumably at least some have a middle-end as well....
 


A compiler front-end is the lexer/parser that actually interprets the 
source code and converts it into an abstract syntax tree which it then 
passes to the back-end.  The back-end takes this syntax tree and 
generates the machine code (or in this case, the IL code) and then 
passes that code on to the linker which is usually a separate program 
that merges the various machine code chunks into a single portable 
executable file (exe, dll, so, what have you)

So in short, the front-end converts the source code into some generic 
format, the back-end converts the generic format into a bytecode and the 
linker converts the bytecode into an executable.

Generally, the front-end and back-end are contained in a single 
executable, however they don't necessarily need to be so (as I think may 
be the case with the GCC back-end, but I'm not sure)

Hope that helps

Deja
Aug 04 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Deja Augustine wrote:

<snip>

 A compiler front-end is the lexer/parser that actually interprets the 
 source code and converts it into an abstract syntax tree which it then 
 passes to the back-end.  The back-end takes this syntax tree and 
 generates the machine code (or in this case, the IL code) and then 
 passes that code on to the linker which is usually a separate program 
 that merges the various machine code chunks into a single portable 
 executable file (exe, dll, so, what have you)


There are stages between parsing and object code generation.  Like 
semantic analysis, obviously.  Presumably some conversion from the plain 
old parse tree into a more logically structured form would be involved. 
  Not to mention, in terms of D at least, the mapping of certain 
constructs to the stuff in the internal and std.typeinfo packages....

<snip>

 Generally, the front-end and back-end are contained in a single 
 executable, however they don't necessarily need to be so (as I think may 
 be the case with the GCC back-end, but I'm not sure)


Well, the GCC back end supports several languages, and I don't know if 
different GCC-based compilers have their own copies of this or call one 
back-end somewhere on the machine.

Obviously someone couldn't just plug the DMD front-end into the GCC 
back-end without anything in between.  Somebody had to write a 
middle-end.  And if only the DMD middle-end could be open source, it 
would speed up development a bit....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Aug 04 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Stewart Gordon wrote:


 Deja Augustine wrote:
 
 <snip>
 

 A compiler front-end is the lexer/parser that actually interprets the 
 source code and converts it into an abstract syntax tree which it then 
 passes to the back-end.  The back-end takes this syntax tree and 
 generates the machine code (or in this case, the IL code) and then 
 passes that code on to the linker which is usually a separate program 
 that merges the various machine code chunks into a single portable 
 executable file (exe, dll, so, what have you)


 
 
 There are stages between parsing and object code generation.  Like 
 semantic analysis, obviously.  Presumably some conversion from the plain 
 old parse tree into a more logically structured form would be involved. 
  Not to mention, in terms of D at least, the mapping of certain 
 constructs to the stuff in the internal and std.typeinfo packages....


Semantic analysis is generally considered to be a front-end task.


 Generally, the front-end and back-end are contained in a single 
 executable, however they don't necessarily need to be so (as I think 
 may be the case with the GCC back-end, but I'm not sure)


 
 Well, the GCC back end supports several languages, and I don't know if 
 different GCC-based compilers have their own copies of this or call one 
 back-end somewhere on the machine.


GCC frontends are directly compiled into the resulting binary, as I 
understand it.  It's basically a matter of some scripts deciding which 
files to link.


 Obviously someone couldn't just plug the DMD front-end into the GCC 
 back-end without anything in between.  Somebody had to write a 
 middle-end.  And if only the DMD middle-end could be open source, it 
 would speed up development a bit....


This isn't really part of either.  It's just a matter of translating the 
DMD structures into what the GCC backend expects.  I'm sure DMD doesn't 
even have such a layer, because its code generator is almost certainly 
written to recieve exactly what the front-end produces.

  -- andy
Aug 04 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Andy Friesen wrote:


 Stewart Gordon wrote:


<snip>

 Not to mention, in terms of D at least, the mapping of 
 certain constructs to the stuff in the internal and std.typeinfo 
 packages....


 
 Semantic analysis is generally considered to be a front-end task.


The DMD front-end probably includes this, but it clearly doesn't include 
the last of my points.  Indeed, my searches have shown that it doesn't 
seem to have any references to the internal package at all.  That's why 
it's impossible to get at half the bugs.

<snip>

 GCC frontends are directly compiled into the resulting binary, as I 
 understand it.  It's basically a matter of some scripts deciding which 
 files to link.


Do you mean GCC is one program, which compiles every language installed 
in it?


 Obviously someone couldn't just plug the DMD front-end into the GCC 
 back-end without anything in between.  Somebody had to write a 
 middle-end.  And if only the DMD middle-end could be open source, it 
 would speed up development a bit....


 
 This isn't really part of either.  It's just a matter of translating the 
 DMD structures into what the GCC backend expects.  I'm sure DMD doesn't 
 even have such a layer, because its code generator is almost certainly 
 written to recieve exactly what the front-end produces.


What's your theory on how the internals of D builtins are mapped in then?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Aug 04 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Stewart Gordon wrote:


 Andy Friesen wrote:
 

 Stewart Gordon wrote:


 
 <snip>
 

 Not to mention, in terms of D at least, the mapping of certain 
 constructs to the stuff in the internal and std.typeinfo packages....



 Semantic analysis is generally considered to be a front-end task.


 
 
 The DMD front-end probably includes this, but it clearly doesn't include 
 the last of my points.  Indeed, my searches have shown that it doesn't 
 seem to have any references to the internal package at all.  That's why 
 it's impossible to get at half the bugs.


If you're talking about how builtin language constructs map to phobos 
library function calls, it's just a matter of the compiler creating 
forward declarations of those functions and generating calls to them. 
The linker sorts out the rest.


 <snip>
 

 GCC frontends are directly compiled into the resulting binary, as I 
 understand it.  It's basically a matter of some scripts deciding which 
 files to link.


 
 Do you mean GCC is one program, which compiles every language installed 
 in it?


Sort of.  A gross simplification would be:

     cc cplusplus-lang.c backend.c -o g++

or: cc c-lang.c backend.c -o gcc

or: cc java-lang.c backend.c -o gjc

  -- andy
Aug 04 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Andy Friesen wrote:
<snip>

 The DMD front-end probably includes this, but it clearly doesn't 
 include the last of my points.  Indeed, my searches have shown that it 
 doesn't seem to have any references to the internal package at all.  
 That's why it's impossible to get at half the bugs.


 
 If you're talking about how builtin language constructs map to phobos 
 library function calls, it's just a matter of the compiler creating 
 forward declarations of those functions and generating calls to them. 


<snip>

Obviously.  But this has to happen somewhere, be it the front-end, the 
middle-end or the back-end.

Looking at the code shows that it isn't in the front-end.

It can't be in the back-end, if the back-end is supposed to be 
cross-language.

So it must be in the middle-end.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Aug 05 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cesu3j$1bnh$1 digitaldaemon.com>, Stewart Gordon says...


Obviously.  But this has to happen somewhere, be it the front-end, the 
middle-end or the back-end.


..


So it must be in the middle-end.


Isn't "middle-end" an oxymoron?
Shouldn't it just be called "middle"?

Jill
Aug 05 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
Arcane Jill schrieb:


 Isn't "middle-end" an oxymoron?
 Shouldn't it just be called "middle"?


or a middle-double-end?

front--->end /middle\ end<---back

i see 2 ends in the middle.

-eye
Aug 09 2004
prev sibling parent reply Deja Augustine <deja scratch-ware.net> writes:
Stewart Gordon wrote:


 Andy Friesen wrote:
 <snip>
 

 The DMD front-end probably includes this, but it clearly doesn't 
 include the last of my points.  Indeed, my searches have shown that 
 it doesn't seem to have any references to the internal package at 
 all.  That's why it's impossible to get at half the bugs.



 If you're talking about how builtin language constructs map to phobos 
 library function calls, it's just a matter of the compiler creating 
 forward declarations of those functions and generating calls to them. 


 
 <snip>
 
 Obviously.  But this has to happen somewhere, be it the front-end, the 
 middle-end or the back-end.
 
 Looking at the code shows that it isn't in the front-end.
 
 It can't be in the back-end, if the back-end is supposed to be 
 cross-language.
 
 So it must be in the middle-end.
 
 Stewart.
 


Actually, the front-end takes care of that.  It's the front-end's duty 
to import all of the modules (including the implicit import to parts of 
the phobos library).  There is no middle"-end".  The front-end passes 
everything straight to the back-end.  The only possible middle-end would 
be something in the case of the GCC front-end that converts the AST 
returned by the DMD front-end into the AST that the GCC back-end expects.

Once again, the front-end's sole purpose is to parse the code into an 
internal syntax tree.  It has no other responsibilities.  It checks for 
syntactical errors such as type mismatching, unknown identifiers, etc. 
If it finds a call to a library function that it recognizes (from being 
imported either implicitly, explicitly or being forward declared via an 
extern (blah) blah blah(blah); call) it generates a CallExpression will 
all of the necessary info to pass to the backend about those functions.

It's purely the job of the back-end to generate the bytecode/machinecode 
from this AST.  The back-end doesn't really do anything else.  There are 
a couple errors that it catches, such as invalid casts, etc.  But for 
the most part, most of the errors the compiler generates are syntactical 
errors caught by the front-end.

Once it's compiled, the byte/machine code gets passed to the linker 
which actually figures out all of the precise addresses from which 
libraries that the functions calls need to be made to and it's then that 
it actually checks to see if those functions exist in those libraries 
(including phobos.lib).
Aug 05 2004
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Deja Augustine wrote:


 Stewart Gordon wrote:
 

 Andy Friesen wrote:




<snip>

 If you're talking about how builtin language constructs map to phobos 
 library function calls, it's just a matter of the compiler creating 
 forward declarations of those functions and generating calls to them. 






<snip>

 So it must be in the middle-end.


 
 Actually, the front-end takes care of that.  It's the front-end's duty 
 to import all of the modules (including the implicit import to parts of 
 the phobos library).


<snip>

I'm not sure how you work that out.  But I'll search again through the 
front-end code and get back to you on this.


 Once again, the front-end's sole purpose is to parse the code into an 
 internal syntax tree.  It has no other responsibilities.  It checks for 
 syntactical errors such as type mismatching, unknown identifiers, etc. 


<snip>

That's a self-contradiction.  Type mismatching and unknown identifiers 
are semantic errors, not syntactical errors.  Finding these is part of 
semantic analysis, which is a separate phase from parsing.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Aug 05 2004
parent Deja Augustine <Deja_member pathlink.com> writes:
In article <cetmui$1qqs$1 digitaldaemon.com>, Stewart Gordon says...

Deja Augustine wrote:


 Stewart Gordon wrote:
 

 Andy Friesen wrote:




<snip>

 If you're talking about how builtin language constructs map to phobos 
 library function calls, it's just a matter of the compiler creating 
 forward declarations of those functions and generating calls to them. 






<snip>

 So it must be in the middle-end.


 
 Actually, the front-end takes care of that.  It's the front-end's duty 
 to import all of the modules (including the implicit import to parts of 
 the phobos library).


<snip>

I'm not sure how you work that out.  But I'll search again through the 
front-end code and get back to you on this.


 Once again, the front-end's sole purpose is to parse the code into an 
 internal syntax tree.  It has no other responsibilities.  It checks for 
 syntactical errors such as type mismatching, unknown identifiers, etc. 


<snip>

That's a self-contradiction.  Type mismatching and unknown identifiers 
are semantic errors, not syntactical errors.  Finding these is part of 
semantic analysis, which is a separate phase from parsing.


typo, and a mistatement.  I was referring to semantic analysis which is also
handled by the front-end.  Perhaps I didn't realize I was talking to someone who
knew a ton about compiler theory, and I, personally, don't know all that much
about the specific terminologies as I'm not a CS or CT student.

However, since I have written quite a bit of a back-end for this, I can tell you
what the front-end gives me and what I do with it.  

The front end creates a heirarchy of declarations, statements and expressions.
It's already checked to make sure that all of the identifiers are valid, it
checks to make sure that there aren't any illegal casts, it does full semantic
analysis on the parsed code.  It then gives that heirarchy to me.

All the back-end does is handles all of the cases, so for a variable expression,
it output such and such a piece of machine code into the object file, for a
class declaration, emit this bit of code, for an add-assign (+=) expression,
emit this bit of code.  That's really all there is to it.  Naturally, if you're
given a class declaration, you also cycle through and call other back-end
methods on each of the classes members, but 95% of the back-end's responsibility
is purely to emit code to the object files.

I'm done talking about compiler theory.  If you have a specific question about
how I handled something in D.NET, please reply, but if not, please redirect your
questions to the board in general under a separate heading.


Deja
Aug 05 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Deja Augustine wrote:


 Stewart Gordon wrote:
 

 Andy Friesen wrote:




<snip>

 If you're talking about how builtin language constructs map to phobos 
 library function calls, it's just a matter of the compiler creating 
 forward declarations of those functions and generating calls to them. 






<snip>

 Actually, the front-end takes care of that.


<snip>

I've just taken a look.  Some of the Phobos internal functions are 
indeed referenced in the front-end code that comes with DMD.  Like those 
for AA access.  Generally as genCfunc calls that take the function name 
as a string.

OTOH, other parts of internal aren't referenced at all, such as the 
contents of arraycat.d.  So obviously they're hooked up somewhere else, 
out of our sight.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Aug 10 2004
parent Deja Augustine <deja scratch-ware.net> writes:
Stewart Gordon wrote:


 Deja Augustine wrote:
 

 Stewart Gordon wrote:


 Andy Friesen wrote:




 
 <snip>
 

 If you're talking about how builtin language constructs map to 
 phobos library function calls, it's just a matter of the compiler 
 creating forward declarations of those functions and generating 
 calls to them. 






 
 <snip>
 

 Actually, the front-end takes care of that.


 
 <snip>
 
 I've just taken a look.  Some of the Phobos internal functions are 
 indeed referenced in the front-end code that comes with DMD.  Like those 
 for AA access.  Generally as genCfunc calls that take the function name 
 as a string.
 
 OTOH, other parts of internal aren't referenced at all, such as the 
 contents of arraycat.d.  So obviously they're hooked up somewhere else, 
 out of our sight.
 
 Stewart.
 


Things like actually calling functions from phobos.lib are done in the 
back-end along with other function calls.  However, the front-end 
handles ensuring that the necessary library calls are mapped in and can 
be used in your D code.  The contents of files such as arraycat.d should 
never be used directly in your D code and therefore require no forward 
declaration and no existance in the front-end.  Those functions will 
simply be called directly as needed by the back-end.
Aug 10 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:cer7tn$a6g$1 digitaldaemon.com...

 Obviously someone couldn't just plug the DMD front-end into the GCC
 back-end without anything in between.  Somebody had to write a
 middle-end.  And if only the DMD middle-end could be open source, it
 would speed up development a bit....


I put some of the middle-end into the open source part, toobj.c, that should
help. It specifies the layout of the vtbl[]'s, which is tricky to get right.
Aug 05 2004