DOS ain't dead

On May 18, David Lindauer updated his Orange C compiler suite to 5.03, both for Win32 and DOS (386+) via HX. The license is BSD-ish (see berkely.lic).

Download: http://ladsoft.tripod.com/orange_c_compiler.html

P.S. This also means the page URL for CC386 (and everything else) has apparently changed, though that still sits at 4.10, but no (other, more recent) changes there. I've updated FreeDOS' online .LSM to this: http://ladsoft.tripod.com/cc386_compiler.html

> David Lindauer updated his Orange C compiler suite to 5.03

It's hell buggy ... I'm just discussing the BUG's with David

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

> > David Lindauer updated his Orange C compiler suite to 5.03
>
> It's hell buggy ... I'm just discussing the BUG's with David

"
The source code is now on GITHUB. UserName: LADSoft RepositoryName: OrangeC

This compiler is at version 5.0.4.
Release Date 5/25/2013.
"

> The source code is now on GITHUB

The "dead" CC386 got updated ... what's new in 4.11 : ???

http://ladsoft.tripod.com/cc386_compiler.html

OCC 5.0.5 is out too:

http://ladsoft.tripod.com/orange_c_compiler.html

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

> > The source code is now on GITHUB
>
> The "dead" CC386 got updated ... what's new in 4.11 : ???
>
> http://ladsoft.tripod.com/cc386_compiler.html

It seems it doesn't like "/9" and "+A" mixed anymore. (Actually, that's confusing anyways, so I need to double-check that. Seems I used to do "cl386 /9 +A", but that doesn't work anymore. Maybe "+A" only means pure C89?)

Honestly, the real oddity is the CX*.ZIP package. I haven't been using that lately (only the main CCDL*E.ZIP DOS installer file), and apparently neither has he! The internal CC.ZIP inside there is md5sum identical between 4.09, 4.10, 4.11. It's dated 2012, so perhaps his personal makefiles are buggy?

EDIT: "Dead" is a harsh word. There is some partial overlap between the two toolsets. But it's obvious he's only doing active work on OrangeC as, unlike CC386, it supports C11 (and eventually C++).

What's new:

- Reportedly fixed DPMI bug in OCC (test pending)
- Fixed OCC / C++ / Win32 INFOPAD (test pending)

- Fixes in CC386 including the "dead" ZIP
- CC386 History file says "occ" but should be probably "CC386"
- CC386 / DOS32A INFOPAD not fixed, still from 2011

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

> What's new:
>
> - Reportedly fixed DPMI bug in OCC (test pending)

Dunno, I haven't updated to latest yet, but it does (did) have some invalid memory access bug.

> - Fixes in CC386 including the "dead" ZIP

Untested but looks okay.

> - CC386 History file says "occ" but should be probably "CC386"

Yeah, he's probably overwhelmed.

BTW, in CC386 4.12, I now get a spurious error about my macro (POP2) lacking a prototype. In reality, the bug is with the preprocessor, e.g. "case '\\': POP2(..." is misunderstood (but changing to "case 0x5C:" works around it).

I'm not sure if you really want me reporting bugs through you like this, but ....

> BTW, in CC386 4.12, I now get a spurious error about my macro (POP2)
> lacking a prototype. In reality, the bug is with the preprocessor, e.g.
> "case '\\': POP2(..." is misunderstood (but changing to "case 0x5C:" works
> around it).

"
This compiler is at version 4.13.
The Release date is June 10,2013.
"

> V4.13: 06/10/13
> cc386: make __DATE__ work like asctime as per the spec
> cc386: adjust how floating point input is done
> cc386: more preprocessor fixes, make cyassl compile again

> > cc386: make __DATE__ work like asctime as per the spec

what's the difference ?

OCC 5.0.7 2013-Jun-16 (fixed DPMI BUG and more)
CC386 4.14 2013-Jun-16

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

CC386 4.15 is out. "SuccessfulRelease" = false (waiting for 4.16, patch sent)

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

> CC386 4.15 is out. "SuccessfulRelease" = false (waiting for 4.16, patch
> sent)

