The LC-3 – Chapter 7 COMP 2620 Dr. James Money COMP

Multiple File Assembly Language Programs Our purpose has been so far to show how to move up from machine code to assembly language We see that assembly language does save us a good deal of work This happens more so in C or C++

Multiple File Assembly Language Programs We also show how a two pass assembler system works for one input file There are a few topics we need to consider before we go on further – Executable images – More than one object file

Executable Images We the computer begins execution of a program, the entity being executed is called an executable image Many times, these are created from modules that are separate from each other by different programmers

Executable Images Each modules is assembled separately into an object file by the assembler The process we have discussed is the same for multiple modules However, some of the modules may have been written in C or C++ These are translated to object code as well

Executable Images Some of the rest of the modules are library routines provided by the operating system Some of the modules can be written by users Each object file, no matter how it was written originally, has the instructions, plus any associated data in memory

Executable Images The final step in this process to get an executable image is to link all the object modules together This creates one image file that can be run by the computer

More than one object file As we discussed before, it is very common to have more than one object file to link Matter of fact, it is unusually to have just one object file We can see this in our character counting example

More than one object file In this example, we have two parts – The assembly code to count the particular character – The file data for the characters that we are counting We would typically have these as two separate modules

More than one object file If this is the case, we more than likely would not know the location of the starting address of the file This is assigned at link time usually

More than one object file So, instead of the line PTR.FILLx4000 We would have PTR.FILLSTARTofFILE

More than one object file However, the compiler does not know where STARTofFILE is located now There is no entry for this label in the symbol table after the first pass The solution is to use the pseudo-op.EXTERNAL

More than one object file This specifies that a symbolic name is in another file We would have to include in our assembly file the command.EXTERNAL STARTofFILE This indicates the symbol is in another file and avoids an error

More than one object file Unfortunately, the current LC-3 language does not support this! However, in many other assembly languages, this exists and gets used extensively for external modules