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?


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.

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.

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

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