I did a quick and dirty comparison between Microsoft Quick C and Open Watcom.

Running some nested for loops, totaling 1,000,000 loops, both executables took 9 seconds on my test machine. An interesting result given that the same program executes with wildly different speeds on various BASIC compilers (MS Quick Basic, Power Basic, FreeBasic, QB 7.1 PDS, with FB being by far the fastest by orders of magnitude).

The executable sizes were a different story, however - the Open Watcom exe was a couple of kilobytes. The MSQC executable was, I think, about 18K or thereabouts. This is compiling the same exact program and include stdlib, stdio, and dos.h.

keenmaster486 wrote:

The executable sizes were a different story, however - the Open Watcom exe was a couple of kilobytes. The MSQC executable was, I think, about 18K or thereabouts. This is compiling the same exact program and include stdlib, stdio, and dos.h.

a most simple program that hardly does anything compiled with djgpp takes hundreds of kilobytes.

noshutdown wrote:

keenmaster486 wrote:

The executable sizes were a different story, however - the Open Watcom exe was a couple of kilobytes. The MSQC executable was, I think, about 18K or thereabouts. This is compiling the same exact program and include stdlib, stdio, and dos.h.

a most simple program that hardly does anything compiled with djgpp takes hundreds of kilobytes.

Older djgpp versions aren't quite as bad as that - my circa-2001 DJGPP install with gcc 2.9.x creates a hello world C program that's 48k stripped. Not as bad as the significantly larger executables produced by the gcc 5+ versions of DJGPP, but still pretty bloated compared to the 8K executable that Turbo C produced on the same code.

keenmaster486 wrote:

I did a quick and dirty comparison between Microsoft Quick C and Open Watcom.

Running some nested for loops, totaling 1,000,000 loops, both executables took 9 seconds on my test machine. An interesting result given that the same program executes with wildly different speeds on various BASIC compilers (MS Quick Basic, Power Basic, FreeBasic, QB 7.1 PDS, with FB being by far the fastest by orders of magnitude).

you need more complicated programs to show the true performance of compilers.
i once wrote a simple program like this:

1short a=0, b[2]={1,-49}
2for (long c=0;c<=0x3fffffff;++c)
3    a+=b[a==49]; //(a==49) ? a=0 : ++a;

it finished in an instant, which couldn't be clocked by 1 millisecond.
but once i add "cout<<a;" at the end, it took several seconds.
that indicates that the compiler cheated by cutting out useless operations that have no impact on output.
but still, freebasic has an advantage for being 32bit.

Damaniel wrote:

Older djgpp versions aren't quite as bad as that - my circa-2001 DJGPP install with gcc 2.9.x creates a hello world C program that's 48k stripped. Not as bad as the significantly larger executables produced by the gcc 5+ versions of DJGPP, but still pretty bloated compared to the 8K executable that Turbo C produced on the same code.

true but i use gcc 3.4.6 and helloworld compiles to ~700kb by default, removing debug info only strips down to ~420kb.

What freaking use is that?! Largest executable program size is <600K usually!! Dumb!

You all are comparing apples to oranges. Djgpp will ALWAYS produce protcted mode programs, and needs to bring a DOS extender and POSIX compatibility library with its runtime. Also comparing the minimal program size is sort of moot as it AT MOST shows the kind of inherent overhead a certain compiler/runtime combination brings. However this overhead might vanish for larger programs when unused functions in this overhead suddenly are needed and get linked in both compilers.

Another point is that even in real mode you can make programs larger than 600 KiB since you can utilize overlays to swap out unused parts of the program. So all these comparisons have to be taken with a grain of salt.

Damaniel wrote:

Older djgpp versions aren't quite as bad as that - my circa-2001 DJGPP install with gcc 2.9.x
creates a hello world C program that's 48k stripped. Not as bad as the significantly larger executables produced by the gcc 5+
versions of DJGPP, but still pretty bloated compared to the 8K executable that Turbo C produced on the same code.

Seriously ? 😳 Power C creates a simple Hello World with less than 3KB (EXE, not just COM).
Perhaps GCC uses some additional layers or embedds a runtime ? 😕

Edit: @root42 Thanks for the explanation. These file sizes are still enormous, though, if you've got an XT with 360KB/720KB drives only.. 😉
In that case, for file transfer, these files can be properly compressed hopefully. 😀

keenmaster486 wrote:

What freaking use is that?! Largest executable program size is <600K usually!! Dumb!

DOS usually ignores debug information when loading an executable. The EXE header tells DOS how much of the file it has to load into memory. And protected-mode programs pretty much always contain a real-mode stub that sets up protected mode and loads the rest of the program. DOS itself only loads the stub, which should be far less than whatever maximum executable program size DOS reports on your system. I strongly doubt that such a 700kb or even a 420kb executable generated by gcc would be a real-mode program.

Jo22 wrote:

