www.digitalmars.com         C & C++   DMDScript  

D.gnu - gdmd on tcc?

reply Robert Jones <robertjones21 HotPOP.com> writes:
Has anyone considered getting the d frontend to work with the Tiny C 
compiler for Gnu/Linux?
Mar 13 2004
next sibling parent J C Calvarese <jcc7 cox.net> writes:
Robert Jones wrote:

 Has anyone considered getting the d frontend to work with the Tiny C 
 compiler for Gnu/Linux?


The frontend is written in C++.

Wouldn't it take considerable effort just to convert it to C?

-- 
Justin
http://jcc_7.tripod.com/d/
Mar 13 2004
prev sibling next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Robert Jones schrieb:

 Has anyone considered getting the d frontend to work with the Tiny C 
 compiler for Gnu/Linux?


This doesn't make sense, since the DigitalMars back end is not worse and 
extremely fast.

What probably does make sense just to get an "alternative" working 
compiler, is to reintegrate Burton's back-end from DLI with DMD code. 
The back end is very simplistic and should be roughly the same quality 
as TCC.

-eye
Mar 14 2004
prev sibling next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
On Sat, 13 Mar 2004 23:48:20 -0500, Robert Jones
<robertjones21 HotPOP.com> wrote:


Has anyone considered getting the d frontend to work with the Tiny C 
compiler for Gnu/Linux?


That would be interesting to try. Without more backends for Tiny C
it seems like it would mostly just be for fun, though. The D
compiler is pretty small already (phobos is 600K, dmd is 950K).

-Ben
Mar 14 2004
prev sibling next sibling parent reply resistor mac.com writes:
I imagine it would be possible, but I don't really see what it would benefit.
Probably the major reason for porting to GCC is the portability: GCC runs on
lots of OS-architecture pairs, and even more by cross-compilation.

Of course, if some adventurous soul wants to do it, far be it from me to tell
them not to.

Owen Anderson

In article <c30o58$21au$1 digitaldaemon.com>, Robert Jones says...

Has anyone considered getting the d frontend to work with the Tiny C 
compiler for Gnu/Linux?
Mar 15 2004
parent reply Robert Jones <robertjones21 HotPOP.com> writes:
resistor mac.com wrote:

 I imagine it would be possible, but I don't really see what it would benefit.
 Probably the major reason for porting to GCC is the portability: GCC runs on
 lots of OS-architecture pairs, and even more by cross-compilation.
 
 Of course, if some adventurous soul wants to do it, far be it from me to tell
 them not to.
 
 Owen Anderson
 
 In article <c30o58$21au$1 digitaldaemon.com>, Robert Jones says...
 

Has anyone considered getting the d frontend to work with the Tiny C 
compiler for Gnu/Linux?


 
 
 


 From what I read, although it is currently for Gnu/Linux at this time, 
the developer has plans to port it to other systems. In the makefile 
there is commands for compiling for a Win32 version. One would only have 
to rewrite some code and write code for asm on say PPC for port to a 
Mac. TCC is also alot smaller than GCC and more ISO C99 compiliant, as 
far as the frontend being written in C++, wrap it. It's something that 
should be looked into, giving GCC's size and complexity.
Mar 15 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
Robert Jones schrieb:


  From what I read, although it is currently for Gnu/Linux at this time, 
 the developer has plans to port it to other systems. In the makefile 
 there is commands for compiling for a Win32 version. One would only have 
 to rewrite some code and write code for asm on say PPC for port to a 
 Mac. TCC is also alot smaller than GCC and more ISO C99 compiliant, as 
 far as the frontend being written in C++, wrap it. It's something that 
 should be looked into, giving GCC's size and complexity.


Urr, sorry, why would one need to wrap the C++ frontend? One would use 
G++ to compile the complete compiler anyway. The back-end will need 
adaptation anyway if someone were to do it.

