Path: utzoo!attcan!uunet!nuchat!wombat From: wombat@nuchat.UUCP (Scott Lindsey) Newsgroups: comp.sys.apple Subject: Re: APW C Message-ID: <1023@nuchat.UUCP> Date: 14 May 88 15:10:43 GMT References: <8805121956.AA21868@crash.cts.com> Organization: StyleWare, Inc. Lines: 37 [Sorry if this is a duplicate posting] From article <8805121956.AA21868@crash.cts.com>, by mdavis@pro-sol.cts.COM.UUCP: > Scott Lindsey (of StyleWare) writes: >> I don't view APW C as a viable development tool [because it lacks] >> assembly-level debugging. > That's not what I said. I said I don't view it as a viable development tool because of the _necessity_ of assembly level debugging. (I also said that this was only one reason). > Are you talking about data flow analysis and a source-based symbolic debugger, > or just the ability to pop into DEBUG and trace through your code? If the > latter, you can EASILY use DEBUG. I was basically referring to the former. On the GS I use assembly (that's what was there first) for the most part. My C background is under BSD unix where I used dbx, a symbolic debugger. When I use debug with my assembly code, no problem. When I use it with C generated code, it's a guessing game figuring out how the compiler was written. Little library routines to do bit shifting, integer comparisons done differently than I would, etc... are things which, while necessary, make life hard. Since you seem to have done some work with APW C, I'll ask your opinion. First, have you written anything big (multi-bank) using APW C? Did it work properly? I ran into problems when I had to put different segments into different banks. I have to assume that it's probably library routines with bank dependencies... but I don't have the time to figure out which library routines are at fault. -- Scott Lindsey uunet!nuchat!wombat | These are _my_ opinions. StyleWare, Inc. | 5250 Gulfton 2E | It was a cold night for alligators Houston, TX 77081 | ... a cold night for dogs.