Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!rutgers!sri-spam!nike!ucbcad!ucbvax!ULKYVX.BITNET!RDROYA01
From: RDROYA01@ULKYVX.BITNET (Robert Royar)
Newsgroups: net.micro.atari16
Subject: BAMMI's MAKE and ST <-> CPM
Message-ID: <8610031214.AA21791@ucbvax.Berkeley.EDU>
Date: Fri, 3-Oct-86 07:38:00 EDT
Article-I.D.: ucbvax.8610031214.AA21791
Posted: Fri Oct  3 07:38:00 1986
Date-Received: Sat, 4-Oct-86 11:13:47 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of Louisville
Lines: 96

The following code fragments are from the bammi@case MAKE.PRG.

struct name
{
    struct name *        n_next;        /* Next in the list of names */
    char *            n_name;        /* Called */
    struct line *        n_line;        /* Dependencies */
    time_t            n_time;        /* Modify time of this name */
    uchar            n_flag;        /* Info about the name */
};

struct name        namehead = {
                    (struct name *)NULL,
                    (char *)NULL,
                    (struct line *)NULL,
                    (time_t)0,
                    (uchar)0
                    };

I have been unable to get the program working.  The program exits with
a "no memory for macro" error and the touch program "touches" all
files back to the date that TOS was born (i.e. midnight sometime in
November 1985).  So question one is, "has anyone other than those at
CASE gotten this program to work?"

My second question has to do with the last cast in the structure
initializer.  Here's the scenario.  My dev pack has been ordered and
should arrive next week, so I compiled the code with the CP/M-68K
compiler (which is identical to the early ST version right down to the
serial numbers).  I had a friend compile it on the ST with his DEV
pack and he got the same errors.  The early Alcyon compiler only
supports unsigned ints, so uchar is defined as char in a header file.
But the code parser (c068) balks at the coercion with the error
"invalid initializer"  which means I tried to init a variable with
something other than a constant.  Even the cast (char)'\0' got the
same error.  Now I know the last element of that structure has to be a
character constant or the structure will not be filled properly.

The code generated for a structure like this goes ahead and fills the
remainder of the space to allign on a word boundary, but the size of
the last element determines how that element will actually be stored
and accessed.  Structure initialization and size has been a known bug
in the Alcyon compiler at least since 1983.  One problem with this
structure is that all of the beginning elements are 32 bits long.
Alcyon has trouble, and always had, with structures or function
parameter lists that all have the same (long) size.

Another minor beef.  If you

#define uchar char

Sometines the preprocessor has trouble in an expansion that involves a
cast.  If you

#define void

casts again can lead to difficult to track errors.  Is there a reason
to avoid typedef in these situations?  Why not use

typedef uchar char;
typedef void int;  /* after all Alcyon expects int returns by default */
                   /* even when none are specified.  Check the stack */
                   /* popping code it produces after a jsr */

Defines are hard to track down in a preprocessor output file because
they all dissapear.  But a typedef follows through that output, and
you can see what a cast or value is.  DRI used to

#define FILE struct _iobuf

That made a file definition bug a real bear to find.  However,

typedef FILE struct _iobuf;

is more logical and closer to the intentention of using FILE
structures in the first place.

While I'm on the DRI soapbox.  I compared the AR68 output for gemlib
to that for the old clib libraries (is AR68 available for the ST
yet?).  The modules are practically identical in fact the object code
from CP/M-68K ports directly!  So much for "the only similarities
between these two systems (GEM-DOS and CP/M) are superficial."  BTW
Concurrent DOS is on the market for the 68010 according to a
Concurrent PC-DOS OEM I know and a CP/M-68K OEM I've contacted.  He
said DRI wanted too much for the port.

I've beat the CPM drum in this newsgroup before and gotten flamed, but
I recommend that anyone who writes software or is trying to port
software for the ST look at as much CPM code as possible.  There
really is a world of good programs out there that require very little
effort to move to the ST.  It's ridiculous that there's no equivalent
to "real" xmodem i.e 1024 packets, true CRC, batch files, 19200 baud,
scripts, etc. in the ST PD library.  19200 is great for moving files
between the ST and your other computer, whatever that may be.

send flames to rdroya01@ulkyvx.bitnet