Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the board
Thread view  Mix view  Order  «  
 
DOS386(R)

04.03.2008, 02:07
 

BIG "C" compiler comparison thread (Developers)

D based on GCC

WATCOM

CC386 by Ladsoft

TCC by Fabrice Bellard

DigitalMARS

Old Boreland "Turbo" C compiler 2.0 (closed source freeware)

Visual studio C## 2010 Ultimate by ???

----------------------------------------------------------------------------

Please discuss here and don't pollute other threads :hungry:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Steve(R)

Homepage E-mail

US,
04.03.2008, 05:08

@ DOS386

BIG "C" compiler comparison thread

Nice list. What do you want?

Japheth(R)

Homepage

Germany (South),
04.03.2008, 09:38

@ DOS386

BIG "C" compiler comparison thread

> Please discuss here and don't pollute other threads :hungry:

Sorry, no, I have to refuse your list because D.... is at the first place which it doesn't deserve at all; being placed as a footnote - because of its historical relevance - seems more appropriate IMO. OTOH, there are some compilers missing (the superior, fine and free MS VC 2003 Toolkit for example)...

---
MS-DOS forever!

rr(R)

Homepage E-mail

Berlin, Germany,
04.03.2008, 10:02

@ DOS386

BIG "C" compiler comparison thread

> D based on GCC

It's not "D" but "DJGPP".

> WATCOM

Its name is "Open Watcom C/C++".

> TCC by Fabrice
> Bellard

Is this used by anyone except you?

> DigitalMARS

Its name is "Digital Mars C" and "C++, D".

> Old Boreland "Turbo" C compiler 2.0 (closed source freeware)

Borland isn't boring. It works fine for small tools and when you care about 8086 compatibility. Borland Turbo C++ 1.01 also supports the C language and is newer than Turbo C 2.01.

Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C, Micro C, Microsoft C, Miracle C, Small C, are missing.

Rugxulo(R)

Homepage

Usono,
04.03.2008, 14:53

@ rr

BIG "C" compiler comparison thread

> > D based on GCC
>
> It's not "D" but "DJGPP".

Anybody here not use this? It's very good, still updated, very robust in features, supports most C99 and modern C++ (ANSI 1998?). My only confusion is why people say, "Back in the day I used to use it ..." when it still exists! (I guess because certain libraries aren't ported??) Good docs, lots of useful utils, good optimizations, sometimes a bit bloated (barely). Good for porting *nix stuff (not that I have, heh). I actually wonder about that comment "Without it, DOS would be dead." because that's probably half-true, at least! Kudos big time to DJ and pals! ;-)

> > WATCOM
>
> Its name is "Open Watcom C/C++".

The only no-cost multiplatform 16-/32-bit compiler that runs natively on DOS with sourcecode. Very robust, supports lots of extenders, good docs, confusing linker, a few other nifty tools too (wdis, vi, ctags, wtouch, dmpobj). This is obviously good for HX because of its Win32 output. But the C++ support isn't quite as good/modern as G++. Oh, and no newer Fortran (95, 2003) like GCC has, only old standard F77 (not that I care, I don't understand it).

> > TCC by Fabrice
> > Bellard
>
> Is this used by anyone except you?

I have it installed on Windows but not DOS. It needs MSVCRT.DLL to run (ugh). But it's a nifty compiler (aimed to support C99, not sure how far along it is, but it's supposedly very good/compatible).

> > DigitalMARS
>
> Its name is "Digital Mars C" and "C++, D".

Never actually tried this, but I hear that the 32-bit DOS extender X32 (which is incompatible with some common setups) can access 3 GB of RAM.

> > Old Boreland "Turbo" C compiler 2.0 (closed source freeware)
>
> Borland isn't boring. It works fine for small tools and when you care
> about 8086 compatibility. Borland Turbo C++ 1.01 also supports the C
> language and is newer than Turbo C 2.01.

