Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site omen.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!reed!omen!caf
From: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Newsgroups: net.micro.pc
Subject: Re: Re Microsoft vs. Lattice
Message-ID: <229@omen.UUCP>
Date: Wed, 28-Aug-85 07:37:13 EDT
Article-I.D.: omen.229
Posted: Wed Aug 28 07:37:13 1985
Date-Received: Sat, 31-Aug-85 05:09:55 EDT
References: <1354@drux3.UUCP>
Reply-To: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Organization: Omen Technology, Portland
Lines: 31
Summary: 

A few points to keep in mind:

The object file formats are NOT compatible between Xenix and DOS.  The
.o files used on Xenix cannot be linked by the DOS linker, and DOS style
.obj files don't mix with ld.  It also appears impossible to take files
from the Xenix libraries to fill in for missing routines in the DOS
cross libraries.

My documentation claims SI and DI are saved by every function call and
always returned.  But, the optimizer sometimes takes out the saves
and resotres.


MSC does not include any source code, not even to the startup routine.
If your application needs something special in the way of stack setup,
etc., you're stuck with Lattice.

The MSC code density advantage is strongest with small model programs.
A huge model 32 bit int "version" of the siev.c benchmark takes 252
bytes with Lattice C and 271 bytes with MSC.  I don't know what the
state of the Lattice large model compiler is, but I have yet to see
a program longer than a couple of pages compile and execute properly
with MSC's huge model on the Xenix system.


-- 
  Chuck Forsberg WA7KGX   ...!tektronix!reed!omen!caf   CIS:70715,131
Omen Technology Inc     17505-V NW Sauvie Island Road Portland OR 97231
Voice: 503-621-3406     Modem: 503-621-3746 (Hit CR's for speed detect)
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
Home of Professional-YAM, the most powerful COMM program for the IBM PC