RDROYA01@ULKYVX.BITNET (Robert Royar) (10/03/86)
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.bitnetbammi@cwruecmp.UUCP (Jwahar R. Bammi) (10/04/86)
Newsgroups: net.micro.atari16 Subject: Re: BAMMI's MAKE and ST <-> CPM Summary: Expires: References: <8610031214.AA21791@ucbvax.Berkeley.EDU> Sender: Reply-To: bammi@cwruecmp.UUCP (Jwahar R. Bammi) Followup-To: Distribution: Organization: CWRU Dept. Comp. Eng., Cleveland OH Keywords: In article <8610031214.AA21791@ucbvax.Berkeley.EDU> RDROYA01@ULKYVX.BITNET (Robert Royar) writes: >The following code fragments are from the bammi@case MAKE.PRG. > ...... > >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?" > I know of alteast 2 dozen people who have gotten make to work outside of CASE, and with various compilers (lattice, megamax). I ran it through Mark Williams too, and it works just fine. Most people who have been having problems with 'no memory ...' type of errors, have been making the mistake of linking make with the version of gemstart.o that was distributed with the development system. That particular version only reserves 1K for stack+heap, and gives the rest back to the system. All that is needed is that you edit gemstart.s and on the line that reads add.l #$500,d0 * d0=basepage+textlen+datalen+bsslen * (plus 1K of user stack) and change the $500 to some much larger number like $4000 (16k). Better yet, use the new gemstart.s available on CompuServe, that has the various memory models. I hope that this is your problem. As far is touch goes, both the stand alone touch program, and the touch function within make, get the current time from the IKBD and not from Gem's counters. So if you only set the current time via the control panel, and have not set the IKBD's time (they are independent counters, and the control panel acc. does not set the IKBD time) the time you will get will be wrong. I am almost certain, from your description of the problem, that this is the case. The reason i chose to read the time from IKBD rather than from Gemdos is that the IKBD clock survives resets, while the Gemdos clock does not. Besides, i have long ago, thrown away the control panel accessory. To set the IKBD clock there are atleat a dozen PD programs. Many of them sit in the auto-folder. Almost all of them set both the counters. -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. All of the above comments are appreciated. I think you will find that the new version of Alcyon V2.14 handles structures quite well. Maybe i should have checked with my old compiler disks, but i did'nt since the new version had been out for more than a couple of months when this article was posted. I guess (have'nt tried) you can go ahead and declare uchar as an int, and just put a '0' for the last initializer, and it should tide you over till you get your devl system. Sounds like your friend needs to get the dev. sys. upgrade too. -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 */ - voids are NOT int's. V2.14 supports voids just fine. I just tried a small example. It does not produce any extraneous code. Besides the stack popping code is there to pop the arguements off the stack. A value, if any, is returned in d0, so the stack popping code has nothing to do with the type of value returned by a function. I think 'typedef void int' is a bad idea, as any compiler (such as v2.14) will complain because void is now a reserved word, and can't be used as an identifier. I do throughly agree on your point about using casts. Typedefs should be used when possible (see comment below too). >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. > Totally agree on the above point. Since i ported neil's code i just followed the same style. I usually do use typedefs. >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?). Yes, a working version comes with the dev. sys. update. there is also a Pd version available. > ..... >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. > I routinely use xmdm to transfers files and in terminal mode at 19.2K. One of the person's here has also implemented chuck fosberg's (sp ?) Ymodem protocol (rz/sz) and that handles 1K packets pretty well. Hopefully it will have adapting windows one day. I agree that we could use PD gems from the Cp/m world too. So as the old saying goes "Put your money where your mouth is" and post some! -- usenet: .....!decvax!cwruecmp!bammi jwahar r. bammi csnet: bammi@case arpa: bammi%case@csnet-relay compuServe: 71515,155
preston@felix.UUCP (Preston L. Bannister) (10/14/86)
[lots of deleted text] >>(is AR68 available for the STyet?). > > Yes, a working version comes with the dev. sys. update. there is >also a Pd version available. Really?!?? How do I get ahold of a copy? >>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. > > I routinely use xmdm to transfers files and in terminal mode >at 19.2K. One of the person's here has also implemented >chuck fosberg's (sp ?) Ymodem protocol (rz/sz) and that handles 1K packets >pretty well. Hopefully it will have adapting windows one day. I agree that >we could use PD gems from the Cp/m world too. So as the old saying >goes "Put your money where your mouth is" and post some! There is a program called 'bmodem' availible from BIX in source and binary for the ST that has scripts. It think it has large (1K) packets. I haven't looked it over yet, so I don't know what other features it may have. ======================================== Preston L. Bannister USENET: ucbvax!trwrb!felix!preston BIX: plb