drabik@gt-eedsp.UUCP (Timothy J. Drabik) (08/05/88)
I'm looking for a C compiler for a PC XT that will allow me to write software that runs both on the PC (MSDOS) and on 4.2 BSD on a 780, without too many headaches. I'd be willing to make up for small differences in the header files. I also want easy low level IO port access on the PC: reading and writing bytes in the IO address space. I prefer a `cc' command line interface to a separate `programming environment.' Borland Turbo C apparently allows this, and is reasonably priced. Would some Turbo C users please comment on the merits or flaws in this compiler? Regards, Tim Drabik Georgia Tech Optical Computing drabik@gteedsp.gatech.edu
cck@deneb.ucdavis.edu (Earl H. Kinmonth) (08/06/88)
In article <371@gt-eedsp.UUCP> drabik@gt-eedsp.UUCP (Timothy J. Drabik) writes: > >I'm looking for a C compiler for a PC XT that will allow me to write >software that runs both on the PC (MSDOS) and on 4.2 BSD on a 780, >reasonably priced. Would some Turbo C users please comment on the >merits or flaws in this compiler? I do what you describe plus compile for several Xenix systems, ULTRIX, and 2.9 BSD. I have three C compilers: the Xenix (Microsoft) cross compiler, MSC, and TurboC. I gave up on MSC (Quick C) under MSDOS. The interface is bad, you can only use the middle memory model (for the debug environment), and the system of handling libraries is intolerable. TurboC (1.0) has many bugs, some in fundamental areas. You say you want floating point arithmetic that works? What are you, some kind of communist? I've never succeeded in getting anything but the most trivial programs to work using large and huge memory models, and turning on stack probes causes programs to run out of memory very rapidly. The documentation has many errors in terms of allegedly equivalent UNIX/MSDOS calls and some things are especially stupid, the signal (actually ssignal under TURBOC) handling, for example. Watch out for **IX code that calls ioctl; turboc has one unrelated to the **IX version. With enough #ifdef statements, you can get things to work, however, and unless you like rodents, the interface is more congenial. Combine TurboC with the MKS Toolkit, put the basic programs and includes on ram disk, and you'll probably not mis a debugger since you can compile/relink so fast. On the other hand, the Quick C (MSC) includes and functions are overall more **IX compatible, and if you are going to use it in a command line environment, you can avoid the dumb interface and its diddling with the video (not good for my ATT 6310).
pjh@mccc.UUCP (Pete Holsberg) (08/07/88)
In article <2637@ucdavis.ucdavis.edu> cck@deneb.ucdavis.edu.UUCP (Earl H. Kinmonth) writes:
...TurboC (1.0) has many bugs, some in fundamental areas. You say you want
Perhaps you should upgrade to 1.5, which has been available for about 6
months.suitti@haddock.ISC.COM (Steve Uitti) (08/09/88)
In article <371@gt-eedsp.UUCP> drabik@gt-eedsp.UUCP (Timothy J. Drabik) writes: > Would some Turbo C users please comment on the >merits or flaws in this compiler? I have Turbo C 1.4 (1.5 is out, and is supposed to be better, but, I haven't gotten around to it. Too many things going on.) >I'm looking for a C compiler for a PC XT that will allow me to write >software that runs both on the PC (MSDOS) and on 4.2 BSD on a 780, >without too many headaches. I'd be willing to make up for small >differences in the header files. Most of the code that I've written in the last six years in C under various UNIXes works with minimum pain under Turbo C. Turbo C's better warnings, and prototype capability have found bugs that remained undiscovered in the UNIX versions for years. The compiler produces good code (even floating point, even for the 8087) quickly (even on my 7.16 Mhz 8088 XT clone), and doesn't require infinite disk space. > I also want easy low level IO port >access on the PC: reading and writing bytes in the IO address space. I haven't had to do this. >I prefer a `cc' command line interface to a separate `programming >environment.' Borland Turbo C apparently allows this, and is >reasonably priced. I'm used to a "cc" line, but with Turbo C, I use the interactive environment. I'm basically lazy. I'd rather use the pull down menus and online help than read the manuals too much and write makefiles. The command line lets you do everything that the environment lets you do, possibly even more. Turbo C was $65 over the counter last fall. Microsoft C (5.0) was something like $300. I don't give it as good a review, even if it were free. Stephen.
kluft@hpcupt1.HP.COM (Ian Kluft) (08/09/88)
cck@deneb.ucdavis.edu (Earl H. Kinmonth) writes: > TurboC (1.0) has many bugs, some in fundamental areas. You say you want > floating point arithmetic that works? What are you, some kind of > communist? I've heard that TC 1.0 was that bad. I bought a copy of 1.5 shortly after it became available. I've had no problems with floating point or any memory model. Also, 1.5 has a VERY useful graphics library which has saved me untold amounts of time (with bit-mapped fonts, Hercules/ CGA/EGA/VGA support, etc.) I recommend that you upgrade to 1.5 to resolve most or all of your complaints against TC. The original message that led to this series of responses also asked about low-level support and Unix semi-compatibility. It seems to have good coverage of the Unix library but MS-DOS is not Unix so there are plenty of differences as well. I like one feature of TC in particular - interrupt functions. By putting the keyword "interrupt" in a function definition, the compiler makes it a function that can be called by a machine interrupt (i.e. it saves the machine registers first and restores them before returning). ------------------------------------------------------------------ Ian Kluft RAS Lab UUCP: hplabs!hprasor!kluft HP Systems Technology Division ARPA: kluft@hpda.hp.com Cupertino, CA ------------------------------------------------------------------
kjc@cuuxb.ATT.COM (~XT4134000~Kevin Coulter~C29~L18~6282~) (08/09/88)
I read an article last nite in the Sept 13 issue of PC Mag (tell me why the
issue is dated over a month from now - I don't know) stating that Borland is
introducing Turbo C 2.0 soon. It is supposed to include a debugger... we'll see what else gets thrown in.....
Kevinmadd@bu-cs.BU.EDU (Jim Frost) (08/10/88)
In article <5930012@hpcupt1.HP.COM> kluft@hpcupt1.HP.COM (Ian Kluft) writes: |cck@deneb.ucdavis.edu (Earl H. Kinmonth) writes: |> TurboC (1.0) has many bugs, some in fundamental areas. You say you want |> floating point arithmetic that works? What are you, some kind of |> communist? | |I've heard that TC 1.0 was that bad. I bought a copy of 1.5 shortly |after it became available. I have it and it does goof up floats and some other things. Interestingly, 1.0 was bug-free enough for someone to port MINIX to, with good results. If you're not using floats, it works pretty well. I have used 1.0 for a number of utilities and have had no problems. 1.5 has all of the bugs that I was aware of fixed (and there are patches to 1.0 that fix several bugs) along with major library enhancements. Haven't gotten around to buying it yet, though. I think the original poster needed port I/O commands. Turbo C has them; not only that, but it has #defines in the appropriate headers that allow MSC programs to compile even though the port I/O commands are not the same between the two C's. Thoughtful of them. |I like one feature of TC in particular - interrupt functions. You didn't mention inline code. It allows both TPascal-style inline machine code and MASM code (although you need MASM for that). I've found that useful when writing interrupt subroutines that get called by FAR calls (why in ^#$%$ the people that wrote NTNX did that is beyond me). You just inline the interrupt function return instructions and replace the IRET with a RETF. Turbo C has ANSI-draft prototyping which i've found very useful in debugging others' code. I keep wishing the compiler on my Sun had that. The MINIX to Turbo C people found several bugs in the MINIX code when they converted over to using prototypes. Of course you don't need to use prototyping but it can be wonderful. Aside from the float problem, 1.0 was pretty good. 1.5, with its bug fixes and awesome libraries, is definitely worth the money. There are better compilers out there, but this is a good one. Its only lacking is a debugger. But we all debug with printk() statements (for lack of a kernel debugger), don't we ;-). jim frost madd@bu-it.bu.edu
guest@vu-vlsi.Villanova.EDU (visitors) (08/11/88)
In article <746@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: >In article <2637@ucdavis.ucdavis.edu> cck@deneb.ucdavis.edu.UUCP (Earl H. Kinmonth) writes: >...TurboC (1.0) has many bugs, some in fundamental areas. You say you want > > >Perhaps you should upgrade to 1.5, which has been available for about 6 >months. Or you can wait a bit longer for version 2.0 that is supposedly having improved floating point emulation, a debugger, Borland's TASM assembler, and a few other goodies. Well, at least this stuff is in the beta version. ---- Mark Schaffer BITNET: 16448591@VUVAXCOM Villanova University UUCP: ...{ihnp4!psuvax1,burdvax,cbmvax,pyrnj,bpa} (Go Wildcats!) !vu-vlsi!excalibur!164485913 "Look, It's Bicycle Repair Man! He's fixing it with his own hands!"
dbraun@cadavr.intel.com (Doug Braun ~) (08/11/88)
In article <5930012@hpcupt1.HP.COM> kluft@hpcupt1.HP.COM (Ian Kluft) writes: >I like one feature of TC in particular - interrupt functions. By putting >the keyword "interrupt" in a function definition, the compiler makes it >a function that can be called by a machine interrupt (i.e. it saves the >machine registers first and restores them before returning). Not quite. The problem is that nothing sets up a stack segment when the interrupt function is called. The problem arises whenever the address of an automatic variable is used. In the tiny or small models (which you need to use for interrupt procedures), it is assumed that DS = SS, so that automatics and static variables can be addressed the same way. When the fubnction is called SS has been set to another value. One cure is to have a static array to serve as a local stack, and set SS to DS and SP to the top of this array before doing anything else in the interrupt function. Even if your code does not use addresses of automatics, library stuff might. This can be hell to debug, and is not mentioned in the (otherwise good) section on assembly language and weird things in the manual. Doug Braun Intel Corp CAD 408 765-4279 / decwrl \ | hplabs | -| oliveb |- !intelca!mipos3!cadev4!dbraun | amd | \ qantel /
Ralf.Brown@B.GP.CS.CMU.EDU (08/11/88)
In article <2714@mipos3.intel.com>, dbraun@cadavr.intel.com (Doug Braun ~) writes: }Not quite. The problem is that nothing sets up a stack segment }when the interrupt function is called. The problem arises whenever }the address of an automatic variable is used. In the tiny or small }models (which you need to use for interrupt procedures), it is assumed Huh? interrupt procedures work fine in all memory models (except maybe huge) }that DS = SS, so that automatics and static variables can be addressed }the same way. When the fubnction is called SS has been set to another value. }One cure is to have a static array to serve as a local stack, }and set SS to DS and SP to the top of this array before doing anything else in }the interrupt function. Even if your code does not use addresses }of automatics, library stuff might. This can be hell to debug, and It can also be a real pain to work around, as I found when using DESQview's asynchronous notification feature (which uses a FAR function, rather than an interrupt function, but still has SS != DS). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.