www.digitalmars.com         C & C++   DMDScript  

D.gnu - Any progress?

reply Jan Knepper <jan opend.org> writes:
Anyone doing anything???
I will be too busy until after the weekend...
Monday/Tuesday I will continue where I left off.
Jan
Aug 02 2002
next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Jan Knepper wrote:

 Anyone doing anything???
 I will be too busy until after the weekend...
 Monday/Tuesday I will continue where I left off.

Talking to me or Jonathon? My port is now compiling and using a little GC I wrote. It's type-aggressive, so it's faster at scanning and could do block allocation for class instances. Nothing to be proud of, it's the minimum I can do in the minimum of time. A full-blown D-specific GC's going to be a pretty meaty creature. But doing this and ironing out any problems now will be a good step towards getting there.
Aug 02 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
Actually, I was talking to any one involved in the GLUE layer for the D
front-end to GCC back-end, but I appreciate your response.

Did you also run into the problem with the /* */ comments broken over more
than one line like:

/*******************
 *
 *
 */

The D front-end would error on the * on the second line. This construction
however is being used in phobos quite a few times, so I guess the D
front-end should parse it.

Jan



Burton Radons wrote:

 Jan Knepper wrote:

 Anyone doing anything???
 I will be too busy until after the weekend...
 Monday/Tuesday I will continue where I left off.

Talking to me or Jonathon? My port is now compiling and using a little GC I wrote. It's type-aggressive, so it's faster at scanning and could do block allocation for class instances. Nothing to be proud of, it's the minimum I can do in the minimum of time. A full-blown D-specific GC's going to be a pretty meaty creature. But doing this and ironing out any problems now will be a good step towards getting there.

Aug 02 2002
next sibling parent reply "Andrew C. Oliver" <andy opend.org> writes:
I've made no progress as of yet.  I'm closing a deal.  This weekend my 
goal is to get it to create an executable... From there I'll start 
looking at what needs to be done from a lower level.

I'm really open to as much direction from you as possible on this.  I 
think you're knowledge and experience in this area should take the lead.

-Andy

Jan Knepper wrote:
 Actually, I was talking to any one involved in the GLUE layer for the D
 front-end to GCC back-end, but I appreciate your response.
 
 Did you also run into the problem with the /* */ comments broken over more
 than one line like:
 
 /*******************
  *
  *
  */
 
 The D front-end would error on the * on the second line. This construction
 however is being used in phobos quite a few times, so I guess the D
 front-end should parse it.
 
 Jan
 
 
 
 Burton Radons wrote:
 
 
Jan Knepper wrote:


Anyone doing anything???
I will be too busy until after the weekend...
Monday/Tuesday I will continue where I left off.

Talking to me or Jonathon? My port is now compiling and using a little GC I wrote. It's type-aggressive, so it's faster at scanning and could do block allocation for class instances. Nothing to be proud of, it's the minimum I can do in the minimum of time. A full-blown D-specific GC's going to be a pretty meaty creature. But doing this and ironing out any problems now will be a good step towards getting there.


Aug 02 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
"Andrew C. Oliver" wrote:

 I've made no progress as of yet.  I'm closing a deal.  This weekend my
 goal is to get it to create an executable... From there I'll start
 looking at what needs to be done from a lower level.

OK. Well, getting the build process integrated into the gcc build would be cool.
 I'm really open to as much direction from you as possible on this.  I think
 you're knowledge and experience in this area should take the lead.

Thanks, but it has been over 10 years since I wrote my C++ to C converter and over 13 years I wrote a compiler. Next week I will be getting into the GCC stuff in more detail to see how I can hook the two up. Jan
 -Andy

 Jan Knepper wrote:
 Actually, I was talking to any one involved in the GLUE layer for the D
 front-end to GCC back-end, but I appreciate your response.

 Did you also run into the problem with the /* */ comments broken over more
 than one line like:

 /*******************
  *
  *
  */

 The D front-end would error on the * on the second line. This construction
 however is being used in phobos quite a few times, so I guess the D
 front-end should parse it.

 Jan



 Burton Radons wrote:


Jan Knepper wrote:


Anyone doing anything???
I will be too busy until after the weekend...
Monday/Tuesday I will continue where I left off.

Talking to me or Jonathon? My port is now compiling and using a little GC I wrote. It's type-aggressive, so it's faster at scanning and could do block allocation for class instances. Nothing to be proud of, it's the minimum I can do in the minimum of time. A full-blown D-specific GC's going to be a pretty meaty creature. But doing this and ironing out any problems now will be a good step towards getting there.



