"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D3D3B83.60203@users.sourceforge.net...
> dchar is another one (I don't know what header file it's from), and a source of a small problem - the code assumes wchar_t is two bytes at several points.

Those dependencies are bugs, could you send me the file/line of them?

dchar is more or less my failed attempt at a unified char/wchar/mbcs header.

> <g>
> I guess that is part of the deal with a compiler that is in progress.
> I don't think there is anything else the code generator can do. It is being called by
> the front-end and lives on data provided by the front-end. The parse should deliver the
> correct 'tree' structure to the code generator to generate the code from.
> 
> Jan
> 

Is there any information about the output that the D front end creates?
I know the gcc tree structure is woefully undocumented. Also, if
anybody has gotten the D front end to compile under Linux,
any chance of posting a zip or tarball of the ported code on
opend.org so others (like me) can play around with it without
reinventing the wheel? (albeit a complicated wheel.)

Thanks,
-Jon

Jonathan Andrew wrote:

> > <g>
> > I guess that is part of the deal with a compiler that is in progress.
> > I don't think there is anything else the code generator can do. It is being called by
> > the front-end and lives on data provided by the front-end. The parse should deliver the
> > correct 'tree' structure to the code generator to generate the code from.
>
> Is there any information about the output that the D front end creates?

It's called Walter Bright <g>

> I know the gcc tree structure is woefully undocumented. Also, if
> anybody has gotten the D front end to compile under Linux,
> any chance of posting a zip or tarball of the ported code on
> opend.org so others (like me) can play around with it without
> reinventing the wheel? (albeit a complicated wheel.)

I am working on that and as soon as I have it all done (just compile I mean) it indeed will appear on opend.org. Actually it will be in CVS and a HEAD tarball will be created daily.

Jan

Jan Knepper wrote:
> 
> I am working on that and as soon as I have it all done (just compile I mean) it indeed will
> appear on opend.org. Actually it will be in CVS and a HEAD tarball will be created daily.
> 
> Jan
> 

Fantastic! I'm really looking forward to it.

-Jon

Walter wrote:

> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:3D3D3B83.60203@users.sourceforge.net...
> 
>>dchar is another one (I don't know what header file it's from), and a
>>source of a small problem - the code assumes wchar_t is two bytes at
>>several points.
> 
> Those dependencies are bugs, could you send me the file/line of them?


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.


> dchar is more or less my failed attempt at a unified char/wchar/mbcs header.

I'd assumed it was a failed attempt at UTF-8, actually.  :-)

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D3C378A.3050508@users.sourceforge.net...
> Jan Knepper wrote:
>
> > Burton Radons wrote:
> >
> >
> >>>It would have been great when you would have reported this before as I also already have done some of this.
> >>>
> >>Oh, it just took this night anyway, unless if you have other code.  It's (DMD, that is) now compiling a test properly and is throwing an unimplemented on Module::genobjfile, which is supposed to do everything in the backend.  So everything past that point is backend.
> >
> > Well, it only took me an hour or two... So it's not that bad...
> > One of the cute things to know is that Walter seems to use a compiler
trick
> > in DMC++ where he includes total.h as first header for every source
file.
>
>
> Ah, I was wondering why I needed to add so many includes.  The only frontend code that's missing was stringbuffer.
>
>
> >>I'm not interested in working on BrightD, so I'm now going ahead with writing my own backend.  I'll put down lots of documentation as I figure out things and make a zip sometime.
> >>
> >
> > You mean, you are not interested in the GLUE layer for the D-front-end
and
> > the GCC-back-end?
> > What are you writing a back-end for?
>
>
> Entertainment, education.  Also, using GNU as a backend doesn't fit in my long-term plan of a compiler-in-a-library.  I want to eventually convert DMD, with the backend, into D, and allow getting the parse tree using a single method call.  I'd convert it to D now but I'm sick of Windows.
>
>
> > If you want to make if 'public' we might be able to setup a newsgroup or
add
> > it to http://www.opend.org/
>
> A bit premature but thanks for the offer.
>
> The code:
>
>      int main ()
>      {
>          return 45;
>      }
>
> Now creates a correct object file.  I'm 0.01% done.  :-)
>


You might want to consider Gnu lightning or cgen (http://sources.redhat.com/cgen/) as starting points. Althought that will be less educational!

Jonathan Andrew wrote:

> 
>> <g>
>> I guess that is part of the deal with a compiler that is in progress.
>> I don't think there is anything else the code generator can do. It is being called by
>> the front-end and lives on data provided by the front-end. The parse should deliver the
>> correct 'tree' structure to the code generator to generate the code from.
> 
> Is there any information about the output that the D front end creates?


It's not too complex - it's a bunch of fully formed structs, unlike GCC's generic LISPish.  But I'm adding header documentation as I go.

> I know the gcc tree structure is woefully undocumented. Also, if
> anybody has gotten the D front end to compile under Linux,
> any chance of posting a zip or tarball of the ported code on
> opend.org so others (like me) can play around with it without
> reinventing the wheel? (albeit a complicated wheel.)

Oh, sure:

http://amateur-scrolls.sourceforge.net/old/dli-0.0.1.tar.gz

My additions, outside of fixing it to compile and behave properly in Linux, is mostly restrained to "machine.h" and "machine-i386.cc".  If you strip off the backend entirely, the main thing you'll need to fix up is the stringtable implementation, which I just stubbed as a linear list.

Burton Radons wrote:

> It's not too complex - it's a bunch of fully formed structs, unlike GCC's generic LISPish.  But I'm adding header documentation as I go.
> 

This is one thing that I was unsure of, from what I've read, the RTL
is LISPish, but before that comes a syntax tree, which should just
be a bunch of tree structs, right? Maybe I am confused on this.

> 
> Oh, sure:
> 
> http://amateur-scrolls.sourceforge.net/old/dli-0.0.1.tar.gz
> 
> My additions, outside of fixing it to compile and behave properly in Linux, is mostly restrained to "machine.h" and "machine-i386.cc".  If you strip off the backend entirely, the main thing you'll need to fix up is the stringtable implementation, which I just stubbed as a linear list.

Thanks!

-Jon

Burton Radons wrote:

> > Well, it only took me an hour or two... So it's not that bad...
> > One of the cute things to know is that Walter seems to use a compiler trick
> > in DMC++ where he includes total.h as first header for every source file.
> Ah, I was wondering why I needed to add so many includes.  The only frontend code that's missing was stringbuffer.

You can do the same with GCC.
I do not know which compiler you are using. Just use as compiler switch -include
total.h and safe yourself a lot of changes!

Jan

Status update.  The last few days I've been looking into various intermediate representation systems.  I'll be going to some variety in the future, but for now I decided to stick with the crappy stack-based code it's currently producing.  I was actually interested in LCC's system, but when I looked at the produced code I saw that it was really horrible.  This is good, as it's comparable to GCC in the computer language shootout, so producing cruddy code is not a death knell by any means, although it has a bad worst-case.

All integer arithmetic is done, and some of floating-point.  Locals are in and I'm just now working on arrays and my next hurdle is to start to port, compile and use Phobos.