Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!well!ewhac From: ewhac@well.UUCP Newsgroups: comp.sys.amiga Subject: Re: Portable "C" Code Message-ID: <2865@well.UUCP> Date: Sat, 4-Apr-87 00:00:32 EST Article-I.D.: well.2865 Posted: Sat Apr 4 00:00:32 1987 Date-Received: Sun, 5-Apr-87 09:59:29 EST References: <6082@amdahl.UUCP> Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) Organization: Whole Earth 'Lectronic Link, Sausalito, CA Lines: 118 Keywords: portable code c manx lattice guidelines religion style Summary: The object of the posting replies. In article <6082@amdahl.UUCP> kim@amdahl.UUCP (really Robert Mitchell) writes: > >[ For all you do ... this line's for you ... ] > >I'm posting this for Robert Mitchell here at Amdahl. [ ... ] > >From Robert Mitchell: > At last. Some comments on the quality of my code. I've been interested to know this for some time. While I appreciate the comments, I thought you might equally be able to appreciate my perspective. > 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. I never said it wouldn't be. Especially difficult should have been _main.c, because of the fundamentally different startup code of the two compilers. I would be interested to know what *exactly* was required to make Robotroff compiler and run under Lettuce. I know the next statement is terribly myopic, but the Manx code seemed relatively clean to me. > 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. > Um... er... Assembly, per se, doesn't *expect* anything. I could have supplied the random number generator I wrote for Lettuce and declared it extern long, and it would have worked great (if I passed it a long). I should have called attention to this gotcha. > 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. > Okay, I'll try. I usually only type Amiga library functions as returning either void * (if they return a pointer to anything), or long (if they return an integral value of some sort). Some might say, "Why not #inlcude ?" Well, in the 3.20 version of the compiler, there are ommisions and errors in that file (the exact nature of which I haven't studied of late, but it is there). Also, I like having the type checking turned off, especially with GetMsg(). GetMsg() almost never returns a struct Message *, but a struct IntuiMessage *, or a struct IOStdReq *, etc. Explicitly coercing the type over to what it should be strikes *me personally* as rather painful, and makes the code more difficult to read, adding more parenthesis and making it look like a LISP program :-). I know, weak excuses, but that's what happens when you become rather familiar with the operation of the processor and compiler, and you know what you can get away with. I suppose ANSI will visit me one day and ask me to please stop that. > 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. > A very valid point. Once again, an assumption on compiler behavior. Sorry. > 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. > Erp. Excuse me. I'll be more careful. > 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. > ^^^^^^^^^^^^^^^^^^^^^^^^^ And if you believe that, I have a bridge to sell you :-) :-). > 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. > Hmm. I like that one. I'll try it. > 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 And your opinions are appreciated. Really. Anything I can do to be a better programmer will be effort well-spent. Thanks. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ________ ___ Leo L. Schwab \ /___--__ The Guy in The Cape ___ ___ /\ ---##\ ihnp4!ptsfa!well!ewhac / X \_____ | __ _---)) ..or.. / /_\-- -----+==____\ // \ _ well ---\ ___ ( o---+------------------O/ \/ \ dual ----> !unicom!ewhac \ / ___ \_ (`o ) hplabs -/ ("AE-wack") ____ \___/ \_/ Recumbent Bikes: "Work FOR? I don't work FOR The _O_n_l_y Way To Fly! anybody! I'm just having fun."