News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

CWARE CORP. ?

Started by BrWarburto, March 19, 2006, 11:45:15 AM

Previous topic - Next topic

BrWarburto

Some years ago, in Paolo Alto, Calif., USA there was a software house called Cware who issued some very interesting 16-bit software.
There was a good 'C' compiler called PCC and an assembler called PCCA. By the late ninties, they seemed to have disappeared? Does anyone know if they relocated somewhere, or just vanished?


BrWarburto

PS I am more regular in the GoAsm Forum

MichaelW

A quick search found this (here):
Quote
DeSmet C
Here's a compiler to conjure with: high performance in a well thought-out package at a low cost. DeSmet C is, to the 16-bit CP/M-86 and MS-DOS world, what BDS C was (is?) to the 8-bit CP/M-80 user. That is, if offers adequately high performance, relaibility and full functionality at a price attractive to hackers, and is good enough for a lot of quick and dirty and small systems work.
DeSmet C, from CWare, is supplied on four disks which contain a comprehensive collection of software and utilities. Apart from the compiler itself, which operates in two passes (parser and code generator), there is also an assembler (which doubles as pass three of the compiler), linker (called BIND), libraries and various header files. So far, all as expected - but the fun has barely begun!
Also supplied on the disks are a full-screen editor, librarian, symbolic source code debugger, profiler, VDISK program, source code comparator program and various utilities and example programs. These are no lightweight utilities, either, as a brief experiment will show.
The compiler is a fairly straightforward affair, lacking the support for ANSI features which the more expensive compilers boast. Such features include structure assignment, enumerated types and bit fields. I have mixed feelings about this: if this older dialect of the C language was good enough to write the UNIX operating system in, then it ought to be good enough for most of us. Certainly, I've managed without such 'fancy' additions for a long time now - but I suspect my code might look better with their use.
The DeSmet compiler supports only small memory model - that is, one code segment and one data segment. This is adequate for many applications. For applications which require more code, DeSmet provides one work-around in the form of an overlay manager which will allow the programmer to place multiple overlays into the .EXE file and load them as required. This is good for small memory systems also (remember them?). Alternatively the overlays can be permanently loaded into memory for best speed.
The output of the compiler is a .O file in a proprietary object format. Actually, the output of the compiler is really assembler which is passed to the assembler directly and it is the assembler which produces the .O file. This means that it is possible for the programmer to insert assembly source in the C program source file, preceded by the #asm 'preprocessor directive'. The assembler is fairly plain vanilla, with no support for macros, codemacros or any of the other goodies to be found in MASM. On the other hand, the only use for this assembler is to write very short routines to perform functions like accessing the IBM PC ROM BIOS and the like.
The compiler provides good support for DOS functions like chain(), exec() and others, and also has functions for IBM PC screen and keyboard access.
The editor, see, is quite powerful and easy to customise for non-IBM hardware, since the source code for the screen driver component is supplied in source code form and can be bound to the object version of see provided. Other utilities (like the debugger) use the same screen driver. See has quite adequate facilities, including the ability to create macros, auto-indent and even automatic auto-indent following a { character.
Two libraries are provided, one with software floating point support and one with 8087 code. It was not clear from my (admittedly brief) reading of the documentation whether the 8087 code is in-line or uses subroutine calls.
The debugger is a source-code type which operates in the same way as see, with a Lotus-style menu across the top of the screen. The compiler and linker can include symbol-table information in the generated code, which is picked up by the D88 debugger to allow display of source code, values of variables and expressions, including arrays and structures. Screen flipping (from debugger to program output) is supported on the I
The profiler is quite a neat idea; triggered off the system clock, it simply collects the current value of the program counter and increments the count in one of 1024 buckets which produce the performance histogram.
Documentation is on the flimsy side, but is nonetheless fairly complete, extending even to a description of the 8086 and 8087 instruction sets.
The benchmark timings reveal that the DeSmet compiler is no slouch, being just behind the Microsoft compiler in performance, at a considerably lower price.
A particularly attractive 'feature' of the DeSmet package is the way that it has started to attract public domain support. A brief look through the libraries of the C Users Group, for example, reveals that the majority of recently contributed programs were written using this compiler.

And this:

http://www.desmet-c.com/
eschew obfuscation

BrWarburto

Michael,  Many thanks for your rapid & comprehensive reply. Very interesting.

BrWarburto