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.

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 C++, C#, VB.NET, ASP.NET, etc. 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 
 C++, C#, VB.NET, ASP.NET, etc.

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:

 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.

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:


 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. 



 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).

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. 

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:


 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. 



 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).

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. 

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:


 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. 



 Actually, the front-end takes care of that.

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