Path: utzoo!attcan!uunet!bfmny0!tneff From: tneff@bfmny0.UUCP (Tom Neff) Newsgroups: comp.sys.intel Subject: Re: PLM vs. C for 80286/80386 Keywords: PLM C Message-ID: <14389@bfmny0.UUCP> Date: 8 Jun 89 15:25:52 GMT References: <598@philtis.UUCP> <126@tridom.uucp> Reply-To: tneff@bfmny0.UUCP (Tom Neff) Organization: ^ Lines: 67 In article <126@tridom.uucp> wht@tridom.uucp (Warren Tucker) writes: >2. The tools for C language development abound. The same >for PL-M are fewer and harder to find. The same holds for >the availability of subroutine libraries and programs to >extract code and ideas from. Tool availability unfortunately depends on your choice of platform. If you have the (mis)fortune to be developing on an iRMX box, you don't have a lot of the goodies UNIX or even MS-DOS based folks do. Some you can port yourself, but it's not always trivial to take 200k of BSDish code and shoehorn it into ANSI C on an alien box with only sketchy equivalents for some of the standard UNIX facilities. >3. C is a lot less wordy. Having refused to use a macro >for the PL/M DECLARE keyword, my fingers are a great deal >more tired after finishing a module in PL/M. EVERY function >or procedure used in a module not resident in it must be >DECLAREd EXTERNALly. This is probably a weaker argument, >but it counts. I would like to play devil's advocate here and say that in my experience, the need to spell more things out HELPS program reliability and maintainability rather than hinders it. Writing your first big PL/M source module from scratch can be a bit daunting. Writing the next one can usually be accomplished by boilerplating the structure of the first one wholesale in the editor and replacing the guts with new stuff. That's what I do. On the other hand I have seen my share of write-only C and would not care to have to maintain it for a living. >4. Support. I may be wrong, but I think there is a great >deal more C programmers out there than PL/M. The problem with PL/M programmers is that they don't know each other exist! That's one of the things comp.realtime can help with, also comp.sys.intel although everyone seems to use that group to beg for stepping errata sheets. :-) >5. PL/M is inherently a strongly typed language. It is >very hard to screw up the number and type of parameters >supplied to a function, etc. However see another poster's point that once you pass by ADDRESS, PL/M gives up the ghost, and this can hurt when interfacing with, say, FORTRAN. What that poster didn't point out, though, is that C is no better at interfacing with FORTRAN! Things like LINT only help for C-to-C interfaces. LINK86 is happy to tell you about "type mismatches" of course - and will do so at *book length* if you link C and FORTRAN together with the TYPDEF records still in, even if you did it *right*. >6. I haven't seen any C compiler produce such good code for >the Intel CPU. PL/M built-in functions use REP, LOOPxx, >MOVSB, etc. in inline code, while C is always calling >external routines for such things (like _blmv for structure >assignment). No - as of iCx86 3.0 and later (the ANSI versions, post-Mark Williams atrocity) there is something called which tells the compiler to generate inline code for MOVB type things. There is a #pragma inline (a total kludge) that gets tacked onto the special functions. If you leave out inline.h, it resolves them to the RTL I believe. -- You may redistribute this article only to those who may freely do likewise. -- Tom Neff UUCP: ...!uunet!bfmny0!tneff "Truisms aren't everything." Internet: tneff@bfmny0.UU.NET