And while talking about that, you should take a look at DLI back-end. It 
is just as simple, integrates wonderfully with DMC. It can be adapted to 
Windows by "only" adding another output format and adjuting minor 
things. Then it can be adapted to PPC by "only" changing the generated 
asm (read: by throwing the back-end away, since there is nothing else in 
such simpistic back-ends). Sure, it would be feasible, but such 
back-ends exist en masse, generate slow code, and have besides their 
speed and simplicity NO REAL VALUE. The only optimisation which TCC 
makes is strength reduction, otherwise code is completely unoptimised. 
The same would roughly be true for DLI. However, TCC is an interesting 
*example* for compiler writers how to do it in a simple way.

The advantages of a real, high-complexity back end, such as DigitalMars, 
GCC or OpenWatcom:
- if multiple platforms are supported, a very minor further effort is 
requiered to support in compiler. With GCC this opens the door to world 
domination;
- one-shot support for debugging information and debuggers on all 
platforms. Do you know that debugging-related code differs to more than 
80% for each platform?
- the compiler takes advantage of optimizer improvements made in the 
back-end;
- interoperability with many othet languages such as Pascal and Ada (GCC);

Please also note that GCC version of D would not suffer on slow compiler 
speed, because our parser is fast. ;)

There are other interesting targets beyond GCC, such as ANDF and 
possibly OW (if they dig out their long buried PPC back-end), as well as 
configurable C. ;) It would also be ineteresting to hear of other 
potentially interesting targets, provided there is any merit.

-eye
Mar 15 2004
prev sibling parent reply Olaf Rogalsky <rogalsky physik.uni-erlangen.de> writes:
Robert Jones wrote:

 
 Has anyone considered getting the d frontend to work with the Tiny C
 compiler for Gnu/Linux?


Another choice would be lcc. Lcc is a tiny and portable and very well
documented C compiler, which has backends to quite a few architectures
and OS'es. But to decide, wether this is feasable, one must compare
the intermediate language of Walters frontend to that of lcc. The main
problem with all those alternative (non GCC) approaches is, that 
they don't provide optimizing backends, which becomes more and more
essential with modern processors.

Olaf

-- 
+-------------------------------------------------------------------+
I Dr. rer. nat. Olaf Rogalsky     Institut fuer Theoretische Physik I
I                                 Universitaet Erlangen-Nuernberg   I
I Tel.: 09131 8528440             Staudtstr. 7 B3                   I
I Fax.: 09131 8528444             D-91058 Erlangen                  I
| rogalsky theorie1.physik.uni-erlangen.de                          I
+-------------------------------------------------------------------+
Mar 15 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Olaf Rogalsky schrieb:


 Another choice would be lcc. Lcc is a tiny and portable and very well
 documented C compiler, which has backends to quite a few architectures
 and OS'es. But to decide, wether this is feasable, one must compare
 the intermediate language of Walters frontend to that of lcc. The main
 problem with all those alternative (non GCC) approaches is, that 
 they don't provide optimizing backends, which becomes more and more
 essential with modern processors.


I was thinking about that, and came to exactly that conclusion, that LCC 
makes a more or less interesting target for many machines. However, the 
lack of optimistion, and the lack of C++ compiler make it really limited.

I would believe porting to whatever C compler back-end should be no 
problem, since the structures output by DMD front-end can be transformed 
into C, just not ANSI C but using compiler specific extensions. There is 
a built-in dumper which does something like that. Haven't tried it yet 
though. My idea was exactly that: to output C with compiler-specific 
extensions. This can very easily be adapted to GCC and even TCC, and 
there would be a fairly working cross-platform compiler, just that debug 
information would carry translation artifacts.

-eye
Mar 15 2004
parent reply Olaf Rogalsky <rogalsky physik.uni-erlangen.de> writes:
Ilya Minkov wrote:

 
 Olaf Rogalsky schrieb:
 I would believe porting to whatever C compler back-end should be no
 problem, since the structures output by DMD front-end can be transformed
 into C, just not ANSI C but using compiler specific extensions. There is
 a built-in dumper which does something like that. Haven't tried it yet
 though. My idea was exactly that: to output C with compiler-specific
 extensions. This can very easily be adapted to GCC and even TCC, and
 there would be a fairly working cross-platform compiler, just that debug
 information would carry translation artifacts.


