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.

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

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

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.

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

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

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

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.

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.