Small memory footprint, small sized, small output, very fast compilation. Not up-to-date on latest standards (C99, C++0x) but good for 16-bit ANSI stuff. (Indeed, some legacy code won't compile without it.)

BTW, don't forget Borland 5.5, which you can WDOSX the output to run in DOS. (That also works for Delphi, supposedly.) But I haven't used that, supposedly isn't that good standards support, but it must be okay, feature-wise.

> Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C,
> Micro C, Microsoft C, Miracle C, Small C, are missing.

Micro C is good if you can work around its quirks. The output is very tiny (literally, only supports tiny or small model). But sometimes, it's better just to do straight assembly, IMO. Still, not bad to have, and it uses very little space.

Dev86/BCC is moderately good too (for its size), also only small or tiny model. Open source too, but I've never been able to cleanly recompile it (blech).

From what little I've used Small C, it's similar to Micro C (not full ANSI support, some quirks), but it's okay for really tiny programs if you can massage it enough to get it to work for your needs. Open source.

EDIT: CC386's biggest "selling points" are that it's a very small install (compared to some), fast, and supports a ton of extenders while running on a NASM backend (so no need to ever worry about or learn AT&T syntax). C only (with C99 support), but still pretty darn good. Ladsoft worked very hard on this for quite a while, so his efforts are definitely appreciated.

---
Know your limits.h

Japheth(R)

Homepage

Germany (South),
04.03.2008, 18:32

@ Rugxulo

BIG "C" compiler comparison thread

> Anybody here not use this?

It's my daily bread ...

> ... sometimes a bit bloated (barely).

My C++ "hello world" with DGPJJ v2.03 results in a 350 kB binary (with "symbols" "stripped" already). I slightly hesitate to call that "barely bloated"...

---
MS-DOS forever!

Rugxulo(R)

Homepage

Usono,
04.03.2008, 18:57

@ Japheth

BIG "C" compiler comparison thread

> > ... sometimes a bit bloated (barely).
>
> My C++ "hello world" with DGPJJ v2.03 results in a 350 kB binary (with
> "symbols" "stripped" already). I slightly hesitate to call that "barely
> bloated"...

I can compile PAQ8o8 to smaller than that, and it's an actually useful program! Try not using C++ streams crap, use the C-based "stdio" instead. Also, "-Os -march=i386" might help. And provide your own dummy functions for env.var. file loading and globbing (see CRT0.H). Oh, and read this.

Steve(R)

Homepage E-mail

US,
04.03.2008, 20:41

@ rr

BIG "C" compiler comparison thread

> Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C,
> Micro C, Microsoft C, Miracle C, Small C, are missing.

Aztec, DeSmet, and Lattice were among the first Cs for microcomputers, c.1980s, so resource requirements are low. Aztec and Lattice were available for other platforms than the x86/DOS/PC, making porting from Amiga, Apple, etc. fairly easy (especially applies to Aztec for CP/M, if anybody still uses that OS). DeSmet was popular in its day, many good progs were written in it, but its power users switched to Turbo C when it got good.

Khusraw

04.03.2008, 21:51

@ DOS386

BIG "C" compiler comparison thread

Don't forget Pacific C, which is a relatively good 286 compiler. IMO better than many other old C compilers. The 486 assembler from the package is also usable.

Rugxulo(R)

Homepage

Usono,
05.03.2008, 01:06

@ Khusraw

BIG "C" compiler comparison thread

> Don't forget Pacific C, which is a relatively good 286 compiler.

Versus Turbo C? Do you know how they compare on code generation?

> IMO better than many other old C compilers.

Well, they at one time said they'd release an improved version (open source?) and never did. I never really used it, but IIRC, it had some weird quirks in its output. Besides, ANSI C only (no C99, no C++, slightly buggy library).

> The 486 assembler from the package is also usable.

Non-standard syntax, no? And used a quite dreadful name for a debugger. But at least the IDE was fairly good.

Rugxulo(R)

Homepage

Usono,
05.03.2008, 01:11

@ Steve

BIG "C" compiler comparison thread

> Aztec, DeSmet, and Lattice were among the first Cs for microcomputers,
> c.1980s, so resource requirements are low. ... but its power users
> switched to Turbo C when it got good.

Was Aztec the one by Manx or something else? I'm not even sure I know of any programs explicitly that used any of those three compilers (by Aztec: some *nix shell workalike, I forget the name). And didn't Lattice eventually get bought by MS and turned into MS C? As far as DeSmet, it's been resurrected (barely), and apparently, there was even a PCC shareware fork.

BTW, correct me if I'm wrong, but I think Turbo C was popular because of its nice IDE, low cost, and fast compilation speed.

Steve(R)

Homepage E-mail

US,
05.03.2008, 01:50

@ Rugxulo

BIG "C" compiler comparison thread

> > Don't forget Pacific C, which is a relatively good 286 compiler.
>
> Versus Turbo C? Do you know how they compare on code generation?
>
> > IMO better than many other old C compilers.
>
> Well, they at one time said they'd release an improved version (open
> source?)

The compiler is freeware but not Open source. Package includes text-based GUI IDE, source editor, linker, assembler, Causeway DOS extender. Last version is 7.51, from 2003. If you're curious, the manual (PDF) can be downloaded separately from the compiler.

Home page: http://www.htsoft.com/products/compilers/PACIFICc.php

Steve(R)

Homepage E-mail

US,
05.03.2008, 02:05

@ Rugxulo

BIG "C" compiler comparison thread

> Was Aztec the one by Manx or something else?

Something else.

> I'm not even sure I know of
> any programs explicitly that used any of those three compilers (by Aztec:
> some *nix shell workalike, I forget the name).

Aztec and Lattice were popular in Amiga circles, maybe Apple (i.e, they were available for Apple, but I don't know how popular they were). I can't recall seeing any DOS PC progs written in them - like DeSmet, they got wiped out early on by Turbo C for DOS, and by the end of the Amiga and Apple II.

> And didn't Lattice eventually get bought by MS and turned into MS C?

It was bought by SAS (the software company, not the airline).

> I think Turbo C was popular because of its nice IDE, low cost, and fast compilation speed.

Correct.

Khusraw

05.03.2008, 08:01

@ Rugxulo

BIG "C" compiler comparison thread

> Versus Turbo C? Do you know how they compare on code generation?

I'm used to look over the code generated by any compiler I test, so yes, I know. The optimized code is comparable to that of Turbo C (but as you noticed it has some weird flaws, it looks like an unfinished job), plus the compiler can pass the first two arguments in registers and has some alignment options that Turbo C lacks.

> Well, they at one time said they'd release an improved version (open
> source?) and never did. I never really used it, but IIRC, it had some
> weird quirks in its output. Besides, ANSI C only (no C99, no C++, slightly
> buggy library).