Well, I don't like the idea of C beeing the backends language very much.
Its too frustrating to see the translation process
D->IL->C->IL->ASSEMBLER->LINKEDITOR->EXE :-(
But on the other hand, one could make use of the wide availibilty of
C to get a portable D compiler.


Olaf

-- 
+-------------------------------------------------------------------+
I Dr. rer. nat. Olaf Rogalsky     Institut fuer Theoretische Physik I
I                                 Universitaet Erlangen-Nuernberg   I
I Tel.: 09131 8528440             Staudtstr. 7 B3                   I
I Fax.: 09131 8528444             D-91058 Erlangen                  I
| rogalsky theorie1.physik.uni-erlangen.de                          I
+-------------------------------------------------------------------+
Mar 16 2004
parent reply KTC <KTC_member pathlink.com> writes:
Olaf Rogalsky says...

Well, I don't like the idea of C beeing the backends language very much.
Its too frustrating to see the translation process
D->IL->C->IL->ASSEMBLER->LINKEDITOR->EXE :-(
But on the other hand, one could make use of the wide availibilty of
C to get a portable D compiler.


It's not exactly an ideal way to generate an app but it's the best way for one
to get a compiler for a language on as many platform as possible. After you get
it on lots of platform and people using it, then one can start thinking about
native compiler on the different platform....

KTC
Mar 16 2004
next sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
KTC wrote:

 Olaf Rogalsky says...
 

Well, I don't like the idea of C beeing the backends language very much.
Its too frustrating to see the translation process
D->IL->C->IL->ASSEMBLER->LINKEDITOR->EXE :-(
But on the other hand, one could make use of the wide availibilty of
C to get a portable D compiler.


 It's not exactly an ideal way to generate an app but it's the best way for one
 to get a compiler for a language on as many platform as possible. After you get
 it on lots of platform and people using it, then one can start thinking about
 native compiler on the different platform....
 KTC
 


I remember that Algol60 had a "bootstrap compiler" which implemented 
Algol in a subset of itself, so to port it only the subset of the 
language needed to be ported.  This was used to compile the bootstrap 
compiler which was used to compile the full compiler.
What would be a good minimal subset of D?  (Clearly implementing ASM 
sections would work, but that fails the test of "good".)
Mar 16 2004
prev sibling parent reply resistor mac.com writes:
It's only "best" in the sense of works on just about everything.  It's a pretty
widely acknowledged fact 
that the easiest way to get a backend that compiles or cross-compiles for a
ridiculous number of 
platforms/architectures AND is still capable of generating useable code
(performace, debugging, etc.) is 
through GCC.

Building a D -> C -> C Compiler system would certainly be possible (someone else
was actually 
working on it I believe), but it is NOT the best way to spread the language.
Such a system would be 
hellish to use for development, and would mostly only be useful for compilation
of projects developed 
on systems that support DMD.

Porting to GCC affords both a long list of supported systems AND the features of
a modern compiler.  
Hence, I am much more inclined to say that GCC is the much better way of
extending the reach to other 
systems, and that a C-dumping implementation should only be necessary/used for
obscure (or perhaps 
embedded) systems that GCC cannot or does not support.  I mean, I happen to know
that with a GCC 
backend I could compile D programs that would run on my graphing calculator!  I
don't think GCC's 
system list is a problem. ;-)

Owen

In article <c376ln$n7u$1 digitaldaemon.com>, KTC says...

Olaf Rogalsky says...

Well, I don't like the idea of C beeing the backends language very much.
Its too frustrating to see the translation process
D->IL->C->IL->ASSEMBLER->LINKEDITOR->EXE :-(
But on the other hand, one could make use of the wide availibilty of
C to get a portable D compiler.


It's not exactly an ideal way to generate an app but it's the best way for one
to get a compiler for a language on as many platform as possible. After you get
it on lots of platform and people using it, then one can start thinking about
native compiler on the different platform....

KTC
Mar 16 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
resistor mac.com schrieb:

 It's only "best" in the sense of works on just about everything.  It's a pretty
 widely acknowledged fact 
 that the easiest way to get a backend that compiles or cross-compiles for a
 ridiculous number of 
 platforms/architectures AND is still capable of generating useable code
 (performace, debugging, etc.) is 
 through GCC.


No, not the easiest.


 Building a D -> C -> C Compiler system would certainly be possible (someone
else
 was actually 
 working on it I believe), but it is NOT the best way to spread the language.
 Such a system would be 
 hellish to use for development, and would mostly only be useful for compilation
 of projects developed 
 on systems that support DMD.


No, noone has been workiing, because this someone didn't have time even 
to read through the whole source. :> And this someone would more gladly 
help on GCC based compiler than hack something alone.

For development, it could actually be not that bad. It would be 
outputting "preprocessed" C, so that the compiler would be able to keep 
track of files and lines of D source both in error messages and debug 
information. It would also compile faster than normal C, due to lack of 
header includes. It would also allow to use another compiler than GCC to 
compile yet much faster. It could automatically call the target compiler 
and convert the command line. Just there would be some weird naming in 
debug information, but it can be resolved somehow.

-eye
Mar 17 2004
parent reply resistor mac.com writes:
In article <c3agqd$dpr$1 digitaldaemon.com>, Ilya Minkov says...

For development, it could actually be not that bad. It would be 
outputting "preprocessed" C, so that the compiler would be able to keep 
track of files and lines of D source both in error messages and debug 
information. It would also compile faster than normal C, due to lack of 
header includes. It would also allow to use another compiler than GCC to 
compile yet much faster. It could automatically call the target compiler 
and convert the command line. Just there would be some weird naming in 
debug information, but it can be resolved somehow.


I don't understand how you'd be able to track back to a D file and line number
from errors thrown in 
the compiled C code.  If it failed, you'd be getting C errors, which could be
traced back to the C 
dumped files but not the D files.  The same goes for debugging: you could debug
against the C files 
but not the D files.  Definitely a suboptimal at best way of developing.  If you
have a way to get around 
either or both problems, please enlighten me.

Also, when I said "easiest" I meant in a pros vs. cons sense.  GCC probably is
harder to code than a C 
dumper, but it also provides a large offset in terms of benefits.

C Dumper Pros:
Fast compile
Absolute maximum platform support
Possibly easier to write

C Dumper Cons:
Easier to break (non-standard compilers, etc)
Limited optimization (high-level optimization is lost in the C dumping)
Difficulties in tracing errors
Nigh-impossibility of debugging

GCC Pros:
Most widely used compiler (easier to get people to accept)
Actively developed but stable enough to rely on
Good and improving optimization support (cf. GENERIC/GIMPLE)
Wide (not infinite) platform support
GNU Debugger support
Direct D compilation makes error tracing much easier

GCC Cons:
Much harder to code
Potentially slower (though should improve as the compiler itself improves)
Platform list is not infinite
Mar 17 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
resistor mac.com schrieb:

 I don't understand how you'd be able to track back to a D file and line number
 from errors thrown in 
 the compiled C code.  If it failed, you'd be getting C errors, which could be
 traced back to the C 
 dumped files but not the D files.  The same goes for debugging: you could debug
 against the C files 
 but not the D files.  Definitely a suboptimal at best way of developing.  If
you
 have a way to get around 
 either or both problems, please enlighten me.


Running a separate preprocessor on a C file spit out a file with a by 
convention different extension. This file contains #file and #line 
directives to be able to track C errors and debug information to the 
original source. These can be sprinkled in so that these point to the 
original D source. It is mostly possible to retain D semantics in C, 
except for names which get mangled. Some locals would be moved in 
structs in rare cases etc. It might be possible to match C++ compilers' 
mangling scheme and allow thus even to view unmangled names while 
debugging, but this would probably go too far.


 Also, when I said "easiest" I meant in a pros vs. cons sense.  GCC probably is
 harder to code than a C 
 dumper, but it also provides a large offset in terms of benefits.


OK. As i said, if i get out of my debts, i'd more gladly help Ben on GCC 
  than write my own C dumper, although i see now that it (basically a 
reduced D dumper) is almost embedded in the DMD frontend source as a 
debugging feature.

-eye
Mar 18 2004