D.gnu - Any progress?
- Jan Knepper <jan opend.org> Aug 02 2002
- Burton Radons <loth users.sourceforge.net> Aug 02 2002
- Jan Knepper <jan smartsoft.cc> Aug 02 2002
- "Andrew C. Oliver" <andy opend.org> Aug 02 2002
- Jan Knepper <jan smartsoft.cc> Aug 02 2002
- andy <acoliver apache.org> Aug 02 2002
- Jan Knepper <jan smartsoft.cc> Aug 02 2002
- Pavel Minayev <evilone omen.ru> Aug 02 2002
- Jan Knepper <jan smartsoft.cc> Aug 02 2002
- Burton Radons <loth users.sourceforge.net> Aug 02 2002
- Jan Knepper <jan smartsoft.cc> Aug 02 2002
- Burton Radons <loth users.sourceforge.net> Aug 02 2002
- Jonathan Andrew <jon ece.arizona.edu> Aug 02 2002
- Jan Knepper <jan smartsoft.cc> Aug 02 2002
- Jonathan Andrew <jon ece.arizona.edu> Aug 02 2002
- Jan Knepper <jan smartsoft.cc> Aug 02 2002
- Jonathan Andrew <jon ece.arizona.edu> Aug 02 2002
- Jan Knepper <jan smartsoft.cc> Aug 02 2002
- Jan Knepper <jan smartsoft.cc> Aug 02 2002
- Jonathan Andrew <jon ece.arizona.edu> Aug 02 2002
- Jan Knepper <jan smartsoft.cc> Aug 02 2002
- Burton Radons <loth users.sourceforge.net> Aug 02 2002
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
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
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
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
"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
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> 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
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
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
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
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 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 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
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
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
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
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
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
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
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
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
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