I'm working on getting DMD to compile in Linux using GCC.  I've had to change quite a lot of stuff - differences in compilers, missing code, things like that.  I'll be giving a more detailed report later.

It's currently compiling all the objects, but I haven't tried linking them.  There's a lot of stub functions to write.

Cool!
It would have been great when you would have reported this before as I
also already have done some of this.
Jan



Burton Radons wrote:

> I'm working on getting DMD to compile in Linux using GCC.  I've had to change quite a lot of stuff - differences in compilers, missing code, things like that.  I'll be giving a more detailed report later.
>
> It's currently compiling all the objects, but I haven't tried linking them.  There's a lot of stub functions to write.

Jan Knepper 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.

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.


> Burton Radons wrote:
> 
>>I'm working on getting DMD to compile in Linux using GCC.  I've had to
>>change quite a lot of stuff - differences in compilers, missing code,
>>things like that.  I'll be giving a more detailed report later.
>>
>>It's currently compiling all the objects, but I haven't tried linking
>>them.  There's a lot of stub functions to write.

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.

> 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?
If you want to make if 'public' we might be able to setup a newsgroup or add
it to http://www.opend.org/

Jan

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

Burton Radons wrote:

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

Are you sure?
I am pretty sure the following header files were missing...
cc.h, cgcv.h, code.h, context.h, dt.h, el.h, global.h, id.h, oper.h, outbuf.h,
port.h, stringtable.h, type.h.

Most significant is id.h as I think it contains "class Id" with quite a few static members used throughout the code.

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

<g>

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

Are you just having a lot of time on your hands?

Jan

"Jan Knepper" <jan@smartsoft.cc> wrote in message news:3D3C3E84.D8F932DC@smartsoft.cc...
> Most significant is id.h as I think it contains "class Id" with quite a
few static
> members used throughout the code.

id.h and id.c are generated by the file idgen.c, which should be included with the source code.

Walter wrote:

> "Jan Knepper" <jan@smartsoft.cc> wrote in message news:3D3C3E84.D8F932DC@smartsoft.cc...
> > Most significant is id.h as I think it contains "class Id" with quite a
> few static
> > members used throughout the code.
>
> id.h and id.c are generated by the file idgen.c, which should be included with the source code.

Thanks!

Jan

Jan Knepper wrote:

> Burton Radons wrote:
> 
> 
>>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.
>>
> 
> Are you sure?
> I am pretty sure the following header files were missing...
> cc.h, cgcv.h, code.h, context.h, dt.h, el.h, global.h, id.h, oper.h, outbuf.h,
> port.h, stringtable.h, type.h.


I meant stringtable there.  The rest are for the backend, with a couple pieces that appear to have been moved to other files (global and outbuf).

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.  Not a large thing, but if your produced strings are nonsensical, you now know why.


> Most significant is id.h as I think it contains "class Id" with quite a few static
> members used throughout the code.


Walter noted that it's generated.  impcnvtab.c is also generated, from impcnvgen.c.


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


I would be willing to have an internal API that can be matched up with GCC, but I could only compromise with generating RTI, since producing this machine-specific code (the syntax is inspecific, but you need to know the machine and calling structure to use it) is not a great inconvenience and I'll have to move towards that eventually anyway.  For BrightD, OpenD, GLUE, or whatever you want to call it, converting D's node tree to GCC's is more your ideal, but for me it adds too much complexity.


>>>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.  :-)
> 
> Are you just having a lot of time on your hands?

At times.  Hello, world! is now working; that makes it about 0.1%. Walter, I found that the code:

    printf ("Hello, world!", "Foo foo foo!");

Was producing the most unexpected:

    printf ("Hello, world!", (wchar [] [12]) (wchar [12]) "Foo foo foo!");

I guess the code generator is assuming the parser knows what it's doing and is producing nonsense as a result.  I've previously clocked it as being the same as "(wchar *)".

Burton Radons wrote:

> > Are you sure?
> > I am pretty sure the following header files were missing...
> > cc.h, cgcv.h, code.h, context.h, dt.h, el.h, global.h, id.h, oper.h, outbuf.h,
> > port.h, stringtable.h, type.h.
>
> I meant stringtable there.  The rest are for the backend, with a couple pieces that appear to have been moved to other files (global and outbuf).
>
> 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.  Not a large thing, but if your produced strings are nonsensical, you now know why.

I think Walter will give you dchar.h...

> > Most significant is id.h as I think it contains "class Id" with quite a few static members used throughout the code.
> Walter noted that it's generated.  impcnvtab.c is also generated, from impcnvgen.c.

OK, let's check into that too!

> >>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.
> I would be willing to have an internal API that can be matched up with GCC, but I could only compromise with generating RTI, since producing this machine-specific code (the syntax is inspecific, but you need to know the machine and calling structure to use it) is not a great inconvenience and I'll have to move towards that eventually anyway.  For BrightD, OpenD, GLUE, or whatever you want to call it, converting D's node tree to GCC's is more your ideal, but for me it adds too much complexity.

OK, you're using the D-front-end to target a different architecture. Understood.

> > Are you just having a lot of time on your hands?
> At times.  Hello, world! is now working; that makes it about 0.1%.
> Walter, I found that the code:
>      printf ("Hello, world!", "Foo foo foo!");
> Was producing the most unexpected:
>      printf ("Hello, world!", (wchar [] [12]) (wchar [12]) "Foo foo foo!");
> I guess the code generator is assuming the parser knows what it's doing
> and is producing nonsense as a result.  I've previously clocked it as
> being the same as "(wchar *)".

<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