assembly language step by step programming with dos and linux PHẦN 8 pptx

file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm subtables give you just about everything you'd really need to know about a given display adapter to do useful work with it. When your assembly-language program begins executing, it should inspect such a table and extract the values pertinent to the currently installed display adapter. These extracted values should be ordinary variables in the data segment, easily accessible without further table searching. These variables should be defined together, as a block, with comments explaining how they are related: As the comments indicate, a single procedure named VidChek reads values from the two-level lookup table VidInfoTbl and loads those values into the variables shown above. VidCheck is an interesting creature, and demonstrates the way of dealing with two-level tables. Read it over: file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm (41 of 58) [9/26/2002 9:20:33 PM] file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm (42 of 58) [9/26/2002 9:20:33 PM] file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm (43 of 58) [9/26/2002 9:20:33 PM] file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm (44 of 58) [9/26/2002 9:20:33 PM] file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm The first thing VidCheck does is call DispID to determine the installed display adapter. Build on your own tools—there's no need to duplicate logic if you can avoid it. The adapter ID code is stored in the variable DispType. It's possible to use the table to look up the number of lines on the screen from the current text font size, but to do that you have to determine the font size. Determining the font size is a good exercise in the use of the CMP instruction and conditional jumps. Certain adapters support only one font size. The MCGA has only the 16-pixel font. The CGA has only the 8-pixel font. The MDA has only the 14-pixel font. A series of compares and jumps selects a font size based on the display adapter ID code. The trickiness comes in with the EGA and VGA, versatile gentlemen capable of using more than one font size. Fortunately, BIOS has a service that reports the size, in pixels, of the text font currently being used, and this service is used to query the font size. Whatever it turns out to be, the font size is stored in the FontSize variable in the data segment. Base-lndexed-Displacement Memory Addressing So far, we haven't dealt with the VidlnfoTbl table at all. This changes when we want to look up the string containing the English-language description of the installed display adapter. There are three general steps to reading any two-level lookup table: file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm (45 of 58) [9/26/2002 9:20:33 PM] file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm • Derive the offset of the subtable from the beginning of the larger table • Derive the offset of the desired information within the subtable • Read the information from the subtable. Each of the subtables is 32 bytes in size. To move from the start of the VidlnfoTbl to a desired subtable, we multiply the index of the subtable by 32, just as we did in the previous section, in reading one single value from OriginTbl. The index, here, is the display adapter ID code. We multiply the index by 32 by loading it into register DI, and then shirting DI to the left by 5 bits. (Shifting left by 5 bits multiplies the shifted quantity by 32.) We use the form mov CL,5 shl DI,CL because it is shorter and faster to shift by CL than to shift by using five SHL DI,1 instructions in sequence. Because the display adapter description is the first item in every subtable, no offset into the subtable is necessary. (The offset, if you must think of an offset, is 0.) The shifted quantity in DI is added to the address of the larger table, and the sum becomes the 16-bit address to the display adapter descrip-tion string. This address is saved in the BordName variable. At this point within VidCheck, we have the address of the VidlnfoTbl table itself in BX, and the offset of the desired subtable in DI. Now we want to fetch the segment address of the display buffer from the middle of the subtable. The segment address is at some fixed offset from the start of the subtable. I say "fixed" because it never changes, and will be the same regardless of which subtable is selected by the adapter ID code. In the case of the segment address, the offset is 27, since the segment address is 27 bytes from the start of the subtable. Expressed as a sum, the segment address is at the following offset from the start of VidlnfoTbl: DI+27. Since BX contains the offset of VidlnfoTbl from the start of the data segment, we can pin down the segment address in the data segment with this sum: BX+DI+27. Is there a way to address memory using this three-part sum? There is indeed, and it is the most complex of the numerous 8086/8088 addressing modes: base-indexed-displacement addressing, a term you probably can't memorize and shouldn't try. Specifically to serve two-level lookup tables like this one, the CPU understands MOV statements like the following: file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm (46 of 58) [9/26/2002 9:20:33 PM] file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm mov AX,[BX+DI+27] Here, the base is the address of the larger table in BX; the index is the offset of the subtable within the larger table, stored in DI; and the displacement is the fixed distance between the start of the subtable and the data we wish to address. You can't just use any registers in building a memory address using based-indexed- displacement addressing. The base register can be only BP or BX. (Think of general- purpose register BX's hidden agenda as that of base register, the "B" is your memory hook.) The index register can be only SI or DI. These registers' names, Source Index and Destination Index, should provide you with their own memory hooks. Finally, the displacement can not be a register at all, but only a literal value like 27 or 14 or 3. Finding the Number of Lines in the Screen Reading the screen line count from the subtable is the trickiest part of the whole process. In one sense, the list of three different line count values is a table within a table within a table, but 8086/8088 addressing only goes down two levels. What we must do is point BX and DI plus a displacement to the first of the three values, and then add a second index to DI that selects one of the three line counts. This second index is placed into AL, which is eventually (as part of AX) added to DI. The line count is read from the table with the following instruction: mov AL,[BX+DI+28] with the second index already built into DI. The rest of VidCheck fills a few other video-related variables like LRXY, which bundles the X,Y position of the lower-right corner of the screen into a single 16-bit quantity. The size of the video buffer in bytes is calculated as the X size of the screen multiplied by the Y size of the screen multiplied by 2, and stored in VidBufSize. A Program to Report on the Current Display Adapter To make VidCheck show its stuff, I've written a short program called INFO.ASM that file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm (47 of 58) [9/26/2002 9:20:33 PM] file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm reports certain facts about the installed display controller. As a program, INFO.ASM doesn't present anything we haven't used before, except in one respect: string lengths. To display a string, you have to tell DOS just how long the string is, in characters. Counting characters is difficult, and if you get it wrong you'll either display too much string or not enough. The solution is simple: let the assembler do the counting. Here's the notation: VidlDStr DB ' The installed video board is: ' LVidlDStr EQU $-VidIDStr The first statement is nothing more than a simple string constant definition that we've been using all along. The second statement is a new kind of statement, an equate, which looks a lot like a data definition but is not. A data definition sets aside and optionally initializes an area of memory to some value. An equate, by contrast, generates a value similar to a simple constant in languages like Pascal. An equate allocates no memory, but instead generates a value that is stored in the assembler's symbol table. This value can then be used anywhere a literal constant of that type can be used. Here, we're using an equate to generate a value giving us the length of the string defined immediately before the equate. The expression $-VidIDStr resolves to the difference between two addresses: one is the address of the first byte of the string variable VidlDStr, and the other is the current location counter, the assembler's way of keeping track of the code and data it's generating. (The current location counter bears no relation to BP, the instruction pointer!) When the assembler is generating information (either code or data) inside a segment, it begins with a counter set to zero for the start of the segment. As it works its way through the segment, generating code or allocating data, it increments this value by one for each byte of generated code or allocated data. The expression $-VidIDStr is evaluated immediately after the string VidlDStr is allocated. This means the assembler's current location counter is pointing to the first byte after VidlDStr. Because the variable name VidlDStr itself resolves to the address of VidlDStr, and $ resolves to the location counter immediately after VidlDStr is allocated, $-VidIDStr evaluates to the length of VidlDStr. Even if you add or delete characters to the contents of VidlDStr, the length count will always come out correct, because the calculation always subtracts the address of the beginning of the string from the address just past the end of the string. file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm (48 of 58) [9/26/2002 9:20:33 PM] file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm (49 of 58) [9/26/2002 9:20:33 PM] file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm file:///D|/Agent%20Folders/Assembly%20Chap9%20Revised.htm (50 of 58) [9/26/2002 9:20:33 PM] [...]... Pascal and Microsoft BASIC The 80 86 /80 88 instruction set, on the other hand, is full of surprises, and the surprise most likely to make apprentice assembly- language programmers gasp is the instruction group we call the string instructions They alone of all the instructions in the 80 86 /80 88 instruction set have the power to deal with long sequences of bytes or words at one time (In assembly language, ... file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm (1 of 33) [9/ 28/ 2002 4: 08: 50 PM] file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm Most people, having learned a little assembly language, grumble about the seemingly huge number of instructions it takes to do anything useful By and large, this is a legitimate gripe and the major... copy of EAT5.ASM, and display some rulers on the screen You don't learn half as much by just reading assembly code as you do by loading and using it! Over and above the LOOP instruction, there's a fair amount of new assembly technology file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm (11 of 33) [9/ 28/ 2002 4: 08: 51 PM] file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm at... two operands The flags involved are the Carry flag (CF) and the Overflow flag (OF) For example, if you're multiplying two 8- bit operands and the product is larger than 8 bits, both CF and OF will be set Otherwise, the two flags will be cleared Now, why the final multiplication by 2? Keep in mind that every character position in the screen buffer is represented by two bytes: One character byte and one... file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm (2 of 33) [9/ 28/ 2002 4: 08: 50 PM] file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm a C string is said to end when a byte with a binary value of 0 is encountered In BASIC, strings are stored in something called string space, which has a lot of built-in code machinery associated with it When you begin working in assembly, you have to give all that high-level language. .. is given in bytes) by 2, in order to express the size of the refresh buffer in words file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm (7 of 33) [9/ 28/ 2002 4: 08: 51 PM] file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm As I explained in Chapter 9, dividing a value in a register by 2 is easy All you have to do is shift the value of the register to the right by one bit This... confused and think that DF also governs whether CX is incremented or decremented by the string instructions Not so! Nothing in a string instruction ever increments CX! You place a count in CX and it counts down, period DF has nothing to say about it file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm (8 of 33) [9/ 28/ 2002 4: 08: 51 PM] file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm... if there were a way to perform BCD addition on the 86 -family CPU, adding ASCII digits '1' and '1' would indeed give us '2' because '1' and '2' can be manipulated as legal file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm (17 of 33) [9/ 28/ 2002 4: 08: 51 PM] file:///D|/Agent%20Folders/Chapter%2010%2 0Assembly% 2 0Language. htm BCD values AAA (and several other instructions I don't have room to...file:///D|/Agent%20Folders /Assembly% 20Chap9%20Revised.htm file:///D|/Agent%20Folders /Assembly% 20Chap9%20Revised.htm (51 of 58) [9/26/2002 9:20:33 PM] file:///D|/Agent%20Folders /Assembly% 20Chap9%20Revised.htm file:///D|/Agent%20Folders /Assembly% 20Chap9%20Revised.htm (52 of 58) [9/26/2002 9:20:33 PM] file:///D|/Agent%20Folders /Assembly% 20Chap9%20Revised.htm file:///D|/Agent%20Folders /Assembly% 20Chap9%20Revised.htm (53 of 58) ... high-level language stuff over Assembly strings are just contiguous regions of memory They start at some specified segment:offset address, go for some number of bytes, and stop There is no "length byte" to tell how many bytes are in the string, and no standard boundary characters like binary 0 to indicate where a string starts or ends You can certainly write assembly- language routines that allocate . things like Turbo Pascal and Microsoft BASIC. The 80 86 /80 88 instruction set, on the other hand, is full of surprises, and the surprise most likely to make apprentice assembly- language programmers. instructions in the 80 86 /80 88 instruction set have the power to deal with long sequences of bytes or words at one time. (In assembly language, any contiguous sequence of bytes or words in memory. a table within a table within a table, but 80 86 /80 88 addressing only goes down two levels. What we must do is point BX and DI plus a displacement to the first of the three values, and then