MODULAR PROGRAMMING. Large project need to be broken into small modules with clean interfaces

Size: px

Start display at page:

Download "MODULAR PROGRAMMING. Large project need to be broken into small modules with clean interfaces"

Rosamond Dixon
5 years ago
Views:

1 MODULAR PROGRAMMING Large project need to be broken into small modules with clean interfaces The way to program a module should only depend on the interfaces provided by other modules not their implementation One possibility would be to place groups of related procedures into different files and then include them with the INCLUDE directive The INCLUDE directive instructs the assembler to include the file (at assembly time) at the place of the directive We must then ensure that the code will be placed in the segment and the data will be placed in the segment

2 Modular Programming (Continued) Hence, in each file, we should always put before the code and before the data In File MyProg.asm include Cs266.inc Msg1 DB "In Main", 10, 0 main: PUTSTR Msg1 CALL ProcA CALL ProcB include ProcA.asm include ProcB.asm In File ProcA.asm ProcA: PUTSTR Msg2 Msg2 DB "In ProcA", 10, 0 In File ProcB.asm ProcB PROC PUTSTR Msg3 ProcB ENDP Msg3 DB "In ProcB", 10, 0

3 Modular Programming (Continued) Hence, by doing Bcc32 MyProg.asm the assembler will create a single object file MyProg.obj which will contain all the included codes and data The scope of each used name (in any included file) will be the object module in which they will be assembled. Here it is MyProg.obj 1. Hence an error will be detected by the assembler if two different included files use the same name 2. Hence this method of included files should be avoided for large projects Instead, we should assemble each file separately to obtain a separate object module for each file and, thus, have a private namespace for each file Make sure, however, to use the.,.model Flat and directives in each files

4 Separate Assembly However, ny module that wants to be used need to provide at least one name to be used by others The directive PUBLIC enables other modules to use names defined in the module where PUBLIC is. Example PUBLIC ProcA, VarC, LabelB Note that the usage is the same for any kind of names (procedures, variables, labels,... ) The directive EXTRN declares names that are defined in other modules But now we need to provide the qualifiers 1. PROC for procedure names 2. BYTE, WORD, DWORD,... for variables names Example EXTRN ProcA:Proc, VarA:Dword, VarB:Word Place the directives EXTRN and PUBLIC just after.model Flat

5 Separate Assembly Example In File MyProg.asm extrn ProcA:Proc, ProcB:Proc include Cs266.inc Msg1 DB "In Main", 10, 0 main: PUTSTR Msg1 CALL ProcA CALL ProcB include ProcA.asm include ProcB.asm In File ProcA.asm public ProcA include Iomacros.inc ProcA: PUTSTR Msg1 Msg1 DB "In ProcA", 10, 0 In File ProcB.asm public ProcB include Iomacros.inc ProcB PROC PUTSTR Msg1 ProcB ENDP Msg1 DB "In ProcB", 10, 0

6 Separate Assembly Example (Continued) To assemble each file separately and link them, do bcc32 -c ProcA.asm bcc32 -c ProcB.asm bcc32 MyProg.asm ProcA.obj ProcB.obj 1. The -c is the Compile Only option: it only produces an object file 2. The last command will produce MyProg.obj and link all the.obj files to produce MyProg.exe All () segments will be concatenated into a single () segment Each.asm file now provides a separate namespace since each file has been assembled separately Note that all three files are using the same name Msg1. These refer to different memory locations since the assembler and linker will produce a different memory address for each variable Msg1

7 The Program s Entry Point An executable program must have only one entry point (the address of the first instruction to execute) This entry point must be called main and made public when using bcc32 to assemble and link 1. This is why I have included the following directive in Cs266.inc (near the top of the file) PUBLIC main Main EQU < main> The second directive make Main equivalent to main, so that Main can be used instead to label the entry point 2. But since a program can have only one entry point, these two directives must be present only in one.asm file: the one containing the entry point 3. If the macros in Cs266.inc are needed in other modules, then include instead another file, call Iomacro.inc, which is identical to Cs266.inc but does not contain these two directives (see previous example again)

8 Using Global Variables A variable made public in one object module will be accessible to every other object module that will be linked into the same.exe file As long as the other object modules are declaring this variable to be extern Such a variable, which is said to be global, can be used by procedures to pass a value across different modules 1. This mechanism increases the complexity of the interfaces (since every module must be aware of all the global variables 2. Hence, the number of global variables should be minimal

9 Global Variable Example In File MyProg.asm public VarA extrn ProcA:Proc include Cs266.inc VarA DD? main: MOV VarA 333 CALL ProcA In File ProcA.asm public ProcA extrn VarA:Dword include Iomacros.inc ProcA: PUTINT VarA To assemble and link, you can do bcc32 MyProg.asm ProcA.asm

Q. State and Explain steps involved in program development. [w-08, w-10, s-12, w-11]

Q. State and Explain steps involved in program development. [w-08, w-10, s-12, w-11] Answer: 1. Defining Problem 2. Algorithm 3. Flowchart 4. Initialization of checklist 5. Choosing instructions 6. Converting