MOVING FROM ASSEMBLER TO "C": Part 1
If you're a TPF programmer who's been waiting for a chance to get exposure to "C" programming, now is your chance. Over the next few issues, we'll explore a fast-track method of learning "C" programming tailored specifically for TPF Assembler language programmers. In this article, we'll show you how to start thinking more like a "C" programmer and less like a TPF programmer; in Part 2, we'll take a more in-depth look at "C" and how its features replace those in TPF Assembler. Finally, in Part 3, we'll take an existing Assembler program and translate it into a "C" TPF program using all of our accumulate knowledge.
Each of these lessons will contain a "quiz" at the end and program exercises for further practice. Answers to the program exercises will be posted to my website at "http://www.robisoft.com"; answers to each quiz will also be posted there and in the next successive issue of this newsletter. Of course, both the quiz and the program exercise are optional but will definitely prove helpful in your learning to use "C" language in a TPF environment. Now, let's get started.
This course assumes that you have a basic knowledge of the use and application of TPF Assembler language programming. That's it! That's all you have to know before you begin.
This course addresses the use of "C" in the newer ISO-C TPF environment -- not the older Target(TPF) one.
THINGS TO FORGET ABOUT
At this point in your TPF career, writing a new TPF program is probably a breeze: from allocating a new segment and determining its name (Can I name it ABXY or XYAB?) to finding which ECB levels are available and which registers to use. All these things and more like them are considered common-place tasks for a TPF applications programmer.
Now, as you delve into the world of "C" programming for TPF (hereafter we'll just use the term "C/TPF" when referring to "C" programming for TPF), you'll in for a definite culture shock. Since "C" is a high-level programming language (or HLL), C/TPF programmers let the compiler and/or the operating system worry about many of the things they used to have to take care of themselves. (A compiler is a product on your development system that converts a high-level languages like "C" into either its equivalent Assembler language or machine language format.)
Here is a list of things you can forget about using before and during the development of C/TPF programs:
Once you began programming in "C", you'll realize that there is an implied trust between the programmer, the compiler and the operating system that goes something like this: "Let me (the programmer) worry about writing the meat of the application and I'll trust you (the OS and the compiler) with taking care of the low-level concerns such as registers, core blocks and the ECB."
THE BASIC "C" BUILDING BLOCK
When you learned to write TPF Assembler programs, you learned that every program should have the following basic structure:
*The program body would follow these comments
The above code segment contains all of the basic building components required to assemble the program cleanly in a TPF environment. For, C/TPF, the basic building block is called a 'function'. A Function in C/TPF will contain the necessary code to carry out a specific action or actions that the programmer wishes to have done. A basic C/TPF function would look like this:
/* The Body of the C function would follow
these comments. */
If the above lines of "C" code looks like "gobbledy-gook" to you, then don't feel concerned. "C" has often been described as an "ugly" programming language which takes some time to get used to. Meanwhile, an explanation of each part of the above function follows.
(Details of the "pre-processor" step are beyond the scope of this course; for now you simply need to know that the pre-processor step is critical for the compiler because the files that are processed help it to resolve the use of external functions and other references your function might use.)
Although not shown in this example, the process that called function abcd() could have also "passed" or handed values (called parameters) to the abcd() function for it to use. Parameters specify the types, sizes and names of values passed to a function. If abcd() had had any parameters passed to it, this would have been shown between the parentheses of the abcd() function. Example: void abcd(int value1, int value2)
That's it for Part 1 of this article series. Now, let's test what you've learned with a brief quiz:
B.) The left and right curly brace
C.) The return statement
D.) The include statements
E.) All of the above
F.) None of the above
A. Determine which statements in the following TPF Assembler language program would NOT be required if you had to convert the program to its C/TPF equivalent.
*THE PURPOSE OF THIS PROGRAM IS TO CHECK THE CHARACTER IN THE 7TH *POSITION OF THE INPUT MESSAGE. IF ITS A 'Y' FOR YES, THEN WIPE OUT *THE PASSENGER NAME CURRENTLY BEING WORKED UPON. OTHERWISE, *JUST EXIT AND RETURN.
L R1,CE1CR0 BASE THE INPUT BLOCK
L R3,CE1CR2 BASE THE PASSENGER NAME BLOCK
CLI MI0ACC+7,C'Y' ZERO OUT THE CURRENT PASSENGER NAME ?
BNE EXITHERE IF NOT 'Y', THEN GO TO EXIT
XC PN0NM,PN0NM ZERO OUT THE CURRENT NAME RECORD
EXITHERE DS 0H
B. Convert the Assembler program above to a "C" function using the information given in this lesson. For lines you can't convert, make those lines comments and indicate where the "C" equivalent statements might go.
C. Using the information in this article, write a C/TPF function that receives two parameters passed to it of "int" type and returns the first value passed.