Chapter 20: Using Assembly Language with High-Level Languages

This chapter concentrates on various aspects of using Assembly language with high-level programming languages. Unfortunately, many contemporary programmers neglect the study of Assembly language or do not know how to use it with high-level languages. Thus, they miss a powerful and flexible programming tool. I would say that every professional programmer, regardless of the chosen programming language, has to master the Assembly language as a second tool. This is similar to a common opinion held by linguists, who say that everyone who chooses to become a professional linguist must master Latin before studying other European languages. Furthermore, the study of Assembly language will bring you joy, so do not miss this opportunity. After all, experiencing the joy of cognizance is a main goal of life. In general, the mating of Assembly language with high-level languages is based on the following foundations: name coordination, parameter coordination, and call coordination. First, it is necessary to consider call coordination.

Call Coordination

In MS-DOS, the called procedure could reside in the same segment as the calling command (in which case the call was classified as NEAR ) or in another segment (in which case the call was classified as FAR ). The difference between NEAR and FAR calls was that in the first case the call address was formed on the basis of 2 bytes and in the latter case 4 bytes were required. Accordingly, the return from the procedure could be near ( RETN ), in which case the return address was formed on the basis of 2 bytes popped from the stack, or far ( RETF ), in which case 4 bytes had to be popped from the stack. Obviously, both the call and the return had to be coordinated. Within the framework of a single program, this usually didn't cause significant difficulties. However, problems could arise when it was necessary to link some external libraries or object modules. If the return into the object module was carried out by RETN , the programmer had to link object modules to join the segment, in which the called procedure resided with segments, from which the call originated. Naturally, the call in this case had to be NEAR . If the return from the procedure was carried out by the RETF , then this procedure must be called by the FAR call. At the same time, the call and the procedure in the course of linking had to fall into different segments. The problem of call coordination was further aggravated because errors were detected at run time, not at the linking time. So-called memory models in the C programming language also resulted from this, and they caused serious headaches for many beginner programmers. By the way, if you look at C libraries for DOS, you'll discover that there was a special library for each memory model. Segmented memory models lead C programmers to another problemthe pointer problem (this, however, is another story). The developers of Turbo Pascal chose another way: They understood that the program should include one data segment and several code segments. When the data couldn't fit within a single segment, the programmer could use the dynamic memory. With the migration to Windows, programmers were given a wonderful giftthe flat memory model. According to this model, all calls are NEAR , which means that they take place within a single vast segment. This eliminates the need to coordinate calls, so I won't return to this problem.