I don't think that opening the source is important (who would improve it?), the same concerning C99 and C++ support (I don't need them). What bugs has library?

> Non-standard syntax, no? And used a quite dreadful name for a debugger.
> But at least the IDE was fairly good.

Non-standard syntax, but not so different and logical enough. I don't find the debugger's name dreadful, considering its meaning. The IDE is memory hungry (both conventional and XMS) and is slow.

rr(R)

Homepage E-mail

Berlin, Germany,
05.03.2008, 09:57

@ Steve

BIG "C" compiler comparison thread

> > And didn't Lattice eventually get bought by MS and turned into MS C?
>
> It was bought by SAS (the software company, not the airline).

You can still buy Lattice C from http://www.lattice.com/otherdos.htm. Don't know about the prices. I asked, but didn't get any response.

rr(R)

Homepage E-mail

Berlin, Germany,
05.03.2008, 10:01

@ Rugxulo

BIG "C" compiler comparison thread

> Was Aztec the one by Manx or something else?

Just have a look at Aztec-C and links from there.

Japheth(R)

Homepage

Germany (South),
05.03.2008, 11:02

@ Rugxulo

No cheats please!

> I can compile
> PAQ8o8 to
> smaller than that, and it's an actually useful program! Try not using C++
> streams crap, use the C-based "stdio" instead. Also, "-Os -march=i386"
> might help. And provide your own dummy functions for env.var. file loading
> and globbing (see CRT0.H). Oh, and read
> this.

Sorry, but it wasn't me who invented the "standard" C++ "hello, world" with io streams. And to provide dummy functions for this and that is also cheating IMO.

---
MS-DOS forever!

Rugxulo(R)

Homepage

Usono,
05.03.2008, 14:04
(edited by Rugxulo, 05.03.2008, 14:27)

@ Khusraw

BIG "C" compiler comparison thread

> I'm used to look over the code generated by any compiler I test, so yes, I
> know. The optimized code is comparable to that of Turbo C (but as you
> noticed it has some weird flaws, it looks like an unfinished job), plus
> the compiler can pass the first two arguments in registers and has some
> alignment options that Turbo C lacks.

I was looking at some asm output from TC++ 1.01 today, and it's seriously not optimized for modern cpus. "inc sp" "inc sp" via speedup option -G instead of "pop ax" (I guess? because 8086 was very slow for "pop", according to HelpPC). Still, it's a good compiler. And, as has been mentioned to me before, small changes like that don't speed up much (although I still say it's worth it, especially if you can automate the process via some text processing, e.g. sed script).

> I don't think that opening the source is important (who would improve
> it?),

I don't care (much), and I may be remembering incorrectly, but they did supposedly at one time plan / hope to release an improved version. Oh well. Strange how FreeDOS is active but some people still think nobody uses DOS. (They've probably moved on to "bigger markets", ugh.)

> the same concerning C99 and C++ support (I don't need them). What
> bugs has library?

Well, most people don't need C99, and C++ is just plain scary to me! So, I don't need 'em. (Even GCC isn't 100% C99 yet, and MSVC has no plans for such last I heard.)

But anyways, I dunno how buggy the library is, didn't mean to imply that. However, FreeDOS / Blair's MD5SUM tool generated incorrect hashes when compiled with Pacific C (vs. OpenWatcom or whatever).

> > Non-standard syntax, no? And used a quite dreadful name for a debugger.
> > But at least the IDE was fairly good.
>
> Non-standard syntax, but not so different and logical enough.

