Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!amdahl!kim
From: kim@amdahl.UUCP
Newsgroups: comp.sys.amiga
Subject: Portable "C" Code
Message-ID: <6082@amdahl.UUCP>
Date: Wed, 1-Apr-87 16:58:19 EST
Article-I.D.: amdahl.6082
Posted: Wed Apr  1 16:58:19 1987
Date-Received: Sat, 4-Apr-87 08:23:27 EST
Organization: Amdahl Corporation,  Sunnyvale, CA 94086
Lines: 77
Keywords: portable code c manx lattice guidelines religion style


[ For all you do ... this line's for you ... ]

I'm posting this for Robert Mitchell here at Amdahl.  I've run
into similar problems, but never really organized my thoughts
on the subject.  Seems like a topic worthy of some discussion
here on the net.  Note that I'm NOT cross-posting this to comp.lang.c
since we're talking about dealing with two specific Amiga compilers,
and not writing portable code in general.

/kim


From Robert Mitchell:

    Leo Schwab is one of the most creative and productive
    people on the net.  I really like what he did with
    ROBOTROFF.
     
    Converting it to Lattice, however, was painful.
    Porting software between compilers within the Amiga
    architecture can be (relatively) easy if authors
    follow some basic guidelines.
    There seem to be two primary problems in the Manx-to-Lattice
    (or vice-versa) translation:
     
      1) Manx defaults to 16 bit integers and Lattice uses 32 bit.
      2) Assembly language subroutines in Manx expect 16 bit
         integer parameters, while Lattice promotes to 32 bit.
     
    Use of the following conventions would make porting (and debugging)
    MUCH easier:
     
      1) Do not type functions as returning "void *".  Not
         only do we lose compiler type checking, it makes it
         harder for us Amiga novices to understand the code.
     
      2) Amiga data structures frequently use "UWORD" types
         for unsigned 16 bit integers.  NEVER cast these as (int);
         use (short) for math computations.  This guarantees
         sign extension for fields like "spr.x" which is "UWORD".
         Why unsigned integers contain negative numbers
         is an area I have not explored.
     
      3) Be extremely careful about type matching when using
         call by reference; the compiler can not help.
         "startxy(&spr.x,&spr.y)"  causes memory overlays
         when the function declares these as integers.
     
      4) Assembly language subroutines will always take some
         re-write because of the parameter passing differences.
         It would be preferable to code functions such as
         "rnd.asm" in "C", even at the cost of execution time.
         It would then port nicely.
     
      5) It would help a lot to get rid of excess warning messages
         by typing local subroutines with no return codes as "static void".
         This also cuts down on the number of external labels.
         This one is just my bias, and is not directly related
         to porting.
     
    I hope this is of some use.  I am certainly not finding fault
    with contributed software, and these reflect only my opinions.
     
    Robert Mitchell
    (408) 746-8491


-- 
UUCP:  kim@amdahl.amdahl.com
  or:  {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim
DDD:   408-746-8462
USPS:  Amdahl Corp.  M/S 249,  1250 E. Arques Av,  Sunnyvale, CA 94086
CIS:   76535,25

[  Any thoughts or opinions which may or may not have been expressed  ]
[  herein are my own.  They are not necessarily those of my employer. ]