Why, what happened? (I've been unable to test again just yet.) Perhaps he needs a better test suite? What would be good projects: Lua? Csed? It's hard to think of some reliable sources that are worth testing (esp. since most everything is too heavily POSIX or Windows based these days).

BTW, TinyC had a big update recently (after a few years of no releases). At least the previous version "mostly" worked under HX with (older) ReactOS 0.3.14 MSVCRT.DLL (set DPMILDR=128):

> (Feb 15, 2013) TCC version 0.9.26 is out thanks to Thomas Preud'homme
> (Changelog). Summary of the changes:
>
> * Support for C99 VLA
> * Generation of make dependencies (-MD/-MF)
> * Support improved for various architectures (x86-64, arm, OSX,
> WinCE, kFreeBSD, Hurd)
> * A bunch of bug fixes

http://download.savannah.gnu.org/releases/tinycc/

tcc-0.9.26-win32-bin.zip 15-Feb-2013 15:22 386K
tcc-0.9.26.tar.bz2 15-Feb-2013 15:11 514K

> tcc-0.9.26-win32-bin.zip
> 15-Feb-2013 15:22 386K
> tcc-0.9.26.tar.bz2
> 15-Feb-2013 15:11 514K

Nice compiler package, I didn't know about this. But my quick test revealed problem with attribute packed doesn't work (struct. that has to be 6B was 8B due to alignement). Maybe it uses different syntax.

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

> Nice compiler package, I didn't know about this. But my quick test revealed
> problem with attribute packed doesn't work (struct. that has to be 6B was
> 8B due to alignement). Maybe it uses different syntax.

IIRC, yes, in TinyC it only works on individual structure members.

The online manual is outdated, but it lists this (under Section 3.3 GNU C extensions):

"The keyword __attribute__ is handled to specify variable or function attributes.

packed: force alignment of a variable or a structure field to 1.
"

Here's my simple test:

#include <stdio.h>

#define get_gdt(gdtr) asm __volatile__ ("sgdt %0" : "=m" (*gdtr) : : "memory") // precte obsah GDTR registru [mem48]

typedef struct {                       // 48-bit adresa GDT/IDT
  short unsigned int limit;            // size limit of GDT [Bytes-1]
  unsigned long base;                  // linear base address of the GDT in physical memory
} __attribute__((packed)) GDTR;

int main(void)
{
  GDTR gdtr;
  printf("\nSimple Compiler Test, GCC version: %s\n", __VERSION__);
  printf("size of char:        %u Bytes\n", (int)sizeof(char));
  printf("size of short int:   %u Bytes\n", (int)sizeof(short int));
  printf("size of int:         %u Bytes\n", (int)sizeof(int));
  printf("size of long:        %u Bytes\n", (int)sizeof(long));
  printf("size of long long:   %u Bytes\n", (int)sizeof(long long));
  printf("size of size_t:      %u Bytes\n", (int)sizeof(size_t));
  printf("size of void *:      %u Bytes\n", (int)sizeof(void *));
  printf("size of float:       %u Bytes\n", (int)sizeof(float));
  printf("size of double:      %u Bytes\n", (int)sizeof(double));
  printf("size of long double: %u Bytes\n", (int)sizeof(long double));
  printf("size of GDTR:        %u Bytes (should be 6 Bytes)\n", (int)sizeof(GDTR));
  get_gdt(&gdtr);
  printf("GDT base: %lXh, limit: %Xh\n", gdtr.base, gdtr.limit);
  return(0);
}


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

> Here's my simple test:
>
> typedef struct {
> short unsigned int limit;
> unsigned long base;
> } __attribute__((packed)) GDTR;
>


#define PACKED __attribute__((packed))

typedef struct {
  short unsigned int limit PACKED;
  unsigned long base PACKED;
} GDTR;