Use it if you like it, but others are faster, more modern, more popular syntax, and less buggy perhaps. There are lots of assemblers out there (unless you're Japheth, heh).

> I don't find the debugger's name dreadful, considering its meaning.

There is no worse name, IMO.

> The IDE is memory hungry (both conventional and XMS) and is slow.

I prefer using a normal text editor anyways and doing a manual compile (or make). But their IDE at least seemed logical and intuitive, IIRC.

Rugxulo(R)

Homepage

Usono,
05.03.2008, 14:07

@ Japheth

No cheats please!

> Sorry, but it wasn't me who invented the "standard" C++ "hello, world"
> with io streams.

Me either. At this point, I can't imagine anyone saying C++ is easier than anything. (Ah, abstraction, whoopee.)

> And to provide dummy functions for this and that is also
> cheating IMO.

Not really, they aren't needed here (or in most instances, probably). If DOS had native LFN support and super long cmdlines like more bloated OSes, then it wouldn't need to support the old and new way of doing things. But since it does, it's bloated unless you tell it to explicitly remove it. (Most people don't care because it's not a big .EXE size these days.)

Khusraw

05.03.2008, 15:46

@ Rugxulo

BIG "C" compiler comparison thread

> I was looking at some asm output from TC++ 1.01 today, and it's seriously
> not optimized for modern cpus. "inc sp" "inc sp" via -G instead of
> "pop ax" (I guess because 8086 was very slow for "pop", according to
> HelpPC ?).

It is a 8086-80286 compiler, so it optimizes for 80286 at best, but I find useful these old C/C++ compilers. Turbo C is the best IMO, I still use it sometimes. I wouldn't use Open Watcom or Digital Mars for writing 16-bit C code. I have no arguments, is just a question of habitude.

> But anyways, I dunno how buggy the library is, didn't mean to imply that.
> However, FreeDOS / Blair's MD5SUM tool generated incorrect hashes when
> compiled with Pacific C (vs. OpenWatcom or whatever).

I used Pacific C for compiling some small projects (just to see how it works) and I had no problems. Did you try to compile MD5SUM with it yourself? There was no warning message? Did you inform the developers?

> Use it if you like it, but others are faster, more modern, more popular
> syntax, and less buggy perhaps. There are lots of assemblers out there
> (unless you're Japheth, heh).

I know about them, and I don't use as86. But it is usable and if you need a 16-bit C compiler+80486 assembler package, Pacific C remains an option. Surely not the best, but this is another problem.

> There is no worse name, IMO.

Perhaps you know what "lucifer" means in Latin, but I'm almost sure you don't know that we inherited the word in Romanian language under the form "luceafar". The word "luceafar" never meant the devil, it was used for the planet Venus and other less important bright stars, but now is mostly used in its figurative meaning of paragon, brilliant person, genius. If it recalls you the devil before its fall, for me it simply means something bright("a luci" means "to shine" in Romanian.) :-)

Rugxulo(R)

Homepage

Usono,
06.03.2008, 04:40

@ Khusraw

BIG "C" compiler comparison thread

> It is a 8086-80286 compiler, so it optimizes for 80286 at best

Even Turbo C++ (which I use a lot) has a -2, but does it do anything useful?? (Haven't checked the asm output on that, maybe I should.)

> , but I find
> useful these old C/C++ compilers. Turbo C is the best IMO, I still use it
> sometimes. I wouldn't use Open Watcom or Digital Mars for writing 16-bit C
> code. I have no arguments, is just a question of habitude.

I don't use OpenWatcom exclusively, but I do think (hope?) it's better at code generation than old Borland. Then again, I haven't tested enough to know for sure. I'm just glad for the alternative.

> I used Pacific C for compiling some small projects (just to see how it
> works) and I had no problems. Did you try to compile MD5SUM with it
> yourself? There was no warning message? Did you inform the developers?

No, I didn't try with Pacific C, so I dunno if it had warnings. The developer eventually released a recompiled version done by OpenWatcom, so everything is fine. (Try recompiling MD5SUM yourself if you're curious, and report back what you discover.)

> > Use it if you like it, but others are faster, more modern, more popular
> > syntax, and less buggy perhaps. There are lots of assemblers out there
> > (unless you're Japheth, heh).
>
> I know about them, and I don't use as86. But it is usable and if you need
> a 16-bit C compiler+80486 assembler package, Pacific C remains an option.
> Surely not the best, but this is another problem.

To each his own, I guess.

> > There is no worse name, IMO.
>
> Perhaps you know what "lucifer" means in Latin,

"Light bearer", right?

> but I'm almost sure you
> don't know that we inherited the word in Romanian language under the form
> "luceafar". The word "luceafar" never meant the devil, it was used for the
> planet Venus and other less important bright stars, but now is mostly used
> in its figurative meaning of paragon, brilliant person, genius.

"Wow, that Linus Torvalds sure is a Lucifer for his hard work! God bless him!"

(Talk about a weird example sentence to put in a dictionary.)

At least where I'm from (southern U.S.), I never hear it used, proper or common noun. Meh, I just don't like it. I just find it hard to believe they couldn't just have called it "PDEBUG" or whatever.

> If it
> recalls you the devil before its fall, for me it simply means something
> bright("a luci" means "to shine" in Romanian.) :-)

"Lucy" to me is my aunt. So I have no problem with that. ;-)

Japheth(R)

Homepage

Germany (South),
06.03.2008, 07:52

@ Rugxulo

BIG "C" compiler comparison thread

> I don't use OpenWatcom exclusively, but I do think (hope?) it's better at
> code generation than old Borland. Then again, I haven't tested enough to
> know for sure. I'm just glad for the alternative.

Yes, OW's 16bit code generator is significantly better than Turbo's one. However, it is beaten by MS VC 1.52, which most likely is the best 16bit C++ compiler of all times, past and future.

---
MS-DOS forever!

Khusraw

06.03.2008, 10:41
(edited by Khusraw, 06.03.2008, 14:03)

@ Rugxulo

BIG "C" compiler comparison thread

> I don't use OpenWatcom exclusively, but I do think (hope?) it's better at
> code generation than old Borland. Then again, I haven't tested enough to
> know for sure. I'm just glad for the alternative.

Surely that Open Watcom is better than Turbo/Borland C/C++, no one doubted this. But it's not as good as it could be. E. g. write a program which uses far pointer arithmetics, pass it to wcc with register calling convention and optimization enabled and then look over the assembly output and you'll understand what I mean. If you still have reasons to write 16-bit code and you are so concerned with code optimization, better use an assembler.