Edit: @root42 Thanks for the explanation. These file sizes are still enormous, though, if you've got an XT with 360KB/720KB drives only.. 😉
In that case, for file transfer, these files can be properly compressed hopefully. 😀

Thing is that djgpp does not emit code for XT or even AT class machines. Only 386 protected mode an up. So program size is really not that big a deal.

I don't think any regular version of GCC can compile code for 286 or earlier. There is a hack to generate 16-bit code, but only with 386+ instruction afaik.
There have only been some experimental 8086 versions of GCC, never finished.
The latest one is the GCC fork by reenigne: https://blogs.mentor.com/embedded/blog/2017/0 … -lite-for-ia16/

Scali wrote:

I don't think any regular version of GCC can compile code for 286 or earlier. There is a hack to generate 16-bit code, but only with 386+ instruction afaik.
There have only been some experimental 8086 versions of GCC, never finished.
The latest one is the GCC fork by reenigne: https://blogs.mentor.com/embedded/blog/2017/0 … -lite-for-ia16/

i am also curious on whether gcc ever supported 16bit cpus.

noshutdown wrote:

i am also curious on whether gcc ever supported 16bit cpus.

Not x86-based ones I suppose. GCC comes from the UNIX world, and its first version is from 1987. By the time x86-use in the UNIX world became commonplace, they were 386 or higher.
There's only a handful of UNIX versions for 16-bit x86, and they predate GCC, so they would have used alternative compilers.

noshutdown wrote:

i am also curious on whether gcc ever supported 16bit cpus.

Motorola 68000 was supported for quite a long time. However the main problem with x86 16 Bit platforms was their lack of an MMU and/or a flat memory model. Hence memory addressing was pretty weird and also prohibited useful implementations of Linux et al to be ported. Thus there was never much drive to develop a working 16 bit gcc.

root42 wrote:

Motorola 68000 was supported for quite a long time.

The 68000 is basically a 32-bit ISA with a 16-bit implementation though. Which is why it has a 32-bit registers and a 32-bit flat memory model, and a lot less headache for compiler writers.

Scali wrote:

root42 wrote:

Motorola 68000 was supported for quite a long time.

The 68000 is basically a 32-bit ISA with a 16-bit implementation though. Which is why it has a 32-bit registers and a 32-bit flat memory model, and a lot less headache for compiler writers.

I heard that was what gave the Atari ST it's name, too. It was said ST did stand for Sixteen-Thirty-two..
From what I remember, there's one notable stumbling stone, as far as development was concerend, that I remember the Amiga manual warned about..
The 68010 and later chips of the M68k series threaded the "MOVE from SR" (?) instruction differently as the original chip.

openwatcom is great for compiling to 8086/80286 with the -0 or -2 flag. But it has to run on a 386. But you get a more modern C support than the free versions of say, Turbo C/C++ from Borland. Honestly a more up to date C compiler is MUCH nicer than the old turbo c/quick c stuff.

you can tell watcom not to use stdlibs and you can write a hello world in a few bytes (95 bytes with exe header because openwatcom does not generate model tiny like 10.6 did).

arguing GCC/DJGPP on does doesnt produce small files is stupid. DJGPP cant product real mode 16bit code it produces pmode code with an extender.

for my 95 byte watcom test;

1extern void print(char far *s);
2#pragma aux print = \
3	"mov ah,9" \
4	"int 021h" \
5	modify [si ax] \
6	parm [ds dx];
7
8extern void exit(unsigned char errorlevel);
9#pragma aux exit = \
10	"mov ah,04cH" \
11	"int 021h" \
12	parm [al];
13
14void main(void)
15{
16	print("Hello World\n\r$");
17	exit(0);
18}

compile + link with

1wcc -zu -d0 -zls -ecc -0 -zl -s x.c -ml -oneatx
2wlink file x.obj op {dosseg nodefaultlibs stack=1024 map=x.map start=main_} name x.exe

BloodyCactus wrote:

openwatcom is great for compiling to 8086/80286 with the -0 or -2 flag. But it has to run on a 386.

But then why use a 386, when you can use 486/Pentium/2/3/4 with Windows 9x or even XP for better performance and interoperability, and still be able to run those 286 applications.

Azarien wrote:

But then why use a 386, when you can use 486/Pentium/2/3/4 with Windows 9x or even XP for better performance and interoperability, and still be able to run those 286 applications.

Or just use Watcom in Windows 10, and run the programs via DOSBox (Windows command prompt only has very limited DOS compatibility. Hardware tricks involving timers, DMA, direct CGA/EGA/VGA register access etc doesn't work properly).

Azarien wrote:

BloodyCactus wrote:

openwatcom is great for compiling to 8086/80286 with the -0 or -2 flag. But it has to run on a 386.

But then why use a 386, when you can use 486/Pentium/2/3/4 with Windows 9x or even XP for better performance and interoperability, and still be able to run those 286 applications.

No, he's talking cross compilation here. The compiler only runs on 386 or better. But the executable will run on 8088 or 80286.