Digital Mars - D.gnu - Any progress?

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → "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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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