> No, I didn't try with Pacific C, so I dunno if it had warnings. The
> developer eventually released a recompiled version done by OpenWatcom, so
> everything is fine. (Try recompiling
> MD5SUM
> yourself if you're curious, and report back what you discover.)

Hard to belive, but I tried. Pacific C doesn't like fixed size arrays passed as parameters and it has a poor <dos.h>, but these are lack of features, not bugs. I don't think that the library is buggy, the developers would have provided some patches until now if this was a known thing.

> At least where I'm from (southern U.S.), I never hear it used, proper or
> common noun. Meh, I just don't like it. I just find it hard to believe
> they couldn't just have called it "PDEBUG" or whatever.

Actually I consider the name very suggestive for a debugger. It sheds light upon your code.;-) About the Romanian word, you can see this (it's a Romanian explicative and etymologic dictionary, but the names of the stars are transparent in English too) and this (how the word can be translated into English). In conclusion no devil, only bright things.

tom(R)

Homepage

Germany,
08.03.2008, 21:50

@ Japheth

BIG "C" compiler comparison thread

> Yes, OW's 16bit code generator is significantly better than Turbo's one.
> However, it is beaten by MS VC 1.52, which most likely is the best 16bit
> C++ compiler of all times, past and future.

In about 2002, we compared the codesize for the FreeDOS kernel
produced by TC 2.01, TC++, Watcom, MS VC 1.52, Digital Mars

TC/TC++ were largest, then MS VC (~85%), then Watcom (~80%)
Digital Mars didn't compile straight due to some crazy macros/far pointer arithmetik, but would probably ended up at ~88%

Watcom allows also some funny inline assembler functions, so with a couple of #ifdefs the watcom kernel is now a few percent smaller.

If only size matters, Watcom is the best compiler around for DOS Kernel type of project.
OTOH MS VC 1.52 produces better code for 386 CPUs and DWORD operations; so your milage may vary

Rugxulo(R)

Homepage

Usono,
09.03.2008, 00:53

@ tom

BIG "C" compiler comparison thread

> In about 2002, we compared the codesize for the FreeDOS kernel
> produced by TC 2.01, TC++, Watcom, MS VC 1.52, Digital Mars

TC 2.01, TC++, and MS VC 1.52 haven't changed a lick since then (five or six years). But Digital Mars, Watcom (now OpenWatcom) are still developed (although I dunno if they really worked on the C++ much, still not nearly as compliant as G++, but 1.8 beta does have someone heavily tweaking it, supposedly). I actually heard someone claim that Digital Mars (or Zortech, whatever) was the first native C++ (PC?) compiler (i.e., not a front-end?). So, it should be good at C++, but I dunno how compatible it is in 16-bit DOS land (meh).

> If only size matters, Watcom is the best compiler around for DOS Kernel
> type of project.

Here's what Eric's latest kernel ("fat security") compile is:

Watcom sizes: 386/16 41280 /32 45857 86/16 43517 /32 46174
TurboC sizes: 186/16 42720 /32 45132 86/16 42861 /32 45267

DOS386(R)

09.03.2008, 02:11
(edited by DOS386, 09.03.2008, 03:03)

@ Steve

BIG "C" compiler comparison thread

> Nice list. What do you want?

Wanted just an overpolite, exhaustive and useful 6 words answer from Steve. Now I got exactly such, so it's now safe to F.O. :lol:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386(R)

09.03.2008, 02:17

@ rr

BIG "C" compiler comparison thread | evil TCC

> > TCC by Fabrice Bellard
> Is this used by anyone except you?

Don't know ... but it's sufficiently good to be mentioned here ... plus you are in the wrong community with your "argument" of "but only one person uses this" :-P

And, IIRC 1 or 2 bugs of CC386 got fixed after testing against TCC :-)

> Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C,
> Micro C, Microsoft C, Miracle C, Small C, are missing.

YES, but most of them can't compile anything recent / useful.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386(R)

09.03.2008, 02:49

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

D based on GCC

> refuse your list because D.... is at the first place which it doesn't deserve

The placing is random ... 1st place is not the best :no:

> It's not "D" but "DJGPP".

NO.

++ MPLAYER got ported to DOS with it and works. No space for neglection here :-)

+ GCC core produces less bad code ("optimization") than some other compilers
+ GCC is still under development and actively competes against VCC
+ Supports C++
+ Offers Loonix "emulation at source level", occasionally useful for porting
+ "without D, DOS would be dead" - reportedly, evidence pending :hungry:
+ "D makes life easier" - reportedly, OTOH, at least, it makes video playing in DOS easier, see above, this is a "scientific" fact :clap:

