1 / 23

Homework

Homework. Reading Assignment Professional Assembly Language, pp 39-59, 62-65 MP1 Get assignment file from my web page and study it Make and populate your UNIX mp1 subdirectory Study the source code for mp1 Lab 1 Load and Read Lab1 Write up GO TO LAB WITH YOUR SECTION!.

kalkin
Télécharger la présentation

Homework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Homework • Reading Assignment • Professional Assembly Language, pp 39-59, 62-65 • MP1 • Get assignment file from my web page and study it • Make and populate your UNIX mp1 subdirectory • Study the source code for mp1 • Lab 1 • Load and Read Lab1 Write up • GO TO LAB WITH YOUR SECTION!

  2. The SAPC “Big” Picture SAPC’s in Server Room (OS is “Tutor” not LINUX) ulab (OS is LINUX) COM2 Pico or vi IBM Compatible mtip COM2 IBM Compatible COM1 COM2 IBM Compatible SSH Communications On PC via Internet COM1 COM2 IBM Compatible Reset Server

  3. The “Big” Picture • LINUX system is your “development host” • SAPC is your “target machine” • SAPC does not normally have its keyboard, video monitor, or mouse attached! • SAPC COM1 and COM2 ports are cabled virtually to ports on the UNIX host “ulab”

  4. The “Big” Picture • You will use a UNIX system to edit your source files, compile and assemble them. • You will use the UNIX system as a server for downloading code to an SAPC • You may be using an SAPC • Locally in the SAPC lab via a terminal attached to one of its COM ports • Remotely via the UNIX system named “ulab”

  5. Picture of mtip “Session” SAPC ulab You mtip Tutor Transparent Relaying of Tutor commands ~d ~r file.lnx Memory Reset Server

  6. System Build Processes • The system build processes for C and assembly source courses are driven by our make files • However, it is important to understand how the component build steps work with the SW tools: Sun/UNIXIntel/SAPC gcc i386-gcc as i386-as (informally called “gas”) ld i386-ld nm i386-nm objdump i386-objdump (alias “disas”)

  7. Build for gcc Compilation C Source Code Translation Unit Assembly Code Object Code Executable File prog.c prog.i prog.s prog.o prog gcc -E gcc -S gcc -c gcc -o

  8. Build for i386-gcc Compilation C Source Code Translation Unit Assembly Code Object Code Executable File prog.c prog.i prog.s prog.opc prog.lnx i386-gcc -E i386-gcc -S i386-gcc -c i386-gcc -o

  9. Build for i386-gcc and i386-as C Source Code Object Code Executable File Assembly Code progc.c prog.s prog.opc prog.lnx i386-gcc -c i386-as i386-ld

  10. Build - Symbol Table Generation • The syms file shows the memory address assigned for each variable or source label Object Code Executable File Symbol File prog.opc prog.lnx syms i386-nm i386-nm

  11. Example: Test Program • Login to UNIX host “ulab” instead of “users” • We will compile and run a program named test.c on both Unix and an SAPC • Produce UNIX executable • Run it using ./test • Produce SAPC executable (.lnx extension) • Download to the SAPC • Run it • Exit from the SAPC

  12. Setup Test files on Unix • Make a subdirectory “test” on your cs341 • Copy these files to that directory • $pcex/makefile • $pcex/test.c • Note the name $pcex is defined by the ulab module in your .cshrc file. If you can’t use $pcex as a directory name, check your ulab module configuration in .cshrc

  13. Running test program on UNIX • Create the UNIX executable “test” ulab(60)% gcc –o test test.c • Execute it (avoiding conflict with UNIX “test”) ulab(61)% ./test • Follow the program’s directions. It should finish up quickly and hand control back to UNIX. You will see a UNIX prompt again. 

  14. Running a program on SAPC • Make the SAPC executable, test.lnx .  ulab(65)% make C=test test.lnx • The suffix “.lnx” is short for Linux, since we are using a Linux-defined executable format • Must be logged in on host ulab to use mtip • Otherwise, we get an error message: blade64(9)% mtip -f test.lnx . . . Sorry, no board currently available blade64(10)%

  15. Running a program on SAPC • Execute mtip to access an SAPC ulab(66)% mtip -f test.lnx • Obtains an SAPC for you and tells mtip the executable file you are planning to download • When you get an SAPC assigned, hit CR to get its Tutor prompt. • It’s safest to use ~r to reboot the SAPC which takes about 12 seconds.  (If an SAPC ever starts working weirdly, you should reboot it.)

  16. Running a program on SAPC • Type “~d” to download test.lnx • To execute the program, when you see the Tutor prompt again, type Tutor> go 100100 • Follow the program’s directions. It should finish up quickly and hand control back to Tutor. You will see Tutor prompt again. • You can run it again by command “go 100100”. • Type “~q” or two ctrl-Cs to quit out of mtip

  17. Analysis of Example • For UNIX or SAPCs, basic process to develop programs is the same - only different in the details • “Cross-compilation” is defined as the compilation of a program on one computer (Sun development host) for execution on another computer (SAPC target machine) • We used gcc to generate an executable file that will run on the Sun-based UNIX system • We used i386-gcc to generate an executable file that would NOT run on UNIX but will run on an SAPC

  18. Analysis of Example • Portability • Defined as ability to write source code so that it can run on two or more types of machines • Requires use of a different compiler/loader and library for each type of machine • Notice that the library functions called by the test program worked slightly differently on the two types of machines (as noted in the text produced by the test program)

  19. Analysis of Example • Another difference between the Unix system and the SAPC is the presence/ absence of an operating system • UNIX is an operating system that runs programs in a protected environment. Our code can not do some things such as access hardware directly • Tutor is a debug monitor only and does not run programs in a protected environment. Our code can access hardware directly as you’ll see later

  20. Machine Project 1 • In mp1, you will add commands to a program that is a simple version of the Tutor program that we just used on the SAPC • The program is “portable” so that it can be run on both the UNIX system and an SAPC • You will learn about some things about the differences between the UNIX environment and the SAPC environment

  21. Two Different Environments • How is our program loaded into memory? Unix/Sun SAPC 0x00000000 0x00000000 Reserved Reserved 0x00010000 Code 0x00020000 Data 0x00050000 Tutor 0x000A0000 Video Memory Reserved 0x000F0000 BIOS (ROM) 0x00100000 code data stack 0x003FFFFF Not Implemented Stack 0xFFFFFFFF 0xFFFFFFFF

  22. Machine Project 1 • Key to understanding “tutor” is a struct: typedef struct { char *cmdtoken; /* char string to invoke cmd */ int (*cmdfn)(); /* function to call for this cmd */ char *help; /* helpstring for cmd */ } cmd; cmd *cmdtoken ‘m’ ‘d’ ‘\0’ (*cmdfn) ( ) Function to process command *help ‘h’ ‘e’ ‘l’ ‘p’ ‘ ’ ‘t’ ‘e’ ‘x’ ‘t’ ‘\0’

  23. Machine Project 1 • Your job entails • Replacing the stub for the md command to: • Convert the character string to an integer • Use that integer as an address (a pointer to memory) • Find the contents of that address • Display the contents of that address to the terminal • Adding commands to the command table and writing code to make both of them work • Memory Set - ms • Help - h

More Related