Jump to page: 1 2
Thread overview
gdmd on tcc?
Mar 14, 2004
Robert Jones
Mar 14, 2004
J C Calvarese
Mar 14, 2004
Ilya Minkov
Mar 14, 2004
Ben Hinkle
Mar 15, 2004
resistor
Mar 15, 2004
Robert Jones
Mar 16, 2004
Ilya Minkov
Mar 15, 2004
Olaf Rogalsky
Mar 16, 2004
Ilya Minkov
Mar 16, 2004
Olaf Rogalsky
Mar 16, 2004
KTC
Mar 16, 2004
Charles Hixson
Mar 17, 2004
resistor
Mar 17, 2004
Ilya Minkov
Mar 18, 2004
resistor
Mar 18, 2004
Ilya Minkov
March 14, 2004
Has anyone considered getting the d frontend to work with the Tiny C compiler for Gnu/Linux?
March 14, 2004
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/
March 14, 2004
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
March 14, 2004
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

March 15, 2004
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?


March 15, 2004
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.
March 15, 2004
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 +-------------------------------------------------------------------+
March 16, 2004
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
March 16, 2004
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
March 16, 2004
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 +-------------------------------------------------------------------+
« First   ‹ Prev
1 2