- The excessive dominance / exclusivity of D prevents people from taking notice of other compilers
- Offers Loonix "emulation at source level", rarely useful, ON by default, difficult to get rid of it
- Supports C++
- Bloats executables, especially from C++
- Itself bloated and messy, not easy to download, install and use
- No 16-bit RM support
- Bad design of the "GO32" extender with outsourced CWSDPMI and non-ZERO-based memory model
- Both inline ASM and output ASM are reportedly supported, but GAS/ATT syntax only, "MASM INTEL" supposed to work but doesn't
- Can't compile itself on DOS
- It's OBSOLETE :crying:
- No project goal, 2.04 beta has been pending for 5 years, nobody knows when 2.04 final will get out, if ever, and what it should offer then :-(
-- Startup code and libraries are bloated, messy, and full on XP hacks :-( :-(

> WATCOM

++ Used for FreeDOS kennel and utils

+ Both DPMI32 and 16-bit RM
+ Compiler core produces less bad code ("optimization") than some other compilers
+ Since 1.6 DOS is supported again
+ Comes with WASM, a free "unusable toy" clone of MASM
+ Supports DOS/32A and D3X extender
+ HX / LOADPEX also supported (?)
+ Supports C++

- Itself bloated and messy, not easy to download, install and use
- Supports C++, but bad compatibility with GCC and VCC ?
- Has IDE's for all platforms except DOS
- No inline ASM, no ASM output :-(
- WASM is bad and not really progressing

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386(R)

09.03.2008, 03:02

@ Japheth

BIG "C" compiler comparison thread | WC 1.52

> Yes, OW's 16bit code generator is significantly better than Turbo's one.
> However, it is beaten by MS VC 1.52, which most likely is the best 16bit
> C++ compiler of all times, past and future.

OK ... Lucho said the same ... Tom and Rugxulo neglect - seems to depend of source coding style and some settings :-|

BTW, at what version did Borland drop 16-bit RM ? IIRC it was much later then in PASCAL compilers :no:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth(R)

Homepage

Germany (South),
09.03.2008, 08:41

@ DOS386

BIG "C" compiler comparison thread | evil TCC

> > > TCC by Fabrice
> Bellard
> > Is this used by anyone except you?
>
> Don't know ... but it's sufficiently good to be mentioned here ... plus
> you are in the wrong community with your "argument" of "but only
> one person uses this" :-P

rr just loves to use the "million flies..." argument ... :-D

However, TCC is used by more than just one person. For example, see http://www.winasm.net/forum/index.php?showtopic=2058

---
MS-DOS forever!

Japheth(R)

Homepage

Germany (South),
09.03.2008, 08:56

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

> - It's OBSOLETE
> :crying:

btw, the problems of DGPJJ on WinXP which are mentioned in the wiki article were to a large part due to its usage of the non-zero-based memory model. So the argument that the memory model is just relevant for low-level stuff isn't convincing.

> - WASM is bad and not really progressing

I soon shall make it progress a little... :-D

---
MS-DOS forever!

Steve(R)

Homepage E-mail

US,
09.03.2008, 09:36

@ Rugxulo

BIG "C" compiler comparison thread

> I actually heard someone claim that Digital Mars (or Zortech,
> whatever) was the first native C++ (PC?) compiler (i.e., not a front-end?).

Walter Bright's Zortech C++ was the first native compiler - earlier ones first expanded C++ code to C, then did the real compiling. It was available for several 80386 PC OSes & for Mac/68030.

Steve(R)

Homepage E-mail

US,
09.03.2008, 09:40

@ DOS386

BIG "C" compiler comparison thread

> > Nice list. What do you want?
>
> Wanted just an overpolite, exhaustive and useful 6 words answer from
> Steve. Now I got exactly such,

I'm pleased to serve.

> so it's now safe to F.O. :lol:

Please do.

Steve(R)

Homepage E-mail

US,
09.03.2008, 12:40

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

> > It's not "D" but "DJGPP".
>
> NO.

"NO" what? You give links to djgpp.

rr(R)

Homepage E-mail

Berlin, Germany,
09.03.2008, 22:10

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

> - The excessive dominance / exclusivity of D prevents people from taking
> notice of other compilers

Duh?! It's "evil", because it's successful?

> - Supports C++

Why is this a minus? If you don't like C++, don't use it.

> - Itself bloated and messy, not easy to download, install and use

Sorry, but the DJGPP Zip File Picker is easy to use and you just have to unzip files to get DJGPP installed.

> - No 16-bit RM support

There's (outdated) experimental 8086 support at http://www.delorie.com/djgpp/16bit/.

> - It's OBSOLETE
> :crying:

Many people call DOS obsolete, but you still use it. So why do you care about? :confused:

> - No project goal, 2.04 beta has been pending for 5 years, nobody knows
> when 2.04 final will get out, if ever, and what it should offer then :-(

OK, but djdev204 works fine. DJGPP just lacks man power to lever a 2.04 final.

> + Supports C++

Why is this a plus for OW, but a minus on DJGPP?

rr(R)

Homepage E-mail

Berlin, Germany,
09.03.2008, 22:20

@ DOS386

BIG "C" compiler comparison thread | evil TCC

> Don't know ... but it's sufficiently good to be mentioned here ... plus
> you are in the wrong community with your "argument" of "but only
> one person uses this" :-P

Please learn to set correct links! I don't see TCC mentioned in message 1024.

> > Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C,
> > Micro C, Microsoft C, Miracle C, Small C, are missing.
>
> YES, but most of them can't compile anything recent / useful.

That just depends on your point of view. If you target your project directly on one of these compilers, you would be able to produce something more useful than your "strange" FASM hacks, which are definitely not useful to me. :-P

Rugxulo(R)

Homepage

Usono,
10.03.2008, 03:29

@ DOS386

BIG "C" compiler comparison thread | evil TCC

> Don't know ... but it's sufficiently good to be mentioned here ... plus
> you are in the wrong community with your "argument" of "but only
> one person uses this" :-P
>
> And, IIRC 1 or 2 bugs of CC386 got fixed after testing against TCC :-)

TCC can compile a modified Linux kernel without an external linker or assembler. Also, it's (mostly) C99 compliant. Plus, it's faster than GCC. (Granted, it could be better, but what can't?)

> > Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI C,
> > Micro C, Microsoft C, Miracle C, Small C, are missing.
>
> YES, but most of them can't compile anything recent / useful.

There are a few FreeDOS utils that compile with Micro C (though less so now that OpenWatcom exists). But something like DeSmet C is more useful because it's (supposedly) more or less ANSI. Micro C and Small C are very very limited but good for some rare uses. It's more accurate to say that 16-bit anything is deprecated (deservedly or not) by most people.

Rugxulo(R)

Homepage

Usono,
10.03.2008, 03:39

@ rr

BIG "C" compiler cmp | the "scientific" facts ore out DW

> > - The excessive dominance / exclusivity of D prevents people from taking
> > notice of other compilers
>
> Duh?! It's "evil", because it's successful?

It's successful because it's GCC, it's free, it's open source, and it's stable, as well as having many support libraries (e.g. Allegro). Oh, and PM stability plus being able to access most of your RAM doesn't hurt either.

> > - Supports C++
>
> Why is this a minus? If you don't like C++, don't use it.

Agreed. I mean, GCC 4.2.3 supports C, C++, Fortran, Ada, Obj C, and Obj C++. That's quite a lot. (More if you count assembly via GAS.) Nothing wrong with that, even if I don't personally use it all.

> > - Itself bloated and messy, not easy to download, install and use
>
> Sorry, but the DJGPP Zip File Picker is easy to use and you just
> have to unzip files to get DJGPP installed.

DJDEV204.ZIP, BNU217B.ZIP, GCC423B.ZIP is the bare bare minimum. "md DJGPP" and "unzip *.zip -d \DJGPP" plus "set DJGPP=C:\DJGPP\djgpp.env" and you're set.

> > - No 16-bit RM support
>
> There's (outdated) experimental 8086 support at
> http://www.delorie.com/djgpp/16bit/.

Somebody recently submitted real 8086 patches for use in embedded work. But, 16-bit anything is frowned upon (esp. by Linux 31337).

> > - It's OBSOLETE
> > :crying:
>
> Many people call DOS obsolete, but you still use it. So why do you care
> about? :confused:

Not trendy anymore perhaps, but it still works. Just because it isn't popular doesn't mean it sucks. It's quite robust. But people follow top dogs, not the little guys. (BTW, it's completely false that it's unstable on XP or any Windows anymore. That was a long, long time ago. And that was partially due to NTVDM bugs. Nobody switched to MinGW or Cygwin because of that. Heck, those have much older GCCs than DJGPP! People may have done it for other reasons [DirectX?].)

> > - No project goal, 2.04 beta has been pending for 5 years, nobody knows
> > when 2.04 final will get out, if ever, and what it should offer then
> :-(
>
> OK, but djdev204 works fine. DJGPP just lacks man power to lever a 2.04
> final.

Yeah, well, DJ just is really slow at updating, that's all. He's overwhelmed, probably. Besides, he has a family to support, etc.

> > + Supports C++
>
> Why is this a plus for OW, but a minus on DJGPP?

16-bit support, perhaps?? (Dunno.) They really aren't as good as G++. But it's good enough for some reasonable use, at least. I don't understand the idea that you have to code everything in only the latest, greatest standard. "Whatever works" should usually be good enough.

Steve(R)

Homepage E-mail

US,
10.03.2008, 06:24

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

[djgpp]
> - It's OBSOLETE

From that article:
"While DJGPP has been widely used for OS development in the past, it's [sic] close connection to MS-DOS and compatibility problems with Windows XP have caused most Windows users to shift to Cygwin or MinGW. DJGPP must be considered obsolete by now."

The author doesn't know what djgpp is for - it is not obsolete for its actual purpose. The reference to Cygwin and MinGW is, in proper context, irrelevant.

But if it's written, it must be true - so I withdraw my comments, above. :rotfl:

Japheth(R)

Homepage

Germany (South),
10.03.2008, 09:04

@ Steve

BIG "C" compiler cmp | the "scientific" facts ore out DW

> "NO" what? You give links to djgpp.

You've fallen into this little trap. Shame on you! :-D

---
MS-DOS forever!

DOS386(R)

10.03.2008, 09:08

@ rr

BIG "C" compiler cmp | the "scientific" facts ore out DW

> > - Supports C++
> Why is this a minus? If you don't like C++, don't use it.

See below :hungry:

> > - No 16-bit RM support
> There's (outdated) experimental 8086 support at

OK :-| ... outdated / experimental / incomplete

> Many people call DOS obsolete, but you still use it.

YES.

> So why do you care about

Indeed no need to care too much :clap:

> > + Supports C++
> Why is this a plus for OW, but a minus on DJGPP?

Because you didn't read my post carefully :lol3: I prefixed "C++" with both "+" and "-" for both D and WATCOM

> If you target your project directly on one of these compilers,
> you would be able to produce something more useful

Probably YES, to some degree (memory limits :-( ) ...

> than your "strange" FASM hacks, which are definitely not useful

This statement is not useful , but, at least, my "strange hacks" :

1. Don't take hours to download
2. Don't pressure anybody to buy a bigger HD
3. Can be deleted easily if someone doesn't like them :clap:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

RayeR(R)

Homepage

CZ,
10.03.2008, 11:39

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

> - Bad design of the "GO32" extender with outsourced CWSDPMI and
> non-ZERO-based memory model

Could you someone explain to me what mean zero/nonzero based memory model? Resp. what are the advantages and issues of this? Why DJ decided to use it if it is SO BAD?

I use C (mostly DJGPP) because I don't want to mess with memory management and let compiler to do it for me. And I think DJGPP serves enough functions for accessing real and entire physical memory. So I don't feel bad that I have something like nonzero based model if it can properly work under common DPMI server in DOS and Windows.

---
DOS gives me freedom to unlimited HW access.

DOS386(R)

10.03.2008, 12:07

@ RayeR

BIG "C" compiler cmp | the "scientific" facts ore out DW

> Could you someone explain to me what mean zero/nonzero based memory model?

ZERO-based: base of CS, DS and SS is ... yeah ... ZERO 0 ;-)

Non-ZERO-based: base is <>0 ... or !=0 for you ;-) ... mostly it is > 0 , but who knows, could be also < 0 maybe :lol:

> are the advantages and issues of this?

ZERO:

+ Easy access to whole memory, incl. low memory and VESA LFB
+ Better compatible with DeLL-hell ???
- Faulty C pointers can damage low memory

NON-ZERO:

+ Faulty pointers can do less damage
- Need hacks to access low memory and VESA LFB

> Why DJ decided to use it

C pointers, I guess ;-)

> I use C (mostly DJGPP) because I don't want to mess with memory management
> and let compiler to do it for me.

We know ;-)

> And I think DJGPP serves enough functions
> for accessing real and entire physical memory.

entire: YES , there are some ;-)

physical: NO , not even DPMI supports this fully: map: YES , allocate: NO :-(

With ZERO-base, accessing VGA or VESA is as easy as:

         ; Assume DS=ES , ZERO based
         mov edi,$A0000
         mov esi,qqbuffer
         mov ecx,16000
         rep movsd


         ; Assume DS=ES , ZERO based
         mov edi,qqphys ; Physical
         ...
         blah, blah, call INT $31/$0800 to "map"
         ...
         ; Now EDI has "linear" possibly paged/mapped address
         mov esi,qqbuffer
         mov ecx,qqvesasize ; In 32bit units
         rep movsd


NO NEED to change segment registers or create a mess of selectors ;-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

rr(R)

Homepage E-mail

Berlin, Germany,
10.03.2008, 12:31

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

> 3. Can be deleted easily if someone doesn't like them :clap:

Did you ever hear about "deltree"?

tom(R)

Homepage

Germany,
10.03.2008, 12:59
(edited by tom, 10.03.2008, 19:16)

@ Rugxulo

BIG "C" compiler comparison thread

> Here's what Eric's latest kernel ("fat security") compile is:
>
> Watcom sizes: 386/16 41280 /32 45857 86/16 43517 /32 46174
> TurboC sizes: 186/16 42720 /32 45132 86/16 42861 /32 45267

these are the sizes after compression.
if comparing codesize, you should compare before compression
(the duller the compiler is, the easier it is to compress later)
for instance the output of the dull TC code generator is much better
compressable then the output of the smart WC code generator

Steve(R)

Homepage E-mail

US,
10.03.2008, 13:52

@ Japheth

BIG "C" compiler cmp | the "scientific" facts ore out DW

> You've fallen into this little trap. Shame on you! :-D

Ich verstehe nicht.

Steve(R)

Homepage E-mail

US,
10.03.2008, 13:58

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

So when are we going to see your compiler? Will you be writing it in FASM?

Japheth(R)

Homepage

Germany (South),
10.03.2008, 14:43

@ Steve

Ich nix verstehen - andere Baustelle!

> Ich verstehe nicht.

Don't worry, that doesn't matter. Most people don't understand what I'm talking about. OTOH, your German is good. You can even improve it by using variations:

"ich verstehe nicht"

-> "Verstehe nur Bahnhof."
-> "Ich habe nicht die leiseste Ahnung wovon du da faselst."
-> "Was?"
-> "Könnten Sie sich bitte etwas deutlicher ausdrücken!"

---
MS-DOS forever!

Khusraw

10.03.2008, 16:00
(edited by Khusraw, 10.03.2008, 16:11)

@ RayeR

BIG "C" compiler cmp | the "scientific" facts ore out DW

> Could you someone explain to me what mean zero/nonzero based memory model?
> Resp. what are the advantages and issues of this? Why DJ decided to use it
> if it is SO BAD?

Let's don't forget that nevertheless a DJGPP ELF port exists. ELF executables are zero memory based. I know that it is not officaly supported and I don't know how much it is used, but it works, I tested it. People who complain that DJGPP executables are not zero memory based could have been more involved with my compatriot Daniel Borca's project.

RayeR(R)

Homepage

CZ,
10.03.2008, 17:42

@ Khusraw

BIG "C" compiler cmp | the "scientific" facts ore out DW

> Let's don't forget that nevertheless a DJGPP ELF port exists. ELF
> executables are zero memory based. I know that it is not officaly
> supported and I don't know how much it is used, but it works, I tested it.

But for what is ELF output usefull in DOS? For linux I rather use linux gcc.

---
DOS gives me freedom to unlimited HW access.

Khusraw

10.03.2008, 17:50

@ RayeR

BIG "C" compiler cmp | the "scientific" facts ore out DW

> But for what is ELF output usefull in DOS? For linux I rather use linux
> gcc.

I was talking about Daniel Borca's DJGPP ELF port. It is about stubed ELF executables (i.e. they have appended a DOS loader), so they work in DOS.
The port is valuable by providing zero based memory model and easy to use dynamic loadable modules with DJGPP.

Back to the board
Thread view  Mix view  Order  «  
 
15108 Postings in 1358 Threads, 246 registered users, 13 users online (0 registered, 13 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum