Hacker News Reader

Hacker News

Comment by mwcampbell | Hacker News Reader

Parent Full thread

mwcampbell

I followed the link for the X32VM DOS extender, and landed at one of those generic domain squatter pages.

Anyway, the Digital Mars C/C++ compiler looks impressive.

View on HN

Genuinely curious: why would I choose the digital mars C/C++ compiler over GCC/clang?

The DMC++ compiler is far and away the best C++ compiler on DOS.

Ok, but why / in what way is it better?

It's optimized to the way the x86 works, for example, near/far pointer support. AFAIK gcc and clang do not support near/far.

How does it compare to OpenWatcom? (the only other modern(ish) compiler I'm aware of with near/far support)

Watcom was (is?) the best optimizing compiler for 80[3]86, and it included a DOS extender (among other things).

Watcom ceased development 25(?) years ago. DMC still gets updates and code gen improvements.

The most recent commit for OpenWatcom, which is what I originally asked about, was 4 hours ago[1] at time of writing.

[1]: https://github.com/open-watcom/open-watcom-v2/commit/ac10ed3...

(FWIW: I'm in agreement with you that DMC++ is likely superior, I'm more curious about what OpenWatcom's deficiencies in relation to it are, and I reckon there are probably only a few people as familiar and qualified than yourself to comment)

I thought OW was museumed. I guess I was wrong. I have no idea how its code gen compares with DMC++ these days.

I used Open Watcom 2 in production, together with JWasm and JWlink, everything worked perfectly. Though I remember a couple issues I had and reported mainstream, they fixed it relatively quickly.

When i made a small raytracing benchmark a few years ago[0] OpenWatcom produced better code than DMC (note it was C, not C++), though they were both crushed by Visual C++ 6.

[0] http://runtimeterror.com/tools/raybench/

A few years ago is a long time ago in the compiler biz.

Ok, i tried with the latest versions of both (DMC 8.57 - though the compiler advertises itself as 8.42n - and the latest build from OpenWatcom).

DMC version: Elapsed time = 7.593 seconds

OW2 version: Elapsed time = 6.344 seconds

While i'm using a different CPU than the one from the previous benchmark, the relative results are practically identical (OW version is ~1.195 times faster for the old results and ~1.196 with the new results). VC6 is still faster than both.

FWIW i do not think these different matter that much in practice anyway, if anyone is going to target those old machines nowadays it'd be for retrocoding fun and in those cases if performance is a concern you'd most likely just want to use assembly anyway. IMO as long as a compiler does some basic optimizations to get mostly there it is fine. Some years ago i wrote a small maze rasterizer[0] in C to run on an original IBM PC and i tried to compile it with both Turbo C and OpenWatcom... and there was zero difference in performance since the main render loop was done by generated machine code, so OW's optimizer was optimizing stuff that didn't really need optimizing anyway :-P.

[0] https://i.imgur.com/M3gKlfA.jpg

I haven't updated the binary on the website in a while, the current version is version 9.00 :-)

Thanks for running the tests.

I can email you a current version if you like.

Sure, check my mail in my profile page.

Sent!

> want to use assembly anyway

Well, Doom was written in C, so...

Doom was written mainly in C but the important bits like the span rasterization for the DOS version were written in assembly. The released code was for the Linux version that didn't use assembly so the DOS was only as part of a README file[0]. The sound code was licensed (and thus never released to the public) and most likely also used assembly as that was common at the time.

Quake also used assembly for a few bits (also, like Doom, had C versions for portability).

That is what i meant when i wrote "use assembly", not to write the entire game in assembly (which is why i also gave my maze renderer as an example - pretty much all of it was in C except a tiny part).

[0] https://github.com/id-Software/DOOM/blob/master/linuxdoom-1....

OpenWatcom is under a license that isn't considered free enough under the FSD/OSD/DFSG.

https://github.com/open-watcom/open-watcom-v2/blob/master/li...

Digital Mars C/C++ is Boost licensed.

Is that able to build 16-bit x86 code, including near/far pointers, like the VirtualBox BIOS uses?

https://www.virtualbox.org/ticket/12011

DMC++ can built 16 bit x86 code with near and far pointers, and near and far functions.

Does DMC++ run on Linux? Or just Windows?

It runs under Windows, cross compiling for DOS. People have told me it runs fine under Wine, though I haven't tried it myself.

It could be made to run on Linux without Wine, there's nothing in particular nailing it to Windows.

Hmm, I guess the VirtualBox BIOS needs to be compiled for bare metal rather than running on DOS.

Sounds like DMC++ would need porting to run on Linux though.

OSI considers it valid[0]. The issue FSF has[1] is a requirement for publishing source code which IMO is very underspecified (i mean FSF's issue, not the license's which seems to not be anything special). I can't see how exactly that makes the license non-free, if anything it ensures the source will be available. The issues DFSG had can be found here[2] but they're also not something that would be an issue in practice for the compiler itself - the most practical issue would be the requirement to provide the code for a year but in practice OWv2 is published via GitHub anyway (and i doubt if it moved anywhere else anyone involved would say "no" if asked to provide sources in case they somehow become inaccessible to the entire internet before a year passes).

Also none of those are "not free enough" (FSF claims so but it doesn't seem to explain why) and they're really about the license itself, not how it applies in practice to OpenWatcom.

[0] https://opensource.org/licenses/Watcom-1.0

[1] https://www.gnu.org/licenses/license-list.html#Watcom

[2] https://lists.debian.org/debian-legal/2006/07/msg00014.html

TK Chia and others have been working on adding DOS C/C++ compiler-isms to GCC as well as improving the the codegen to make it more hospitable for DOS apps. So far, the FreeDOS kernel compilable by gcc-ia16.

https://github.com/tkchia/gcc-ia16

It's more than that. It's also supporting the 16 bit Windows calling conventions, __ss pointers, __cs pointers, __huge pointers, etc. There's also dealing with chips that don't have an x87 processor.

Deming said...“In God we trust; all others must bring data”.

Sagan said..."extraordinary claims require extraordinary evidence".

It must be though to be Walter Bright on HN. He wrote the compiler himself. he wrote dlang. He has been in this game for a lifetime. He would know, right?

I don't think he is the boasting type, even though he has enough reasons to boast… being the only person that ever wrote a C++ compiler by himself and all.

One thing people should be aware of, is that C++ exceptions and RTTI are unworkable for a 16 bit target. Those have to be disabled for 16 bit code gen.

The reason is pretty simple - all the support code would exceed 640K. You wouldn't get past a demo program.

Templates work, but you have to be pretty cautious in avoiding template bloat. Probably better off just avoiding them.

Also remember that he says for DOS not any target. Digital Mars is incredibly old but that makes it perfect for DOS.

The backend is also used for the DMD D compiler.

I have a lot of respect for Walter Bright. And I agree, he's typically not boastful without good evidence. Walter is also very accomplished. However, DigitalMars compilers on DOS haven't been popular in a very long time. And if there are some good tricks or some sort of advantage to using them for building and maintaining DOS apps and FreeDOS, then there would be a few people interested in exploring & understanding that.

The main cause of that is I was slow to make the compiler open source. It is open source now.

https://github.com/DigitalMars/Compiler

Reply on news.ycombinator.com