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

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

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.

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

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.

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

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.

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

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.

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