Aug 02 2002
parent reply andy <acoliver apache.org> writes:
Jan Knepper wrote:
 "Andrew C. Oliver" wrote:
 
 
I've made no progress as of yet.  I'm closing a deal.  This weekend my
goal is to get it to create an executable... From there I'll start
looking at what needs to be done from a lower level.

OK. Well, getting the build process integrated into the gcc build would be cool.

Yes. I got it to *build*.... and theoretically it worked together. Just nothing really resulted from it...
 
I'm really open to as much direction from you as possible on this.  I think
you're knowledge and experience in this area should take the lead.

Thanks, but it has been over 10 years since I wrote my C++ to C converter and over 13 years I wrote a compiler. Next week I will be getting into the GCC stuff in more detail to see how I can hook the two up.

And its been like 3-4 years since my last serious effort in C/C++. (Which oddly enough was an NT service...long story...involved a mainframe ;-) )
 Jan
 
 
 
 
-Andy

Jan Knepper wrote:

Actually, I was talking to any one involved in the GLUE layer for the D
front-end to GCC back-end, but I appreciate your response.

Did you also run into the problem with the /* */ comments broken over more
than one line like:

/*******************
 *
 *
 */

The D front-end would error on the * on the second line. This construction
however is being used in phobos quite a few times, so I guess the D
front-end should parse it.

Jan



Burton Radons wrote:



Jan Knepper wrote:



Anyone doing anything???
I will be too busy until after the weekend...
Monday/Tuesday I will continue where I left off.

Talking to me or Jonathon? My port is now compiling and using a little GC I wrote. It's type-aggressive, so it's faster at scanning and could do block allocation for class instances. Nothing to be proud of, it's the minimum I can do in the minimum of time. A full-blown D-specific GC's going to be a pretty meaty creature. But doing this and ironing out any problems now will be a good step towards getting there.




Aug 02 2002
parent Jan Knepper <jan smartsoft.cc> writes:
 OK. Well, getting the build process integrated into the gcc build would be
cool.

Just nothing really resulted from it...

So, if I understand you well you already got the .in files done? If so: Cool!
 Thanks, but it has been over 10 years since I wrote my C++ to C converter and
 over 13 years I wrote a compiler.
 Next week I will be getting into the GCC stuff in more detail to see how I can
 hook the two up.

(Which oddly enough was an NT service...long story...involved a mainframe ;-) )

That has been about 1 second for me I guess... <g> I guess I have been using C++ for too long by now... <g> Jan
Aug 02 2002
prev sibling next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Fri, 02 Aug 2002 10:36:34 -0400 Jan Knepper <jan smartsoft.cc> wrote:

 Did you also run into the problem with the /* */ comments broken over more
 than one line like:
 
 /*******************
  *
  *
  */
 
 The D front-end would error on the * on the second line. This construction
 however is being used in phobos quite a few times, so I guess the D
 front-end should parse it.

