CCS C compiler
by
Shawn M. Gordon
President
S.M.Gordon & Associates
Introduction
What in the world ever possessed me to review a C compiler I will never know, I must say that it has been one heck of a learning experience. I chose not to do a comparative review because I felt it was beyond my ability to complete in any reasonable amount of time. I chose the CCS C compiler because it is the only one that still seems to be actively marketed on the MPE V machine. Also I believe that the CCS C compiler was used by HP to develop their XL version of the C compiler. I know that HP used the CCS manual for their compiler.
The advantage to using the CCS C compiler on both the MPE V and iX machines is that they should be totally compatible, whereas if you use CCS C on your Classic and HP C on your Spectrum, you could run into some compatibility problems. The other advantage to using CCS, in my opinion, is that they tend to react much quicker to making enhancements to the product than HP is likely to.
I tested the software on an HP 3000 series 70, running MPE V Platform 1P release 21. There was 12 meg of main memory and I used Probe from Strategic Systems to monitor the system performance.
Features
Before I get into the features of the actual language I want to touch on some of the other products that you can get with the C Professional package. These are MAKE, GREG and CVIEW. The first, MAKE, is a popular facility on PC’s and under UNIX, but for some reason has never gained a whole lot of recognition or popularity on the 3000, even though CCS does sell it stand alone. The purpose of the MAKE facility is to let you describe a project and then have any modules affected by a change be recompiled, linked or whatever needs to be done to satisfy the project description. This makes a lot easier to maintain projects because you can have the system automatically compile only the necessary files, and not have to do everything just to be sure.
The CCS implementation of MAKE isn’t as easy to use as the one I have on my PC, but it does work well, and conforms pretty closely to the UNIX ones I have seen. There is certainly some set up required on your part, but if you take the time now you will probably save yourself a lot of time in the future. I am not going to go into describing how the product works because I am here to write about the C compiler.
The second program is GREP, and for those of you familiar with UNIX, this is an old friend. GREP at it’s most basic will search through the files specified in the file set for a string pattern. There are various options for specifying case or to read through a file that contains the strings to compare, etc.. If you have used MPEX’s PRINT ;SEARCH=, you can think of it that way. The program works well, just like it’s UNIX counterpart.
Lastly there is CVIEW, this is the C debugger that runs on MPE V. If you have ever been fortunate enough to use TRAX for COBOL from CCS you will notice a big difference. They have TRAX for C but it only runs on MPE/iX.
While it is always nice to have a decent source level debugger I found CVIEW a bit difficult to use. It does work, but there was just to much to learn for me to make much use of it during the course of the review. It is MUCH better than having to use DEBUG or nothing however.
Ok, now on to the language proper; First a program must be written, all you have to do is fire up your favorite editor, write one, save it, compile and link it, and you are done.
To accommodate the MPE Intrinsics the PRAGMA has been introduced. This allows you to declare the intrinsic function. It does the prototyping for you, you can code the intrinsic as extern and prototype it yourself, but it is much easier to use the pragma. You can also give the intrinsic an alias name if you wish. Here is a short example of various declarations;
#pragma intrinsic FOPEN
#pragma intrinsic TERMINATE shutdown /* shows the use of alias */
extern int FWRITE(int fnum, unsigned *buffer, int len, unsigned opt);
/* ^ example of declaring the intrinsic yourself */
OR
#pragma intrinsic FWRITE /* much easier than previous example */
The IMAGE intrinsics are handled in the same manner, there is a section in the manual under Special Topics that shows that types of variables expected for each parameter of an Image call, as well as some examples of how to do it.
There is a program that is included that will format your SPLINTR file, this is the file that describes all your intrinsics, giving you the expected C data types. Since the intrinsics manual gives all definitions in SPL this is a handy addon program.
If you are going to create C subroutines that reside in a USL or SL, you will also need to copy a couple of segments from the CCUSL that comes with CCS C.
These are CCSCSEG0 and CCSCSEG1, otherwise you are going to get unresolved external errors on things like strlen, strcat, printf, etc..
It’s kind of hard to go through the features without regurgitating everything that is in the ANSI C specification. I wanted to just touch on the major parts that are different under MPE. For instance, the Extra Data Segment can be implemented in C one of two ways. Either using the intrinsics for GETDSEG, DMOVIN and DMOVOUT, or by using the C function ‘malloc’ which does memory chunk allocation. Here again it depends on how portable you want your code to be.
Usability (also installation)
I didn’t care for the installation all that much, the instructions were imbedded at least a hundred or more pages into the manual, with nothing telling you were to look for them. I had to resort to a RESTORE with the CREATE option and then had to modify the accounts myself. Turns out there was an install stream, but I found it later after having perused the manual more.
The software is as usable as you would want it to be. In other words you can write and compile code. Don’t look to the manual as a training guide as it isn’t. There are some sections specifically for us MPE types that include how to call data base intrinsics and how to convert from their CREL RBM to the more familiar Segmenter RBM.
Reliability
All my code ran that I wrote, so you would have to say that it’s a reliable compiler. The error messages were much more useful than those I have found on the various HP compilers I have used. This made it quicker to correct problems. You have to remember though that K&R C does very little, if any checking of your code, you can do anything you want, even if it’s wrong and won’t work. The ANSI committee decided to make the language a little less forgiving and that is reflected in the CCS C compiler.
Performance
There is a trade off when coding in C. You need to know if you are trying to code for portability or not. If you are coding for portability then you will probably want to use the C I/O functions, or code your own intermediate functions that will allow you to switch between I/O types easily. You will find that the code generated by coding the MPE I/O Intrinsic call’s rather than using the C I/O functions will be faster and smaller but less portable.
In terms of compiler efficiency I would say that CCS C comes somewhere between COBOL and compiled BASIC, which is second only to SPL in terms of compiler efficiency. This is going to also be dependent on the way you code as I just mentioned. Since I didn’t do any real hard core benchmarks take this statement with a grain of salt.
Supportability (including Doc)
I don’t know why but my first call to tech support went unanswered for 2 days. I finally called again and was put right through to someone. Every time I called after that I got a hold of someone immediately and received expert help. There was one guy I talked to who really was familiar with the HP 3000 and use to code COBOL, so he was able to give me quick answers since he had gone through some of what I had been going through.
The manual works OK as a reference manual, I wish that there were more examples in it however. I know they don’t want to be writing a C training guide, but it would be nice to see more code fragments to demonstrate some of the functions. There is a section at the end that has the error and warning numbers that the compiler will generate as well as the explanations for them. They also go to lengths to explain how certain functions of C operate under MPE and why they work that way. I thought this was a nice touch.
The manual for CVIEW is a little weak in getting you started, but works good as a reference manual. The manuals for MAKE and GREP were pretty easy to go through however.
Summary
Well I don’t think I am going to be making a jump from COBOL to C just yet, but if I did, I would buy the CCS C compiler. C just doesn’t seem to be as home on the HP as it does under UNIX. However it gives you some options for coding that are unique to a language on the HP.
I like the MAKE and GREP facilities that you can get with the product, as well as the CVIEW debugger. I wish I could use the debugger under MPE/iX since it is more powerful, but since I am on a Classic that wasn’t an option.
Since Unison/Tymlabs has dropped their C compiler there really isn’t any competition under MPE V so it’s easy to make a strong recommendation for CCS. It’s a good thing that they have a good product and strong support.
My final statement on the whole C philosophy in general, is that you should probably start re-writing those SPL sub-routines that have been laying around in C sometime soon. However, coding a business application is usually much more straight forward and easier to maintain in a language like COBOL. There, that should make me a few enemies, but I really found that certain functions that were very straight forward in COBOL were incredibly convoluted in C. I will save a comparison of the two languages for another article.
At-a-Glance box
C version 2.1.40
Corporate Computer Systems
33 West Main St.
Holmdel NJ 07733
(908) 946-3800 phone
(908) 946-7167 FAX
Price is $$$$$ support is $$$
1 C Manual 2″ thick
Good Points
Solid ANSI C compiler
Good tech support
Some convenient function additions to ANSI C
Bad Points
Very few useful MPE examples
Installation instructions are hard to find