(Though "long double" still won't match, but that's a separate issue. I don't think the standard guarantees it to always be wider than "double". IIRC, OpenWatcom and MSVC only support it same as "double", though obviously GCC does more.)

>
> #define PACKED __attribute__((packed))
>
> typedef struct {
> short unsigned int limit PACKED;
> unsigned long base PACKED;
> } GDTR;
>

Well this is tested? I used it for old GCC (2.9?), later it was possible to use only one 'packed' for entire struct instead of all members (maybe this old form became deprecated and ignored, not sure). so I update my code. Anyway good to know TCC can do pack.

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

> Well this is tested?

Yes, I tested Cygwin (32-bit GCC 4.5.3) and latest TinyC. Except for "long double", the sizes matched.

> I used it for old GCC (2.9?)

I did not test a bunch of other GCCs (as most of mine are DOS-based and this was done on silly Win64). I was only mainly interested in showing what I remembered, that for TinyC you have to declare each field as packed explicitly. TinyC does a lot for GCC compatibility but of course it can never be 100% and such probably isn't high priority.

> later it was possible to use only one 'packed' for entire struct
> instead of all members (maybe this old form became deprecated and
> ignored, not sure). so I update my code.

Yes, I know GCC supports it; however, TinyC does not (though you could argue that calling it "GNU C extensions" but not fully supporting it is woefully incomplete).

> Anyway good to know TCC can do pack.

Yes.

> that for TinyC you have to declare each field as packed
> explicitly. TinyC does a lot for GCC compatibility but of course it can
> never be 100% and such probably isn't high priority.

Yes I tested and it worked.

BTW TCC boasts how fast it can compile over GCC but is there some comparison of speed of resulting code? What advanced instructions it can use? MMX/SSEx/AVXx?

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

> BTW TCC boasts how fast it can compile over GCC but is there some
> comparison of speed of resulting code? What advanced instructions it can
> use? MMX/SSEx/AVXx?

I don't know. Even if I was familiar with older versions, it has probably changed in the meantime. For instance, 64-bit support probably prefers SSE, but the 32-bit one is most likely just x87 only. MMX is deprecated by almost everyone, and AVX is too new (and relatively rare, you need a 2011-era machine or newer.)

As far as compiled code speed, it's not as good as GCC. TinyC is (IIRC) a one-pass, all-in-one compiler + assembler + linker tool. It does some basic optimizations, but there was some lack of register use, perhaps it didn't schedule or didn't reload or maybe didn't even use some registers ever. Probably the only way to know for sure is compile to .o (ELF? apparently, yes, even for Win32 target) and disassemble, e.g. "objdump -M intel -d" or "objconv -fnasm" or whatever. For a simple example, I don't see any use of EBX, ESI, EDI at all. (Though I do see x87 and SSE, respectively, for float stuff.)

I don't know the details, but I'll quote the docs for you.

http://www.bellard.org/tcc/tcc-doc.html

> The TCC code generator directly generates linked binary code in one pass.
>
> The TCC code generator is register based. Optimization is only done at the
> expression level. No intermediate representation of expression is kept
> except the current values stored in the value stack.
>
> On x86, three temporary registers are used. When more registers are
> needed, one register is spilled into a new temporary variable on the stack.
>
> Constant propagation is done for all operations. Multiplications and
> divisions are optimized to shifts when appropriate. Comparison operators
> are optimized by maintaining a special cache for the processor flags.
> &&, || and ! are optimized by maintaining a special 'jump target' value.
> No other jump optimization is currently performed because it would
> require to store the code in a more abstract fashion.

OK, thx. I wouldn't expect it can do some heavy opts like GCC. It may be handy for some small tools...

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

> CC386 4.15 is out. "SuccessfulRelease" = false (waiting for 4.16

CC386 4.17 is out. Minimal test: can't find anything exceptionally malicious

OCC unchanged: 5.0.7 2013-Jun-16

http://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/cc386/

http://ladsoft.tripod.com/index.html


Copyright (C) LADSoft, 2013
Version: 2.0.1.0
Date: Jun 25 2013
Time: 20:12:05


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

> This compiler is at version 4.18.
> The Release date is October 3,2013.

> This compiler is at version 5.0.9
> Release Date Decembler 1, 2013.

What's new:

> occ: fix problem with two labels in a row generating errors
> occ: fix crash with forward declared labels in inline assembler

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

http://ladsoft.tripod.com/cc386_compiler.html

This compiler is at version 4.19.
The Release date is January 18, 2014.

What's new (from RELNOTES.DOC):

v4.19:
ccide: handle adding files without extensions without crashing
ccide: add an extension to newly added files automatically

> > This compiler is at version 4.20.
> > The Release date is January 21, 2014.
>
> > This compiler is at version 5.0.10.
> > Release Date March 29, 2014.
>
> What's new:
>
> v4.20:
> ccide: Support windows 8



> version 5.0.10: 3/29/14
> misc: various code cleanup and improvements suggested by Kirill Joss
> misc: include dlea allocator in most C++ apps (borland compile only) this helps speed it up
> occ: inlining functions that took the address of parameters was broken
> occ: fixed bug with optimizing of inlined functions generating incorrect code
> occ: fix so that external references will show up in the output file when included with a C++ using directive
> occ: fix bug where debug info of arrays was wrong
> occ: fix basic types in debug information
> occ: fix bug in register allocation that may speed up the compile
> occ: fix problem with generating DOUBLE sized constants for negative FLOAT constants
> occ: fix some error messages
> ogrep: fix crash under some circumstances
> olib: fix bug that caused libraries to be generated incorrectly, this will probably also speed up links
> olink: fix bug where a debug info table that didn't exist was referenced
> ocide: fix find dialog to not crash when invoked
> ocide: after debugging, a build would not work (said file in relative format)
> ocide: show types in watch window correctly
> clibs: fix fputc and friends to match const correctness in headers
> clibs: remove some shellapi stuff from the main windows headers
> build: remove all references to PEPATCH