It's an old DMD bug. I don't remember the exact reason (which I've figured out when I first came over it), but sometimes it complains on such comments, sometimes it isn't - I have such a comment in WinD and it works fine. It has something to do with whitespace as far as I remember.
Aug 02 2002
parent Jan Knepper <jan smartsoft.cc> writes:
Pavel Minayev wrote:

 On Fri, 02 Aug 2002 10:36:34 -0400 Jan Knepper <jan smartsoft.cc> wrote:

 Did you also run into the problem with the /* */ comments broken over more
 than one line like:

 /*******************
  *
  *
  */

 The D front-end would error on the * on the second line. This construction
 however is being used in phobos quite a few times, so I guess the D
 front-end should parse it.

It's an old DMD bug. I don't remember the exact reason (which I've figured out when I first came over it), but sometimes it complains on such comments, sometimes it isn't - I have such a comment in WinD and it works fine. It has something to do with whitespace as far as I remember.

No, it has something to do with line counting and and end of line not being processed properly. (I think). I fixed it in the D front-end which is available. Jan
Aug 02 2002
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Jan Knepper wrote:

 Actually, I was talking to any one involved in the GLUE layer for the D
 front-end to GCC back-end, but I appreciate your response.
 
 Did you also run into the problem with the /* */ comments broken over more
 than one line like:
 
 /*******************
  *
  *
  */
 
 The D front-end would error on the * on the second line. This construction
 however is being used in phobos quite a few times, so I guess the D
 front-end should parse it.

Yes, it's mistakenly perceiving the "*\n" sequence as being the end of the comment. Just add a check that it really aborted the loop on a "/". I haven't the slightest idea why that code works in DOS; I can only imagine that the '\n' was never being seen.
Aug 02 2002
next sibling parent Jan Knepper <jan smartsoft.cc> writes:
Do you have any more specific's on the char / wchar_t mixup?
I guess under certain circumstances the parse treats a "bla bla" as char and
under others as wchar_t.
Jan



Burton Radons wrote:

 Jan Knepper wrote:

 Actually, I was talking to any one involved in the GLUE layer for the D
 front-end to GCC back-end, but I appreciate your response.

 Did you also run into the problem with the /* */ comments broken over more
 than one line like:

 /*******************
  *
  *
  */

 The D front-end would error on the * on the second line. This construction
 however is being used in phobos quite a few times, so I guess the D
 front-end should parse it.

Yes, it's mistakenly perceiving the "*\n" sequence as being the end of the comment. Just add a check that it really aborted the loop on a "/". I haven't the slightest idea why that code works in DOS; I can only imagine that the '\n' was never being seen.

Aug 02 2002
prev sibling parent Burton Radons <loth users.sourceforge.net> writes:
Burton Radons wrote:

 Jan Knepper wrote:
 
 Actually, I was talking to any one involved in the GLUE layer for the D
 front-end to GCC back-end, but I appreciate your response.

 Did you also run into the problem with the /* */ comments broken over 
 more
 than one line like:

 /*******************
  *
  *
  */

 The D front-end would error on the * on the second line. This 
 construction
 however is being used in phobos quite a few times, so I guess the D
 front-end should parse it.

Yes, it's mistakenly perceiving the "*\n" sequence as being the end of the comment. Just add a check that it really aborted the loop on a "/". I haven't the slightest idea why that code works in DOS; I can only imagine that the '\n' was never being seen.

Wait, I get it - DOS uses "\r\n" sequences, so it was never seeing a "*\n" pattern. This bug would show up if your tool was using sensible line endings and disappear if it then used DOS.
Aug 02 2002
prev sibling parent reply Jonathan Andrew <jon ece.arizona.edu> writes:
Jan Knepper wrote:
 Anyone doing anything???
 I will be too busy until after the weekend...
 Monday/Tuesday I will continue where I left off.
 Jan
 

I'm trying to figure out the gcc stuff, For the sake of interfacing, it might be interesting to output whatever the D front end uses as an intermediary representation to a file. -Jon
Aug 02 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
That's a great thing that can be done with the current wrapper
functions.
Look for the use of __DMCSTUB in the .cpp files in ~/jak and you will
find all the stubs.

Jan



Jonathan Andrew wrote:

 Jan Knepper wrote:
 Anyone doing anything???
 I will be too busy until after the weekend...
 Monday/Tuesday I will continue where I left off.
 Jan

I'm trying to figure out the gcc stuff, For the sake of interfacing, it might be interesting to output whatever the D front end uses as an intermediary representation to a file. -Jon

Aug 02 2002
parent reply Jonathan Andrew <jon ece.arizona.edu> writes:
Jan Knepper wrote:
 That's a great thing that can be done with the current wrapper
 functions.
 Look for the use of __DMCSTUB in the .cpp files in ~/jak and you will
 find all the stubs.
 
 Jan
 

I'm guessing genobjfile is the most important one for this, but I still have to examine the front end source some more and try to understand it better. I'm also getting some strange compile errors when I try to use the front end to parse code. I will try and hunt some of these down, as the same code compiled fine under windows. Finally, I think I might try and write the inifile function, unless it's already been done by someone else. -Jon
Aug 02 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
Jonathan Andrew wrote:

 Jan Knepper wrote:
 That's a great thing that can be done with the current wrapper
 functions.
 Look for the use of __DMCSTUB in the .cpp files in ~/jak and you will
 find all the stubs.

 Jan

I'm guessing genobjfile is the most important one for this, but I still have to examine the front end source some more and try to understand it better.

That seems to be the main entry to the back-end.
 I'm also getting some strange compile errors when I try to use the front
 end to parse code. I will try and hunt some of these down, as the same
 code compiled fine under windows.

What kind of errors? Can you post them?
 Finally, I think I might try and write the inifile function, unless it's
 already been done by someone else.

Not that I am aware of. It might be good if we had a subgroup here probably D.gnu.work or something like that where people could drop a note when they start on something. Any one on this? Jan
Aug 02 2002
parent reply Jonathan Andrew <jon ece.arizona.edu> writes:
I'm also getting some strange compile errors when I try to use the front
end to parse code. I will try and hunt some of these down, as the same
code compiled fine under windows.

What kind of errors? Can you post them?

The only one I can think of right now is when I try to import stdio for a simple "hello world" program, it gives me "stdio.d(75): cannot implicitly convert wchar[135034216] to char[]" Also, the -I flag doesn't appear to work, I may just be doing something wrong though. Right now I have to move all my source files to the dmd directory to compile.
Finally, I think I might try and write the inifile function, unless it's
already been done by someone else.

Not that I am aware of. It might be good if we had a subgroup here probably D.gnu.work or something like that where people could drop a note when they start on something. Any one on this?

I think that's a good idea. -Jon
Aug 02 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
Jonathan Andrew wrote:

I'm also getting some strange compile errors when I try to use the front
end to parse code. I will try and hunt some of these down, as the same
code compiled fine under windows.

What kind of errors? Can you post them?

The only one I can think of right now is when I try to import stdio for a simple "hello world" program, it gives me "stdio.d(75): cannot implicitly convert wchar[135034216] to char[]"

OK, I know about that one. It think it has to do with char/wchar_t processing. Burton Radons has fixed this I think, but I figured I will wait until Walter posts the next D front-end...
 Also, the -I flag doesn't appear to work, I may just be doing something
 wrong though. Right now I have to move all my source files to the dmd
 directory to compile.

This probably has just to do with checking for \ instead of for / on Unix.
Finally, I think I might try and write the inifile function, unless it's
already been done by someone else.

It might be good if we had a subgroup here probably D.gnu.work or something like that where people could drop a note when they start on something. Any one on this?


Anyone else? Jan
Aug 02 2002
next sibling parent reply Jan Knepper <jan smartsoft.cc> writes:
 Also, the -I flag doesn't appear to work, I may just be doing something
 wrong though. Right now I have to move all my source files to the dmd
 directory to compile.

This probably has just to do with checking for \ instead of for / on Unix.

Hmmm, this seems to be implemented! Are you sure you are using the latest source and in 'linux' defined in your compile? Jan
Aug 02 2002
parent reply Jonathan Andrew <jon ece.arizona.edu> writes:
Jan Knepper wrote:
Also, the -I flag doesn't appear to work, I may just be doing something
wrong though. Right now I have to move all my source files to the dmd
directory to compile.

This probably has just to do with checking for \ instead of for / on Unix.

Hmmm, this seems to be implemented! Are you sure you are using the latest source and in 'linux' defined in your compile? Jan

Hmm, I didn't know I needed to define linux, where do I do this? -Jon
Aug 02 2002
parent Jan Knepper <jan smartsoft.cc> writes:
g++ -Dlinux
In other words the compiler command line.
The latest Makefile should do it for you.

Jan



Jonathan Andrew wrote:

 Jan Knepper wrote:
Also, the -I flag doesn't appear to work, I may just be doing something
wrong though. Right now I have to move all my source files to the dmd
directory to compile.

This probably has just to do with checking for \ instead of for / on Unix.

Hmmm, this seems to be implemented! Are you sure you are using the latest source and in 'linux' defined in your compile? Jan

Hmm, I didn't know I needed to define linux, where do I do this? -Jon

Aug 02 2002
prev sibling parent Burton Radons <loth users.sourceforge.net> writes:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Jan Knepper wrote:

 Jonathan Andrew wrote:
 
 
I'm also getting some strange compile errors when I try to use the front
end to parse code. I will try and hunt some of these down, as the same
code compiled fine under windows.

What kind of errors? Can you post them?

a simple "hello world" program, it gives me "stdio.d(75): cannot implicitly convert wchar[135034216] to char[]"

OK, I know about that one. It think it has to do with char/wchar_t processing. Burton Radons has fixed this I think, but I figured I will wait until Walter posts the next D front-end...

I responded with details to Walter earlier: In lexer.c search for "case '\\':" and the StringConstant functions. Also, there are a couple uses of writeword where writedchar is intended, and a couple "/ 2" snippets should be "/ sizeof (wchar_t)", or perhaps "dchar". Also charConstant, but that's dead code anyway. Sorry that I can't be more specific, but I passed the file through indent. It's all in lexer.c; grepping for these and putting in some diagnostics and tests should shake out the problems. All strings use wchar_t before being more specifically typed, so a Hello, World! won't be possible at all until that's amended.
Also, the -I flag doesn't appear to work, I may just be doing something
wrong though. Right now I have to move all my source files to the dmd
directory to compile.

This probably has just to do with checking for \ instead of for / on Unix.

It's a buggy argument anyway - it only pays attention to the last instance of -I.
Finally, I think I might try and write the inifile function, unless it's
already been done by someone else.




I've attached my implementation if you want to use that. "fail_at" is similar to "error", except that it stops program execution.
Aug 02 2002