Xref: utzoo comp.sys.amiga:16421 comp.sys.amiga.tech:83
Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!pasteur!agate!eris!mwm
From: mwm@eris (Mike (My watch has windows) Meyer)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: code differences between manx and lattice
Message-ID: <7873@agate.BERKELEY.EDU>
Date: 21 Mar 88 20:03:05 GMT
References: <9457@sunybcs.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: mwm@eris.UUCP (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Lines: 73
Keywords: a lexicl analyser to make them "interchangable"

In article <9457@sunybcs.UUCP> ugmiker@sunybcs.UUCP (Michael Reilly) writes:
<	 What I wanted to know, is how different is the code needed
<for each compiler to get the "same" output. 

That is, in general, a "hard" problem. For many reasons. I think that
on current releases of the compilers, the actual language swallowed by
the two compilers is nearly identical. Differences are:

1) Prototypes: Lattice has them, Manx doesn't yet. A conversion
program should detect them, and comment them out. Needs to be disabled
for people who have Manx with prototypes.

2) Default integers sizes: Manx is 16 bits, Lattice is 32. 32 bit ints
leads to "sloppy" code that passes ints without casting them to the
correct types. Prototyping fixes this, in that it implicitly does the
cast. Without prototypes, these are bugs. Fixing them with prototypes 
requires keeping track of the types of all prototyped functions, and
casting arguments if required.

3) Include files: Manx calls their list of all Amiga functions
"functions.h". Lattice calls theirs "proto/all.h". This can be fixed
by creating a copy of the existing include file with the other name.
For pre-4.0 Lattice, there's no "proto/all.h". Creating an empty file
works.

Also, Manx pre-compiled headers allow the programmer to get away with
some incredibly grotesque include sequence. Checking for multiple
includes would be nice. Being able to detect missing includes is
harder (in general, impossible) but needed.

3) Libraries. Here's the catch. Lattice went with SysV/ANSI libraries,
and Manx went with 4BSD libraries. This can be fixed with an include
file with macros to provide new names and mabye swap arguments around
(string routines are the classic example), and a library of routines
for routines that don't have quite the same behavior.

The trouble here is that the set of library routines for the compilers
is changing with each release. Lattice is committed to having an ANSI
compliant compiler ASAP after the real release. I vaguely recall
hearing that Manx will go the same way, though probably somewhat
slower.

4) Bugs. I think mg1b still has an incredibly baroque piece of code in
it that avoided bugs in character arithmetic in Lattice and Manx -
different bugs in each compiler! Bugs change from release to
release, and get fixed with patches from the releases. The general
case is that you see pathalogical code. It's not clear what to do
about them, except for ignoring them.

You see what the problem is - it isn't going from Lattice -> Manx,
it's goin from Lattice X.Y -> Manx Z.W. Since code that worked with
one version of a compiler may not work with another, this also changes
from release to release of each compiler.

On the other hand, things aren't as bleak as I make them appear.
Carefully written code can be ported from one compiler to the other
without to much trouble. Mostly you have to tweak in/out the "#include
<functions.h>", and prototypes. What's left is library calls.  Having
access to the other compiler manual makes it simple to figure out
exactly what's going on if it's not clear from context. Providing the
routines as a global macro or a function somewhere is then
straightforward.

Now, all you have to do is write a program that takes
"random-piece-of-crappy-code-from-the-net" and turns it into carefully
written code :-). That's harder, but more worthwhile...

	<mike
--
Love and affection,					Mike Meyer
Of the corporate kind.					mwm@berkeley.edu
It's just belly to belly,				ucbvax!mwm
Never eye to eye.					mwm@ucbjade.BITNET