Computer Science Department San Francisco State University CSC 413 Spring 2022 Assignment 5 - Debugger Due...
Fantastic news! We've Found the answer you've been seeking!
Question:
Transcribed Image Text:
Computer Science Department San Francisco State University CSC 413 Spring 2022 Assignment 5 - Debugger Due Date Wednesday, May 18, BEFORE MIDNIGHT No late submissions can be accepted for this assignment! Note that the due date applies to the last commit timestamp into the main branch of your repository. Overview The purpose of this assignment is to continue our work in the large compiler codebase, and implement a Debugger. You will be using your code for the Interpreter class, which must be copied into your github repository when you begin the assignment via this assignment link. Submission Your assignment will be submitted using github. Only the "main" branch of your repository will be graded. Late submission is determined by the last commit time on the "main" branch. You are required to submit a documentation PDF named "documentation.pdf" in a "documentation" folder at the root of your project. Implementation Requirements You may create additional classes as needed to implement the requirements defined here, but must implement at least those classes listed here. If you decide to add additional classes, they must follow object oriented design principles - proper encapsulation and data hiding, and implementing a single responsibility. Project Setup 1. You must be able to execute your program by typing: interpreter/debugger/commands/*.java javac javac interpreter/bytecode/*.java javac interpreter/bytecode/debuggercodes/*.java javac interpreter/Interpreter.java java interpreter. Interpreter Note that the Interpreter may now also be run in debugger mode by providing a switch (-d) and the base file name (instead of the fully qualified bytecode file name): java interpreter. Interpreter -d You may assume that the bytecode programs that are used for testing are generated correctly, and therefore should not contain any errors. Note that the assignment 5 skeleton code provides you with an updated main method in the Interpreter class to handle this switch! 2. Begin by replacing the placeholder classes in the project skeleton with your assignment 4 implementation. The following files should be replaced: a. Virtual Machine.java b. ByteCodeLoader.java c. CodeTable.java d. Program.java e. Any other supporting files you created or that you need(i.e. RuntimeStack). 3. Copy your byte code classes from your assignment 4 implementation into the bytecode package. New Implementation 1. You must add three new byte codes - LINE, FUNCTION, and FORMAL - to the set of byte codes we are implementing. All existing byte codes should continue to function, and may need to add behavior to support debugging. Bytecode Example LINE LINE n FORMAL FUNCTION FUNCTION name start end FUNCTION g 1 20 name is the name of the function, start is the source code line that this function starts on, and end is the source code line that this function ends on. FORMAL name offset LINE 5 FORMAL f1 0 FORMAL 2 1 Description n is the current source line number; the generated byte codes for line n will follow this code. FORMAL f1 0 name is the name of the formal parameter, offset is the stack offset for the variable. a. The FUNCTION and FORMAL byte codes will be generated as a header for each function declaration. The byte codes generated for each function will begin with: LABEL namel - branch label for function call start. function definition LINE n FUNCTION name start end I name of function with source line. number boundaries given by start and end fl is first formal with offset 0 f2 is second formal with offset 1 b. When debugging, we will not need to dump(), so no dump behavior is required for these byte codes. 2. You must implement the FunctionEnvironmentRecord that will be used to track the current function's state in the debugger. The FunctionEnvironmentRecord consists of a symbol table, a function name, the start and end lines of a function in the original source code file, and the current line number. Note that the current line number must be reset when branching instructions are processed. The symbol table works a lot like the symbol table implementation we saw in constraining, though it is slightly simpler - you may reuse the code from the Table class in the Constrainer, but you will need to make some modifications. The symbol table is modified as follows when the given byte codes are encountered: FORMAL xyz n LIT 0 i POP n enter ("xyz", n) enter ("i", current Offset) - delete the last n items entered into the symbol table Note the that class provided in the assignment 5 skeleton code includes a main method to help test your implementation. Compare the output from that main method to the correct output provided in main's function header. A simulation of the environment stack changes during a debugger execution for the factorial program is provided, with the environment stack shown, in Appendix A. A simulation of symbol table changes during a debugger execution for a simple program is provided in Appendix B. 3. You must provide debugger implementations for each of the byte codes discussed in class (implementations from assignment 4), in addition to three new byte codes that will be introduced to facilitate debugging. Note that byte codes for the debugger do everything they would do for the interpreter, with the addition of some behavior for debugging. a. Debugger byte codes must be placed in the sub package of interpreter.debugger created for this purpose in your assignment 5 skeleton: interpreter.bytecode. debuggercodes. 4. To accommodate these new byte codes, we need a DebuggerCodeTable. The interface for the DebuggerCodeTable is the same as the CodeTable, and only needs to include the new byte codes that are needed by the debugger (i.e. any byte code that requires additional behavior for debugging, and the three new byte codes described below). In the event that a byte code is not found in the Debugger Code Table, you will return the result of getting that code from the CodeTable. An implementation is provided for you, but you need to add your debugger byte codes to its initialization method. 5. In the debugger package, you must update the implementation for the Debugger that extends the Interpreter. a. Just after the Interpreter (Debugger) starts, and before the VM executes the first instruction, you should print the source program and then prompt the user for a command. This should be handled by the DebuggerShell object, described below. b. The Debugger will require some additional data structures in order to allow the user to debug a program: i. A Vector of entries where each Entry contains int lineNumber: The line number for this Entry String sourceLine: The source program line i for Vector slot i Boolean isBreakpointLine: Is a breakpoint set for this line? Accessors for these fields. ii. A Stack of FunctionEnvironmentRecords. A new record will be pushed when a function is entered, and popped when returning from a function. c. The following commands must be implemented by the debugger: ? i. Display available commands. Do not display the command list at any other time! Type? for help > ? set list locals source step continue exit Type ? for help > ii. set (set breakpoint) This command records that a breakpoint has been set for a specific line Type ? for help > set Enter line number: > 2 Type? for help > iii. list (list breakpoints) This command lists all breakpoints currently set with the debugger Type ? for help > list * 2: int factorial (int n) { Type ? for help > iv. source (display source) This command displays the source code of the current function, with an indication of where the execution has stopped (if executing), and any breakpoints that have been set: Type ? for help > source 1: program {boolean j int i int factorial (int n) { if (n < 2) then { return 1} -> * 2: 3: 4: 5: 6: 7: 8: 9: 10: } 11: } Type ? for help. > v. step This command causes execution to continue for one byte code (essentially the behavior of "step into"). There will be no output, apart from a new prompt (the user can choose to display source if they require output): Type ? for help > step Type ? for help. else {return n* factorial (n-1)} } while (1==1) { i = write (factorial (read())) vi. continue This command causes execution to continue. There will be no output, apart from a new prompt (if another break point is encountered). vii. locals This command prints a listing of all symbols in the current frame, with their values: Type ? for help. > locals i: 0 j: 0 Type ? for help viii. exit Immediately halts execution of the program: Type ? for help > exit assignment-5-debugger-spring-2020-jrob8577 git: (master) X 6. You must create classes for interaction with the user. Any UI classes must be created in the interpreter.debugger.ui package. a. A class DebuggerShell must be implemented to encapsulate prompting the user for a command. The prompt should be: Type ? for help > The DebuggerShell class should display the prompt, wait for a user command, validate that the command is allowed, and return an instance of Debugger Command to the Debugger. Follow the strategy pattern to implement concrete DebuggerCommands for each of the required commands. b. Whenever the debugger stops, the source code should be displayed, with an indication of: i. Breakpoints (indicated by *) ii. Current line of code that is executing (indicated by ->) -> * 2: 3: 4: 5: 6: 7: 8: 9: 10: } 11: } 7. In the debugger package, you must provide an implementation for the DebuggerVirtual Machine that extends the Virtual Machine. This extension will add any methods necessary to manage the debugging session. 1: program {boolean j int i int factorial (int n) { GOTO start < <1>> LABEL start < <1>> LINE 1 FUNCTION main 1 11 LIT 0 j LIT 0 i GOTO continue < <3>> LABEL continue < <3>> LABEL while < <7>> LINE 8 LIT 1 LIT 1 == Testing Requirements A test program is provided for you (factorial.x and factorial.x.cod) in the sample_files directory of the assignment 5 project skeleton. LABEL Read LINE -1 Appendix A: Example of Environment Stack changes Note: this is not expected output! This just shows how the function environment stack changes in the debugger during execution. Also, the stack is growing downwards in this example. Bytecode FUNCTION Read -1 -1 READ RETURN if (n < 2) then { return 1} else FALSEBRANCH continue < <6>> LINE 9 ARGS 0 CALL Read ARGS 1 CALL factorial < <2>> } while (1==1) { {return n* factorial (n-1) } LABEL factorial < <2>> LINE 2 i write (factorial (read ())) Environment Stack (symbol table, start, end, name, currentLine) -, -> < -1 1 > < (), 1, 11, main, 1 > < ( ), 1, 11, main, 1 > < ( , ), 1, 11, main, 1 > < ( , ), 1, 11, main, 8 > < ( , ), 1, 11, main, 9 > < ( , ), 1, 11, main, 9 > < (), -, -, -, -> < ( , ), 1, 11, main, 9 > < (), -, -, -, -1 > < ( , ), 1, 11, main, 9 > < (), -1, -1, Read, -1 > < ( , ), 1, 11, main, 9 > (Return to line 9) < ( , ), 1, 11, main, 9 > < (), -, -, -, -> < ( , ), 1, 11, main, 9 > FUNCTION factorial 27 FORMAL n 0 LINE 3 LOAD 0 n LIT 2 BOP < FALSEBRANCH else < <4>> LABEL else < <4>> LINE 6 LOAD 0 n LOAD 0 n LIT 1 ARGS 1 CALL factorial < <2>> LABEL factorial < <2>> LINE 2 FUNCTION factorial 2 7 FORMAL n 0 LINE 3 LOAD 0 n LIT 2 BOP < FALSEBRANCH else < <4>> ... etc. < (), -, 2 > < ( , ), 1, 11, main, 9 > < (), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 3 > < < ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < < < (), -, -, -, - > ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < < < ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < (), -, -, -, 2 > ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < (), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < ( ), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < ( ), 2, 7, factorial, 3 > Appendix B Consider the following x program snippet: 8. int f() { int j int k 9. { int j j = 1 10. } j = 2 11. 12. } The following is the generated byte codes for this function declaration, along with the state of the symbol table, and the symbol table method called: LABEL f < <2>> LINE 8 FUNCTION f 8 12 LIT 0 j LIT 0 k LINE 9 LIT 0 j LIT 1 STORE 2 POP 1 LINE 11 LIT 2 STORE 0 POP 2 RETURN f < <2>> create symbol table, beginScope < (), -, -, -> < (), - - 8 > < (). 8, 12, f, 8 > enter j < ( ), 8, 12, f, 8 > enter k < ( ), 8, 12, f, 8 > < ( ), 8, 12, f, 9 > enter j; symbol table will link to prior entry for j < ( - ), 8, 12, f, 9 > remove last symbol entered, thereby restoring linked entry of j < ( ), 8, 12, f, 9 > < ( ), 8, 12, f, 11 > remove last two symbols < (), 8, 12, f, 11> Computer Science Department San Francisco State University CSC 413 Spring 2022 Assignment 5 - Debugger Due Date Wednesday, May 18, BEFORE MIDNIGHT No late submissions can be accepted for this assignment! Note that the due date applies to the last commit timestamp into the main branch of your repository. Overview The purpose of this assignment is to continue our work in the large compiler codebase, and implement a Debugger. You will be using your code for the Interpreter class, which must be copied into your github repository when you begin the assignment via this assignment link. Submission Your assignment will be submitted using github. Only the "main" branch of your repository will be graded. Late submission is determined by the last commit time on the "main" branch. You are required to submit a documentation PDF named "documentation.pdf" in a "documentation" folder at the root of your project. Implementation Requirements You may create additional classes as needed to implement the requirements defined here, but must implement at least those classes listed here. If you decide to add additional classes, they must follow object oriented design principles - proper encapsulation and data hiding, and implementing a single responsibility. Project Setup 1. You must be able to execute your program by typing: interpreter/debugger/commands/*.java javac javac interpreter/bytecode/*.java javac interpreter/bytecode/debuggercodes/*.java javac interpreter/Interpreter.java java interpreter. Interpreter Note that the Interpreter may now also be run in debugger mode by providing a switch (-d) and the base file name (instead of the fully qualified bytecode file name): java interpreter. Interpreter -d You may assume that the bytecode programs that are used for testing are generated correctly, and therefore should not contain any errors. Note that the assignment 5 skeleton code provides you with an updated main method in the Interpreter class to handle this switch! 2. Begin by replacing the placeholder classes in the project skeleton with your assignment 4 implementation. The following files should be replaced: a. Virtual Machine.java b. ByteCodeLoader.java Computer Science Department San Francisco State University CSC 413 Spring 2022 Assignment 5 - Debugger Due Date Wednesday, May 18, BEFORE MIDNIGHT No late submissions can be accepted for this assignment! Note that the due date applies to the last commit timestamp into the main branch of your repository. Overview The purpose of this assignment is to continue our work in the large compiler codebase, and implement a Debugger. You will be using your code for the Interpreter class, which must be copied into your github repository when you begin the assignment via this assignment link. Submission Your assignment will be submitted using github. Only the "main" branch of your repository will be graded. Late submission is determined by the last commit time on the "main" branch. You are required to submit a documentation PDF named "documentation.pdf" in a "documentation" folder at the root of your project. Implementation Requirements You may create additional classes as needed to implement the requirements defined here, but must implement at least those classes listed here. If you decide to add additional classes, they must follow object oriented design principles - proper encapsulation and data hiding, and implementing a single responsibility. Project Setup 1. You must be able to execute your program by typing: interpreter/debugger/commands/*.java javac javac interpreter/bytecode/*.java javac interpreter/bytecode/debuggercodes/*.java javac interpreter/Interpreter.java java interpreter. Interpreter Note that the Interpreter may now also be run in debugger mode by providing a switch (-d) and the base file name (instead of the fully qualified bytecode file name): java interpreter. Interpreter -d You may assume that the bytecode programs that are used for testing are generated correctly, and therefore should not contain any errors. Note that the assignment 5 skeleton code provides you with an updated main method in the Interpreter class to handle this switch! 2. Begin by replacing the placeholder classes in the project skeleton with your assignment 4 implementation. The following files should be replaced: a. Virtual Machine.java b. ByteCodeLoader.java Computer Science Department San Francisco State University CSC 413 Spring 2022 Assignment 5 - Debugger Due Date Wednesday, May 18, BEFORE MIDNIGHT No late submissions can be accepted for this assignment! Note that the due date applies to the last commit timestamp into the main branch of your repository. Overview The purpose of this assignment is to continue our work in the large compiler codebase, and implement a Debugger. You will be using your code for the Interpreter class, which must be copied into your github repository when you begin the assignment via this assignment link. Submission Your assignment will be submitted using github. Only the "main" branch of your repository will be graded. Late submission is determined by the last commit time on the "main" branch. You are required to submit a documentation PDF named "documentation.pdf" in a "documentation" folder at the root of your project. Implementation Requirements You may create additional classes as needed to implement the requirements defined here, but must implement at least those classes listed here. If you decide to add additional classes, they must follow object oriented design principles - proper encapsulation and data hiding, and implementing a single responsibility. Project Setup 1. You must be able to execute your program by typing: interpreter/debugger/commands/*.java javac javac interpreter/bytecode/*.java javac interpreter/bytecode/debuggercodes/*.java javac interpreter/Interpreter.java java interpreter. Interpreter Note that the Interpreter may now also be run in debugger mode by providing a switch (-d) and the base file name (instead of the fully qualified bytecode file name): java interpreter. Interpreter -d You may assume that the bytecode programs that are used for testing are generated correctly, and therefore should not contain any errors. Note that the assignment 5 skeleton code provides you with an updated main method in the Interpreter class to handle this switch! 2. Begin by replacing the placeholder classes in the project skeleton with your assignment 4 implementation. The following files should be replaced: a. Virtual Machine.java b. ByteCodeLoader.java Computer Science Department San Francisco State University CSC 413 Spring 2022 Assignment 5 - Debugger Due Date Wednesday, May 18, BEFORE MIDNIGHT No late submissions can be accepted for this assignment! Note that the due date applies to the last commit timestamp into the main branch of your repository. Overview The purpose of this assignment is to continue our work in the large compiler codebase, and implement a Debugger. You will be using your code for the Interpreter class, which must be copied into your github repository when you begin the assignment via this assignment link. Submission Your assignment will be submitted using github. Only the "main" branch of your repository will be graded. Late submission is determined by the last commit time on the "main" branch. You are required to submit a documentation PDF named "documentation.pdf" in a "documentation" folder at the root of your project. Implementation Requirements You may create additional classes as needed to implement the requirements defined here, but must implement at least those classes listed here. If you decide to add additional classes, they must follow object oriented design principles - proper encapsulation and data hiding, and implementing a single responsibility. Project Setup 1. You must be able to execute your program by typing: interpreter/debugger/commands/*.java javac javac interpreter/bytecode/*.java javac interpreter/bytecode/debuggercodes/*.java javac interpreter/Interpreter.java java interpreter. Interpreter Note that the Interpreter may now also be run in debugger mode by providing a switch (-d) and the base file name (instead of the fully qualified bytecode file name): java interpreter. Interpreter -d You may assume that the bytecode programs that are used for testing are generated correctly, and therefore should not contain any errors. Note that the assignment 5 skeleton code provides you with an updated main method in the Interpreter class to handle this switch! 2. Begin by replacing the placeholder classes in the project skeleton with your assignment 4 implementation. The following files should be replaced: a. Virtual Machine.java b. ByteCodeLoader.java Computer Science Department San Francisco State University CSC 413 Spring 2022 Assignment 5 - Debugger Due Date Wednesday, May 18, BEFORE MIDNIGHT No late submissions can be accepted for this assignment! Note that the due date applies to the last commit timestamp into the main branch of your repository. Overview The purpose of this assignment is to continue our work in the large compiler codebase, and implement a Debugger. You will be using your code for the Interpreter class, which must be copied into your github repository when you begin the assignment via this assignment link. Submission Your assignment will be submitted using github. Only the "main" branch of your repository will be graded. Late submission is determined by the last commit time on the "main" branch. You are required to submit a documentation PDF named "documentation.pdf" in a "documentation" folder at the root of your project. Implementation Requirements You may create additional classes as needed to implement the requirements defined here, but must implement at least those classes listed here. If you decide to add additional classes, they must follow object oriented design principles - proper encapsulation and data hiding, and implementing a single responsibility. Project Setup 1. You must be able to execute your program by typing: interpreter/debugger/commands/*.java javac javac interpreter/bytecode/*.java javac interpreter/bytecode/debuggercodes/*.java javac interpreter/Interpreter.java java interpreter. Interpreter Note that the Interpreter may now also be run in debugger mode by providing a switch (-d) and the base file name (instead of the fully qualified bytecode file name): java interpreter. Interpreter -d You may assume that the bytecode programs that are used for testing are generated correctly, and therefore should not contain any errors. Note that the assignment 5 skeleton code provides you with an updated main method in the Interpreter class to handle this switch! 2. Begin by replacing the placeholder classes in the project skeleton with your assignment 4 implementation. The following files should be replaced: a. Virtual Machine.java b. ByteCodeLoader.java c. CodeTable.java d. Program.java e. Any other supporting files you created or that you need(i.e. RuntimeStack). 3. Copy your byte code classes from your assignment 4 implementation into the bytecode package. New Implementation 1. You must add three new byte codes - LINE, FUNCTION, and FORMAL - to the set of byte codes we are implementing. All existing byte codes should continue to function, and may need to add behavior to support debugging. Bytecode Example LINE LINE n FORMAL FUNCTION FUNCTION name start end FUNCTION g 1 20 name is the name of the function, start is the source code line that this function starts on, and end is the source code line that this function ends on. FORMAL name offset LINE 5 FORMAL f1 0 FORMAL 2 1 Description n is the current source line number; the generated byte codes for line n will follow this code. FORMAL f1 0 name is the name of the formal parameter, offset is the stack offset for the variable. a. The FUNCTION and FORMAL byte codes will be generated as a header for each function declaration. The byte codes generated for each function will begin with: LABEL namel - branch label for function call start. function definition LINE n FUNCTION name start end I name of function with source line. number boundaries given by start and end fl is first formal with offset 0 f2 is second formal with offset 1 b. When debugging, we will not need to dump(), so no dump behavior is required for these byte codes. 2. You must implement the FunctionEnvironmentRecord that will be used to track the current function's state in the debugger. The FunctionEnvironmentRecord consists of a symbol table, a function name, the start and end lines of a function in the original source code file, and the current line number. Note that the current line number must be reset when branching instructions are processed. The symbol table works a lot like the symbol table implementation we saw in constraining, though it is slightly simpler - you may reuse the code from the Table class in the Constrainer, but you will need to make some modifications. The symbol table is modified as follows when the given byte codes are encountered: FORMAL xyz n LIT 0 i POP n enter ("xyz", n) enter ("i", current Offset) - delete the last n items entered into the symbol table Note the that class provided in the assignment 5 skeleton code includes a main method to help test your implementation. Compare the output from that main method to the correct output provided in main's function header. A simulation of the environment stack changes during a debugger execution for the factorial program is provided, with the environment stack shown, in Appendix A. A simulation of symbol table changes during a debugger execution for a simple program is provided in Appendix B. 3. You must provide debugger implementations for each of the byte codes discussed in class (implementations from assignment 4), in addition to three new byte codes that will be introduced to facilitate debugging. Note that byte codes for the debugger do everything they would do for the interpreter, with the addition of some behavior for debugging. a. Debugger byte codes must be placed in the sub package of interpreter.debugger created for this purpose in your assignment 5 skeleton: interpreter.bytecode. debuggercodes. 4. To accommodate these new byte codes, we need a DebuggerCodeTable. The interface for the DebuggerCodeTable is the same as the CodeTable, and only needs to include the new byte codes that are needed by the debugger (i.e. any byte code that requires additional behavior for debugging, and the three new byte codes described below). In the event that a byte code is not found in the Debugger Code Table, you will return the result of getting that code from the CodeTable. An implementation is provided for you, but you need to add your debugger byte codes to its initialization method. 5. In the debugger package, you must update the implementation for the Debugger that extends the Interpreter. a. Just after the Interpreter (Debugger) starts, and before the VM executes the first instruction, you should print the source program and then prompt the user for a command. This should be handled by the DebuggerShell object, described below. b. The Debugger will require some additional data structures in order to allow the user to debug a program: i. A Vector of entries where each Entry contains int lineNumber: The line number for this Entry String sourceLine: The source program line i for Vector slot i Boolean isBreakpointLine: Is a breakpoint set for this line? Accessors for these fields. ii. A Stack of FunctionEnvironmentRecords. A new record will be pushed when a function is entered, and popped when returning from a function. c. The following commands must be implemented by the debugger: ? i. Display available commands. Do not display the command list at any other time! Type? for help > ? set list locals source step continue exit Type ? for help > ii. set (set breakpoint) This command records that a breakpoint has been set for a specific line Type ? for help > set Enter line number: > 2 Type? for help > iii. list (list breakpoints) This command lists all breakpoints currently set with the debugger Type ? for help c. CodeTable.java d. Program.java e. Any other supporting files you created or that you need(i.e. RuntimeStack). 3. Copy your byte code classes from your assignment 4 implementation into the bytecode package. New Implementation 1. You must add three new byte codes - LINE, FUNCTION, and FORMAL - to the set of byte codes we are implementing. All existing byte codes should continue to function, and may need to add behavior to support debugging. Bytecode Example LINE LINE n FORMAL FUNCTION FUNCTION name start end FUNCTION g 1 20 name is the name of the function, start is the source code line that this function starts on, and end is the source code line that this function ends on. FORMAL name offset LINE 5 FORMAL f1 0 FORMAL 2 1 Description n is the current source line number; the generated byte codes for line n will follow this code. FORMAL f1 0 name is the name of the formal parameter, offset is the stack offset for the variable. a. The FUNCTION and FORMAL byte codes will be generated as a header for each function declaration. The byte codes generated for each function will begin with: LABEL namel - branch label for function call start. function definition LINE n FUNCTION name start end I name of function with source line. number boundaries given by start and end fl is first formal with offset 0 f2 is second formal with offset 1 b. When debugging, we will not need to dump(), so no dump behavior is required for these byte codes. 2. You must implement the FunctionEnvironmentRecord that will be used to track the current function's state in the debugger. The FunctionEnvironmentRecord consists of a symbol table, a function name, the start and end lines of a function in the original source code file, and the current line number. Note that the current line number must be reset when branching instructions are processed. The symbol table works a lot like the symbol table implementation we saw in constraining, though it is slightly simpler - you may reuse the code from the Table class in the Constrainer, but you will need to make some modifications. The symbol table is modified as follows when the given byte codes are encountered: FORMAL xyz n LIT 0 i POP n enter ("xyz", n) enter ("i", current Offset) - delete the last n items entered into the symbol table Note the that class provided in the assignment 5 skeleton code includes a main method to help test your implementation. Compare the output from that main method to the correct output provided in main's function header. A simulation of the environment stack changes during a debugger execution for the factorial program is provided, with the environment stack shown, in Appendix A. A simulation of symbol table changes during a debugger execution for a simple program is provided in Appendix B. 3. You must provide debugger implementations for each of the byte codes discussed in class (implementations from assignment 4), in addition to three new byte codes that will be introduced to facilitate debugging. Note that byte codes for the debugger do everything they would do for the interpreter, with the addition of some behavior for debugging. a. Debugger byte codes must be placed in the sub package of interpreter.debugger created for this purpose in your assignment 5 skeleton: interpreter.bytecode. debuggercodes. 4. To accommodate these new byte codes, we need a DebuggerCodeTable. The interface for the DebuggerCodeTable is the same as the CodeTable, and only needs to include the new byte codes that are needed by the debugger (i.e. any byte code that requires additional behavior for debugging, and the three new byte codes described below). In the event that a byte code is not found in the Debugger Code Table, you will return the result of getting that code from the CodeTable. An implementation is provided for you, but you need to add your debugger byte codes to its initialization method. 5. In the debugger package, you must update the implementation for the Debugger that extends the Interpreter. a. Just after the Interpreter (Debugger) starts, and before the VM executes the first instruction, you should print the source program and then prompt the user for a command. This should be handled by the DebuggerShell object, described below. b. The Debugger will require some additional data structures in order to allow the user to debug a program: i. A Vector of entries where each Entry contains int lineNumber: The line number for this Entry String sourceLine: The source program line i for Vector slot i Boolean isBreakpointLine: Is a breakpoint set for this line? Accessors for these fields. ii. A Stack of FunctionEnvironmentRecords. A new record will be pushed when a function is entered, and popped when returning from a function. c. The following commands must be implemented by the debugger: ? i. Display available commands. Do not display the command list at any other time! Type? for help > ? set list locals source step continue exit Type ? for help > ii. set (set breakpoint) This command records that a breakpoint has been set for a specific line Type ? for help > set Enter line number: > 2 Type? for help > iii. list (list breakpoints) This command lists all breakpoints currently set with the debugger Type ? for help c. CodeTable.java d. Program.java e. Any other supporting files you created or that you need(i.e. RuntimeStack). 3. Copy your byte code classes from your assignment 4 implementation into the bytecode package. New Implementation 1. You must add three new byte codes - LINE, FUNCTION, and FORMAL - to the set of byte codes we are implementing. All existing byte codes should continue to function, and may need to add behavior to support debugging. Bytecode Example LINE LINE n FORMAL FUNCTION FUNCTION name start end FUNCTION g 1 20 name is the name of the function, start is the source code line that this function starts on, and end is the source code line that this function ends on. FORMAL name offset LINE 5 FORMAL f1 0 FORMAL 2 1 Description n is the current source line number; the generated byte codes for line n will follow this code. FORMAL f1 0 name is the name of the formal parameter, offset is the stack offset for the variable. a. The FUNCTION and FORMAL byte codes will be generated as a header for each function declaration. The byte codes generated for each function will begin with: LABEL namel - branch label for function call start. function definition LINE n FUNCTION name start end I name of function with source line. number boundaries given by start and end fl is first formal with offset 0 f2 is second formal with offset 1 b. When debugging, we will not need to dump(), so no dump behavior is required for these byte codes. 2. You must implement the FunctionEnvironmentRecord that will be used to track the current function's state in the debugger. The FunctionEnvironmentRecord consists of a symbol table, a function name, the start and end lines of a function in the original source code file, and the current line number. Note that the current line number must be reset when branching instructions are processed. The symbol table works a lot like the symbol table implementation we saw in constraining, though it is slightly simpler - you may reuse the code from the Table class in the Constrainer, but you will need to make some modifications. The symbol table is modified as follows when the given byte codes are encountered: FORMAL xyz n LIT 0 i POP n enter ("xyz", n) enter ("i", current Offset) - delete the last n items entered into the symbol table Note the that class provided in the assignment 5 skeleton code includes a main method to help test your implementation. Compare the output from that main method to the correct output provided in main's function header. A simulation of the environment stack changes during a debugger execution for the factorial program is provided, with the environment stack shown, in Appendix A. A simulation of symbol table changes during a debugger execution for a simple program is provided in Appendix B. 3. You must provide debugger implementations for each of the byte codes discussed in class (implementations from assignment 4), in addition to three new byte codes that will be introduced to facilitate debugging. Note that byte codes for the debugger do everything they would do for the interpreter, with the addition of some behavior for debugging. a. Debugger byte codes must be placed in the sub package of interpreter.debugger created for this purpose in your assignment 5 skeleton: interpreter.bytecode. debuggercodes. 4. To accommodate these new byte codes, we need a DebuggerCodeTable. The interface for the DebuggerCodeTable is the same as the CodeTable, and only needs to include the new byte codes that are needed by the debugger (i.e. any byte code that requires additional behavior for debugging, and the three new byte codes described below). In the event that a byte code is not found in the Debugger Code Table, you will return the result of getting that code from the CodeTable. An implementation is provided for you, but you need to add your debugger byte codes to its initialization method. 5. In the debugger package, you must update the implementation for the Debugger that extends the Interpreter. a. Just after the Interpreter (Debugger) starts, and before the VM executes the first instruction, you should print the source program and then prompt the user for a command. This should be handled by the DebuggerShell object, described below. b. The Debugger will require some additional data structures in order to allow the user to debug a program: i. A Vector of entries where each Entry contains int lineNumber: The line number for this Entry String sourceLine: The source program line i for Vector slot i Boolean isBreakpointLine: Is a breakpoint set for this line? Accessors for these fields. ii. A Stack of FunctionEnvironmentRecords. A new record will be pushed when a function is entered, and popped when returning from a function. c. The following commands must be implemented by the debugger: ? i. Display available commands. Do not display the command list at any other time! Type? for help > ? set list locals source step continue exit Type ? for help > ii. set (set breakpoint) This command records that a breakpoint has been set for a specific line Type ? for help > set Enter line number: > 2 Type? for help > iii. list (list breakpoints) This command lists all breakpoints currently set with the debugger Type ? for help c. CodeTable.java d. Program.java e. Any other supporting files you created or that you need(i.e. RuntimeStack). 3. Copy your byte code classes from your assignment 4 implementation into the bytecode package. New Implementation 1. You must add three new byte codes - LINE, FUNCTION, and FORMAL - to the set of byte codes we are implementing. All existing byte codes should continue to function, and may need to add behavior to support debugging. Bytecode Example LINE LINE n FORMAL FUNCTION FUNCTION name start end FUNCTION g 1 20 name is the name of the function, start is the source code line that this function starts on, and end is the source code line that this function ends on. FORMAL name offset LINE 5 FORMAL f1 0 FORMAL 2 1 Description n is the current source line number; the generated byte codes for line n will follow this code. FORMAL f1 0 name is the name of the formal parameter, offset is the stack offset for the variable. a. The FUNCTION and FORMAL byte codes will be generated as a header for each function declaration. The byte codes generated for each function will begin with: LABEL namel - branch label for function call start. function definition LINE n FUNCTION name start end I name of function with source line. number boundaries given by start and end fl is first formal with offset 0 f2 is second formal with offset 1 b. When debugging, we will not need to dump(), so no dump behavior is required for these byte codes. 2. You must implement the FunctionEnvironmentRecord that will be used to track the current function's state in the debugger. The FunctionEnvironmentRecord consists of a symbol table, a function name, the start and end lines of a function in the original source code file, and the current line number. Note that the current line number must be reset when branching instructions are processed. The symbol table works a lot like the symbol table implementation we saw in constraining, though it is slightly simpler - you may reuse the code from the Table class in the Constrainer, but you will need to make some modifications. The symbol table is modified as follows when the given byte codes are encountered: FORMAL xyz n LIT 0 i POP n enter ("xyz", n) enter ("i", current Offset) - delete the last n items entered into the symbol table Note the that class provided in the assignment 5 skeleton code includes a main method to help test your implementation. Compare the output from that main method to the correct output provided in main's function header. A simulation of the environment stack changes during a debugger execution for the factorial program is provided, with the environment stack shown, in Appendix A. A simulation of symbol table changes during a debugger execution for a simple program is provided in Appendix B. 3. You must provide debugger implementations for each of the byte codes discussed in class (implementations from assignment 4), in addition to three new byte codes that will be introduced to facilitate debugging. Note that byte codes for the debugger do everything they would do for the interpreter, with the addition of some behavior for debugging. a. Debugger byte codes must be placed in the sub package of interpreter.debugger created for this purpose in your assignment 5 skeleton: interpreter.bytecode. debuggercodes. 4. To accommodate these new byte codes, we need a DebuggerCodeTable. The interface for the DebuggerCodeTable is the same as the CodeTable, and only needs to include the new byte codes that are needed by the debugger (i.e. any byte code that requires additional behavior for debugging, and the three new byte codes described below). In the event that a byte code is not found in the Debugger Code Table, you will return the result of getting that code from the CodeTable. An implementation is provided for you, but you need to add your debugger byte codes to its initialization method. 5. In the debugger package, you must update the implementation for the Debugger that extends the Interpreter. a. Just after the Interpreter (Debugger) starts, and before the VM executes the first instruction, you should print the source program and then prompt the user for a command. This should be handled by the DebuggerShell object, described below. b. The Debugger will require some additional data structures in order to allow the user to debug a program: i. A Vector of entries where each Entry contains int lineNumber: The line number for this Entry String sourceLine: The source program line i for Vector slot i Boolean isBreakpointLine: Is a breakpoint set for this line? Accessors for these fields. ii. A Stack of FunctionEnvironmentRecords. A new record will be pushed when a function is entered, and popped when returning from a function. c. The following commands must be implemented by the debugger: ? i. Display available commands. Do not display the command list at any other time! Type? for help > ? set list locals source step continue exit Type ? for help > ii. set (set breakpoint) This command records that a breakpoint has been set for a specific line Type ? for help > set Enter line number: > 2 Type? for help > iii. list (list breakpoints) This command lists all breakpoints currently set with the debugger Type ? for help c. CodeTable.java d. Program.java e. Any other supporting files you created or that you need(i.e. RuntimeStack). 3. Copy your byte code classes from your assignment 4 implementation into the bytecode package. New Implementation 1. You must add three new byte codes - LINE, FUNCTION, and FORMAL - to the set of byte codes we are implementing. All existing byte codes should continue to function, and may need to add behavior to support debugging. Bytecode Example LINE LINE n FORMAL FUNCTION FUNCTION name start end FUNCTION g 1 20 name is the name of the function, start is the source code line that this function starts on, and end is the source code line that this function ends on. FORMAL name offset LINE 5 FORMAL f1 0 FORMAL 2 1 Description n is the current source line number; the generated byte codes for line n will follow this code. FORMAL f1 0 name is the name of the formal parameter, offset is the stack offset for the variable. a. The FUNCTION and FORMAL byte codes will be generated as a header for each function declaration. The byte codes generated for each function will begin with: LABEL namel - branch label for function call start. function definition LINE n FUNCTION name start end I name of function with source line. number boundaries given by start and end fl is first formal with offset 0 f2 is second formal with offset 1 b. When debugging, we will not need to dump(), so no dump behavior is required for these byte codes. 2. You must implement the FunctionEnvironmentRecord that will be used to track the current function's state in the debugger. The FunctionEnvironmentRecord consists of a symbol table, a function name, the start and end lines of a function in the original source code file, and the current line number. Note that the current line number must be reset when branching instructions are processed. The symbol table works a lot like the symbol table implementation we saw in constraining, though it is slightly simpler - you may reuse the code from the Table class in the Constrainer, but you will need to make some modifications. The symbol table is modified as follows when the given byte codes are encountered: FORMAL xyz n LIT 0 i POP n enter ("xyz", n) enter ("i", current Offset) - delete the last n items entered into the symbol table Note the that class provided in the assignment 5 skeleton code includes a main method to help test your implementation. Compare the output from that main method to the correct output provided in main's function header. A simulation of the environment stack changes during a debugger execution for the factorial program is provided, with the environment stack shown, in Appendix A. A simulation of symbol table changes during a debugger execution for a simple program is provided in Appendix B. 3. You must provide debugger implementations for each of the byte codes discussed in class (implementations from assignment 4), in addition to three new byte codes that will be introduced to facilitate debugging. Note that byte codes for the debugger do everything they would do for the interpreter, with the addition of some behavior for debugging. a. Debugger byte codes must be placed in the sub package of interpreter.debugger created for this purpose in your assignment 5 skeleton: interpreter.bytecode. debuggercodes. 4. To accommodate these new byte codes, we need a DebuggerCodeTable. The interface for the DebuggerCodeTable is the same as the CodeTable, and only needs to include the new byte codes that are needed by the debugger (i.e. any byte code that requires additional behavior for debugging, and the three new byte codes described below). In the event that a byte code is not found in the Debugger Code Table, you will return the result of getting that code from the CodeTable. An implementation is provided for you, but you need to add your debugger byte codes to its initialization method. 5. In the debugger package, you must update the implementation for the Debugger that extends the Interpreter. a. Just after the Interpreter (Debugger) starts, and before the VM executes the first instruction, you should print the source program and then prompt the user for a command. This should be handled by the DebuggerShell object, described below. b. The Debugger will require some additional data structures in order to allow the user to debug a program: i. A Vector of entries where each Entry contains int lineNumber: The line number for this Entry String sourceLine: The source program line i for Vector slot i Boolean isBreakpointLine: Is a breakpoint set for this line? Accessors for these fields. ii. A Stack of FunctionEnvironmentRecords. A new record will be pushed when a function is entered, and popped when returning from a function. c. The following commands must be implemented by the debugger: ? i. Display available commands. Do not display the command list at any other time! Type? for help > ? set list locals source step continue exit Type ? for help > ii. set (set breakpoint) This command records that a breakpoint has been set for a specific line Type ? for help > set Enter line number: > 2 Type? for help > iii. list (list breakpoints) This command lists all breakpoints currently set with the debugger Type ? for help > list * 2: int factorial (int n) { Type ? for help > iv. source (display source) This command displays the source code of the current function, with an indication of where the execution has stopped (if executing), and any breakpoints that have been set: Type ? for help > source 1: program {boolean j int i int factorial (int n) { if (n < 2) then { return 1} -> * 2: 3: 4: 5: 6: 7: 8: 9: 10: } 11: } Type ? for help. > v. step This command causes execution to continue for one byte code (essentially the behavior of "step into"). There will be no output, apart from a new prompt (the user can choose to display source if they require output): Type ? for help > step Type ? for help. else {return n* factorial (n-1)} } while (1==1) { i = write (factorial (read())) vi. continue This command causes execution to continue. There will be no output, apart from a new prompt (if another break point is encountered). vii. locals This command prints a listing of all symbols in the current frame, with their values: Type ? for help. > locals i: 0 j: 0 Type ? for help viii. exit Immediately halts execution of the program: Type ? for help > exit assignment-5-debugger-spring-2020-jrob8577 git: (master) X 6. You must create classes for interaction with the user. Any UI classes must be created in the interpreter.debugger.ui package. a. A class DebuggerShell must be implemented to encapsulate prompting the user for a command. The prompt should be: Type ? for help > The DebuggerShell class should display the prompt, wait for a user command, validate that the command is allowed, and return an instance of Debugger Command to the Debugger. Follow the strategy pattern to implement concrete DebuggerCommands for each of the required commands. b. Whenever the debugger stops, the source code should be displayed, with an indication of: i. Breakpoints (indicated by *) ii. Current line of code that is executing (indicated by ->) -> * 2: 3: 4: 5: 6: 7: 8: 9: 10: } 11: } 7. In the debugger package, you must provide an implementation for the DebuggerVirtual Machine that extends the Virtual Machine. This extension will add any methods necessary to manage the debugging session. 1: program {boolean j int i int factorial (int n) { GOTO start < <1>> LABEL start < <1>> LINE 1 FUNCTION main 1 11 LIT 0 j LIT 0 i GOTO continue < <3>> LABEL continue < <3>> LABEL while < <7>> LINE 8 LIT 1 LIT 1 == Testing Requirements A test program is provided for you (factorial.x and factorial.x.cod) in the sample_files directory of the assignment 5 project skeleton. LABEL Read LINE -1 Appendix A: Example of Environment Stack changes Note: this is not expected output! This just shows how the function environment stack changes in the debugger during execution. Also, the stack is growing downwards in this example. Bytecode FUNCTION Read -1 -1 READ RETURN if (n < 2) then { return 1} else FALSEBRANCH continue < <6>> LINE 9 ARGS 0 CALL Read ARGS 1 CALL factorial < <2>> } while (1==1) { {return n* factorial (n-1) } LABEL factorial < <2>> LINE 2 i write (factorial (read ())) Environment Stack (symbol table, start, end, name, currentLine) -, -> < -1 1 > < (), 1, 11, main, 1 > < ( ), 1, 11, main, 1 > < ( , ), 1, 11, main, 1 > < ( , ), 1, 11, main, 8 > < ( , ), 1, 11, main, 9 > < ( , ), 1, 11, main, 9 > < (), -, -, -, -> < ( , ), 1, 11, main, 9 > < (), -, -, -, -1 > < ( , ), 1, 11, main, 9 > < (), -1, -1, Read, -1 > < ( , ), 1, 11, main, 9 > (Return to line 9) < ( , ), 1, 11, main, 9 > < (), -, -, -, -> < ( , ), 1, 11, main, 9 > > list * 2: int factorial (int n) { Type ? for help > iv. source (display source) This command displays the source code of the current function, with an indication of where the execution has stopped (if executing), and any breakpoints that have been set: Type ? for help > source 1: program {boolean j int i int factorial (int n) { if (n < 2) then { return 1} -> * 2: 3: 4: 5: 6: 7: 8: 9: 10: } 11: } Type ? for help. > v. step This command causes execution to continue for one byte code (essentially the behavior of "step into"). There will be no output, apart from a new prompt (the user can choose to display source if they require output): Type ? for help > step Type ? for help. else {return n* factorial (n-1)} } while (1==1) { i = write (factorial (read())) vi. continue This command causes execution to continue. There will be no output, apart from a new prompt (if another break point is encountered). vii. locals This command prints a listing of all symbols in the current frame, with their values: Type ? for help. > locals i: 0 j: 0 Type ? for help viii. exit Immediately halts execution of the program: Type ? for help > exit assignment-5-debugger-spring-2020-jrob8577 git: (master) X 6. You must create classes for interaction with the user. Any UI classes must be created in the interpreter.debugger.ui package. a. A class DebuggerShell must be implemented to encapsulate prompting the user for a command. The prompt should be: Type ? for help > The DebuggerShell class should display the prompt, wait for a user command, validate that the command is allowed, and return an instance of Debugger Command to the Debugger. Follow the strategy pattern to implement concrete DebuggerCommands for each of the required commands. b. Whenever the debugger stops, the source code should be displayed, with an indication of: i. Breakpoints (indicated by *) ii. Current line of code that is executing (indicated by ->) -> * 2: 3: 4: 5: 6: 7: 8: 9: 10: } 11: } 7. In the debugger package, you must provide an implementation for the DebuggerVirtual Machine that extends the Virtual Machine. This extension will add any methods necessary to manage the debugging session. 1: program {boolean j int i int factorial (int n) { GOTO start < <1>> LABEL start < <1>> LINE 1 FUNCTION main 1 11 LIT 0 j LIT 0 i GOTO continue < <3>> LABEL continue < <3>> LABEL while < <7>> LINE 8 LIT 1 LIT 1 == Testing Requirements A test program is provided for you (factorial.x and factorial.x.cod) in the sample_files directory of the assignment 5 project skeleton. LABEL Read LINE -1 Appendix A: Example of Environment Stack changes Note: this is not expected output! This just shows how the function environment stack changes in the debugger during execution. Also, the stack is growing downwards in this example. Bytecode FUNCTION Read -1 -1 READ RETURN if (n < 2) then { return 1} else FALSEBRANCH continue < <6>> LINE 9 ARGS 0 CALL Read ARGS 1 CALL factorial < <2>> } while (1==1) { {return n* factorial (n-1) } LABEL factorial < <2>> LINE 2 i write (factorial (read ())) Environment Stack (symbol table, start, end, name, currentLine) -, -> < -1 1 > < (), 1, 11, main, 1 > < ( ), 1, 11, main, 1 > < ( , ), 1, 11, main, 1 > < ( , ), 1, 11, main, 8 > < ( , ), 1, 11, main, 9 > < ( , ), 1, 11, main, 9 > < (), -, -, -, -> < ( , ), 1, 11, main, 9 > < (), -, -, -, -1 > < ( , ), 1, 11, main, 9 > < (), -1, -1, Read, -1 > < ( , ), 1, 11, main, 9 > (Return to line 9) < ( , ), 1, 11, main, 9 > < (), -, -, -, -> < ( , ), 1, 11, main, 9 > > list * 2: int factorial (int n) { Type ? for help > iv. source (display source) This command displays the source code of the current function, with an indication of where the execution has stopped (if executing), and any breakpoints that have been set: Type ? for help > source 1: program {boolean j int i int factorial (int n) { if (n < 2) then { return 1} -> * 2: 3: 4: 5: 6: 7: 8: 9: 10: } 11: } Type ? for help. > v. step This command causes execution to continue for one byte code (essentially the behavior of "step into"). There will be no output, apart from a new prompt (the user can choose to display source if they require output): Type ? for help > step Type ? for help. else {return n* factorial (n-1)} } while (1==1) { i = write (factorial (read())) vi. continue This command causes execution to continue. There will be no output, apart from a new prompt (if another break point is encountered). vii. locals This command prints a listing of all symbols in the current frame, with their values: Type ? for help. > locals i: 0 j: 0 Type ? for help viii. exit Immediately halts execution of the program: Type ? for help > exit assignment-5-debugger-spring-2020-jrob8577 git: (master) X 6. You must create classes for interaction with the user. Any UI classes must be created in the interpreter.debugger.ui package. a. A class DebuggerShell must be implemented to encapsulate prompting the user for a command. The prompt should be: Type ? for help > The DebuggerShell class should display the prompt, wait for a user command, validate that the command is allowed, and return an instance of Debugger Command to the Debugger. Follow the strategy pattern to implement concrete DebuggerCommands for each of the required commands. b. Whenever the debugger stops, the source code should be displayed, with an indication of: i. Breakpoints (indicated by *) ii. Current line of code that is executing (indicated by ->) -> * 2: 3: 4: 5: 6: 7: 8: 9: 10: } 11: } 7. In the debugger package, you must provide an implementation for the DebuggerVirtual Machine that extends the Virtual Machine. This extension will add any methods necessary to manage the debugging session. 1: program {boolean j int i int factorial (int n) { GOTO start < <1>> LABEL start < <1>> LINE 1 FUNCTION main 1 11 LIT 0 j LIT 0 i GOTO continue < <3>> LABEL continue < <3>> LABEL while < <7>> LINE 8 LIT 1 LIT 1 == Testing Requirements A test program is provided for you (factorial.x and factorial.x.cod) in the sample_files directory of the assignment 5 project skeleton. LABEL Read LINE -1 Appendix A: Example of Environment Stack changes Note: this is not expected output! This just shows how the function environment stack changes in the debugger during execution. Also, the stack is growing downwards in this example. Bytecode FUNCTION Read -1 -1 READ RETURN if (n < 2) then { return 1} else FALSEBRANCH continue < <6>> LINE 9 ARGS 0 CALL Read ARGS 1 CALL factorial < <2>> } while (1==1) { {return n* factorial (n-1) } LABEL factorial < <2>> LINE 2 i write (factorial (read ())) Environment Stack (symbol table, start, end, name, currentLine) -, -> < -1 1 > < (), 1, 11, main, 1 > < ( ), 1, 11, main, 1 > < ( , ), 1, 11, main, 1 > < ( , ), 1, 11, main, 8 > < ( , ), 1, 11, main, 9 > < ( , ), 1, 11, main, 9 > < (), -, -, -, -> < ( , ), 1, 11, main, 9 > < (), -, -, -, -1 > < ( , ), 1, 11, main, 9 > < (), -1, -1, Read, -1 > < ( , ), 1, 11, main, 9 > (Return to line 9) < ( , ), 1, 11, main, 9 > < (), -, -, -, -> < ( , ), 1, 11, main, 9 > > list * 2: int factorial (int n) { Type ? for help > iv. source (display source) This command displays the source code of the current function, with an indication of where the execution has stopped (if executing), and any breakpoints that have been set: Type ? for help > source 1: program {boolean j int i int factorial (int n) { if (n < 2) then { return 1} -> * 2: 3: 4: 5: 6: 7: 8: 9: 10: } 11: } Type ? for help. > v. step This command causes execution to continue for one byte code (essentially the behavior of "step into"). There will be no output, apart from a new prompt (the user can choose to display source if they require output): Type ? for help > step Type ? for help. else {return n* factorial (n-1)} } while (1==1) { i = write (factorial (read())) vi. continue This command causes execution to continue. There will be no output, apart from a new prompt (if another break point is encountered). vii. locals This command prints a listing of all symbols in the current frame, with their values: Type ? for help. > locals i: 0 j: 0 Type ? for help viii. exit Immediately halts execution of the program: Type ? for help > exit assignment-5-debugger-spring-2020-jrob8577 git: (master) X 6. You must create classes for interaction with the user. Any UI classes must be created in the interpreter.debugger.ui package. a. A class DebuggerShell must be implemented to encapsulate prompting the user for a command. The prompt should be: Type ? for help > The DebuggerShell class should display the prompt, wait for a user command, validate that the command is allowed, and return an instance of Debugger Command to the Debugger. Follow the strategy pattern to implement concrete DebuggerCommands for each of the required commands. b. Whenever the debugger stops, the source code should be displayed, with an indication of: i. Breakpoints (indicated by *) ii. Current line of code that is executing (indicated by ->) -> * 2: 3: 4: 5: 6: 7: 8: 9: 10: } 11: } 7. In the debugger package, you must provide an implementation for the DebuggerVirtual Machine that extends the Virtual Machine. This extension will add any methods necessary to manage the debugging session. 1: program {boolean j int i int factorial (int n) { GOTO start < <1>> LABEL start < <1>> LINE 1 FUNCTION main 1 11 LIT 0 j LIT 0 i GOTO continue < <3>> LABEL continue < <3>> LABEL while < <7>> LINE 8 LIT 1 LIT 1 == Testing Requirements A test program is provided for you (factorial.x and factorial.x.cod) in the sample_files directory of the assignment 5 project skeleton. LABEL Read LINE -1 Appendix A: Example of Environment Stack changes Note: this is not expected output! This just shows how the function environment stack changes in the debugger during execution. Also, the stack is growing downwards in this example. Bytecode FUNCTION Read -1 -1 READ RETURN if (n < 2) then { return 1} else FALSEBRANCH continue < <6>> LINE 9 ARGS 0 CALL Read ARGS 1 CALL factorial < <2>> } while (1==1) { {return n* factorial (n-1) } LABEL factorial < <2>> LINE 2 i write (factorial (read ())) Environment Stack (symbol table, start, end, name, currentLine) -, -> < -1 1 > < (), 1, 11, main, 1 > < ( ), 1, 11, main, 1 > < ( , ), 1, 11, main, 1 > < ( , ), 1, 11, main, 8 > < ( , ), 1, 11, main, 9 > < ( , ), 1, 11, main, 9 > < (), -, -, -, -> < ( , ), 1, 11, main, 9 > < (), -, -, -, -1 > < ( , ), 1, 11, main, 9 > < (), -1, -1, Read, -1 > < ( , ), 1, 11, main, 9 > (Return to line 9) < ( , ), 1, 11, main, 9 > < (), -, -, -, -> < ( , ), 1, 11, main, 9 > > list * 2: int factorial (int n) { Type ? for help > iv. source (display source) This command displays the source code of the current function, with an indication of where the execution has stopped (if executing), and any breakpoints that have been set: Type ? for help > source 1: program {boolean j int i int factorial (int n) { if (n < 2) then { return 1} -> * 2: 3: 4: 5: 6: 7: 8: 9: 10: } 11: } Type ? for help. > v. step This command causes execution to continue for one byte code (essentially the behavior of "step into"). There will be no output, apart from a new prompt (the user can choose to display source if they require output): Type ? for help > step Type ? for help. else {return n* factorial (n-1)} } while (1==1) { i = write (factorial (read())) vi. continue This command causes execution to continue. There will be no output, apart from a new prompt (if another break point is encountered). vii. locals This command prints a listing of all symbols in the current frame, with their values: Type ? for help. > locals i: 0 j: 0 Type ? for help viii. exit Immediately halts execution of the program: Type ? for help > exit assignment-5-debugger-spring-2020-jrob8577 git: (master) X 6. You must create classes for interaction with the user. Any UI classes must be created in the interpreter.debugger.ui package. a. A class DebuggerShell must be implemented to encapsulate prompting the user for a command. The prompt should be: Type ? for help > The DebuggerShell class should display the prompt, wait for a user command, validate that the command is allowed, and return an instance of Debugger Command to the Debugger. Follow the strategy pattern to implement concrete DebuggerCommands for each of the required commands. b. Whenever the debugger stops, the source code should be displayed, with an indication of: i. Breakpoints (indicated by *) ii. Current line of code that is executing (indicated by ->) -> * 2: 3: 4: 5: 6: 7: 8: 9: 10: } 11: } 7. In the debugger package, you must provide an implementation for the DebuggerVirtual Machine that extends the Virtual Machine. This extension will add any methods necessary to manage the debugging session. 1: program {boolean j int i int factorial (int n) { GOTO start < <1>> LABEL start < <1>> LINE 1 FUNCTION main 1 11 LIT 0 j LIT 0 i GOTO continue < <3>> LABEL continue < <3>> LABEL while < <7>> LINE 8 LIT 1 LIT 1 == Testing Requirements A test program is provided for you (factorial.x and factorial.x.cod) in the sample_files directory of the assignment 5 project skeleton. LABEL Read LINE -1 Appendix A: Example of Environment Stack changes Note: this is not expected output! This just shows how the function environment stack changes in the debugger during execution. Also, the stack is growing downwards in this example. Bytecode FUNCTION Read -1 -1 READ RETURN if (n < 2) then { return 1} else FALSEBRANCH continue < <6>> LINE 9 ARGS 0 CALL Read ARGS 1 CALL factorial < <2>> } while (1==1) { {return n* factorial (n-1) } LABEL factorial < <2>> LINE 2 i write (factorial (read ())) Environment Stack (symbol table, start, end, name, currentLine) -, -> < -1 1 > < (), 1, 11, main, 1 > < ( ), 1, 11, main, 1 > < ( , ), 1, 11, main, 1 > < ( , ), 1, 11, main, 8 > < ( , ), 1, 11, main, 9 > < ( , ), 1, 11, main, 9 > < (), -, -, -, -> < ( , ), 1, 11, main, 9 > < (), -, -, -, -1 > < ( , ), 1, 11, main, 9 > < (), -1, -1, Read, -1 > < ( , ), 1, 11, main, 9 > (Return to line 9) < ( , ), 1, 11, main, 9 > < (), -, -, -, -> < ( , ), 1, 11, main, 9 > FUNCTION factorial 27 FORMAL n 0 LINE 3 LOAD 0 n LIT 2 BOP < FALSEBRANCH else < <4>> LABEL else < <4>> LINE 6 LOAD 0 n LOAD 0 n LIT 1 ARGS 1 CALL factorial < <2>> LABEL factorial < <2>> LINE 2 FUNCTION factorial 2 7 FORMAL n 0 LINE 3 LOAD 0 n LIT 2 BOP < FALSEBRANCH else < <4>> ... etc. < (), -, 2 > < ( , ), 1, 11, main, 9 > < (), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 3 > < < ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < < < (), -, -, -, - > ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < < < ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < (), -, -, -, 2 > ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < (), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < ( ), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < ( ), 2, 7, factorial, 3 > Appendix B Consider the following x program snippet: 8. int f() { int j int k 9. { int j j = 1 10. } j = 2 11. 12. } The following is the generated byte codes for this function declaration, along with the state of the symbol table, and the symbol table method called: LABEL f < <2>> LINE 8 FUNCTION f 8 12 LIT 0 j LIT 0 k LINE 9 LIT 0 j LIT 1 STORE 2 POP 1 LINE 11 LIT 2 STORE 0 POP 2 RETURN f < <2>> create symbol table, beginScope < (), -, -, -> < (), - - 8 > < (). 8, 12, f, 8 > enter j < ( ), 8, 12, f, 8 > enter k < ( ), 8, 12, f, 8 > < ( ), 8, 12, f, 9 > enter j; symbol table will link to prior entry for j < ( - ), 8, 12, f, 9 > remove last symbol entered, thereby restoring linked entry of j < ( ), 8, 12, f, 9 > < ( ), 8, 12, f, 11 > remove last two symbols < (), 8, 12, f, 11> FUNCTION factorial 27 FORMAL n 0 LINE 3 LOAD 0 n LIT 2 BOP < FALSEBRANCH else < <4>> LABEL else < <4>> LINE 6 LOAD 0 n LOAD 0 n LIT 1 ARGS 1 CALL factorial < <2>> LABEL factorial < <2>> LINE 2 FUNCTION factorial 2 7 FORMAL n 0 LINE 3 LOAD 0 n LIT 2 BOP < FALSEBRANCH else < <4>> ... etc. < (), -, 2 > < ( , ), 1, 11, main, 9 > < (), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 3 > < < ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < < < (), -, -, -, - > ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < < < ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < (), -, -, -, 2 > ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < (), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < ( ), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < ( ), 2, 7, factorial, 3 > Appendix B Consider the following x program snippet: 8. int f() { int j int k 9. { int j j = 1 10. } j = 2 11. 12. } The following is the generated byte codes for this function declaration, along with the state of the symbol table, and the symbol table method called: LABEL f < <2>> LINE 8 FUNCTION f 8 12 LIT 0 j LIT 0 k LINE 9 LIT 0 j LIT 1 STORE 2 POP 1 LINE 11 LIT 2 STORE 0 POP 2 RETURN f < <2>> create symbol table, beginScope < (), -, -, -> < (), - - 8 > < (). 8, 12, f, 8 > enter j < ( ), 8, 12, f, 8 > enter k < ( ), 8, 12, f, 8 > < ( ), 8, 12, f, 9 > enter j; symbol table will link to prior entry for j < ( - ), 8, 12, f, 9 > remove last symbol entered, thereby restoring linked entry of j < ( ), 8, 12, f, 9 > < ( ), 8, 12, f, 11 > remove last two symbols < (), 8, 12, f, 11> FUNCTION factorial 27 FORMAL n 0 LINE 3 LOAD 0 n LIT 2 BOP < FALSEBRANCH else < <4>> LABEL else < <4>> LINE 6 LOAD 0 n LOAD 0 n LIT 1 ARGS 1 CALL factorial < <2>> LABEL factorial < <2>> LINE 2 FUNCTION factorial 2 7 FORMAL n 0 LINE 3 LOAD 0 n LIT 2 BOP < FALSEBRANCH else < <4>> ... etc. < (), -, 2 > < ( , ), 1, 11, main, 9 > < (), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 3 > < < ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < < < (), -, -, -, - > ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < < < ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < (), -, -, -, 2 > ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < (), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < ( ), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < ( ), 2, 7, factorial, 3 > Appendix B Consider the following x program snippet: 8. int f() { int j int k 9. { int j j = 1 10. } j = 2 11. 12. } The following is the generated byte codes for this function declaration, along with the state of the symbol table, and the symbol table method called: LABEL f < <2>> LINE 8 FUNCTION f 8 12 LIT 0 j LIT 0 k LINE 9 LIT 0 j LIT 1 STORE 2 POP 1 LINE 11 LIT 2 STORE 0 POP 2 RETURN f < <2>> create symbol table, beginScope < (), -, -, -> < (), - - 8 > < (). 8, 12, f, 8 > enter j < ( ), 8, 12, f, 8 > enter k < ( ), 8, 12, f, 8 > < ( ), 8, 12, f, 9 > enter j; symbol table will link to prior entry for j < ( - ), 8, 12, f, 9 > remove last symbol entered, thereby restoring linked entry of j < ( ), 8, 12, f, 9 > < ( ), 8, 12, f, 11 > remove last two symbols < (), 8, 12, f, 11> FUNCTION factorial 27 FORMAL n 0 LINE 3 LOAD 0 n LIT 2 BOP < FALSEBRANCH else < <4>> LABEL else < <4>> LINE 6 LOAD 0 n LOAD 0 n LIT 1 ARGS 1 CALL factorial < <2>> LABEL factorial < <2>> LINE 2 FUNCTION factorial 2 7 FORMAL n 0 LINE 3 LOAD 0 n LIT 2 BOP < FALSEBRANCH else < <4>> ... etc. < (), -, 2 > < ( , ), 1, 11, main, 9 > < (), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 3 > < < ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < < < (), -, -, -, - > ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < < < ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < (), -, -, -, 2 > ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < (), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < ( ), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < ( ), 2, 7, factorial, 3 > Appendix B Consider the following x program snippet: 8. int f() { int j int k 9. { int j j = 1 10. } j = 2 11. 12. } The following is the generated byte codes for this function declaration, along with the state of the symbol table, and the symbol table method called: LABEL f < <2>> LINE 8 FUNCTION f 8 12 LIT 0 j LIT 0 k LINE 9 LIT 0 j LIT 1 STORE 2 POP 1 LINE 11 LIT 2 STORE 0 POP 2 RETURN f < <2>> create symbol table, beginScope < (), -, -, -> < (), - - 8 > < (). 8, 12, f, 8 > enter j < ( ), 8, 12, f, 8 > enter k < ( ), 8, 12, f, 8 > < ( ), 8, 12, f, 9 > enter j; symbol table will link to prior entry for j < ( - ), 8, 12, f, 9 > remove last symbol entered, thereby restoring linked entry of j < ( ), 8, 12, f, 9 > < ( ), 8, 12, f, 11 > remove last two symbols < (), 8, 12, f, 11> FUNCTION factorial 27 FORMAL n 0 LINE 3 LOAD 0 n LIT 2 BOP < FALSEBRANCH else < <4>> LABEL else < <4>> LINE 6 LOAD 0 n LOAD 0 n LIT 1 ARGS 1 CALL factorial < <2>> LABEL factorial < <2>> LINE 2 FUNCTION factorial 2 7 FORMAL n 0 LINE 3 LOAD 0 n LIT 2 BOP < FALSEBRANCH else < <4>> ... etc. < (), -, 2 > < ( , ), 1, 11, main, 9 > < (), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 3 > < < ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < < < (), -, -, -, - > ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < < < ( , ), 1, 11, main, 9 > ( ), 2, 7, factorial, 6 > < (), -, -, -, 2 > ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < (), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < ( ), 2, 7, factorial, 2 > < ( , ), 1, 11, main, 9 > < ( ), 2, 7, factorial, 6 > < ( ), 2, 7, factorial, 3 > Appendix B Consider the following x program snippet: 8. int f() { int j int k 9. { int j j = 1 10. } j = 2 11. 12. } The following is the generated byte codes for this function declaration, along with the state of the symbol table, and the symbol table method called: LABEL f < <2>> LINE 8 FUNCTION f 8 12 LIT 0 j LIT 0 k LINE 9 LIT 0 j LIT 1 STORE 2 POP 1 LINE 11 LIT 2 STORE 0 POP 2 RETURN f < <2>> create symbol table, beginScope < (), -, -, -> < (), - - 8 > < (). 8, 12, f, 8 > enter j < ( ), 8, 12, f, 8 > enter k < ( ), 8, 12, f, 8 > < ( ), 8, 12, f, 9 > enter j; symbol table will link to prior entry for j < ( - ), 8, 12, f, 9 > remove last symbol entered, thereby restoring linked entry of j < ( ), 8, 12, f, 9 > < ( ), 8, 12, f, 11 > remove last two symbols < (), 8, 12, f, 11>
Expert Answer:
Related Book For
Posted Date:
Students also viewed these programming questions
-
The Crazy Eddie fraud may appear smaller and gentler than the massive billion-dollar frauds exposed in recent times, such as Bernie Madoffs Ponzi scheme, frauds in the subprime mortgage market, the...
-
Planning is one of the most important management functions in any business. A front office managers first step in planning should involve determine the departments goals. Planning also includes...
-
As we continue our discussions regarding revenue's associated with public sector, this will help reinforce some of the ideas regarding taxes on goods and services. Through the next week, save your...
-
Earth Friendly Structures, Inc., builds environmentally sensitive structures. The company's 2016 revenues totaled $2,760 million. At December 31, 2016, and 2015, the company had. Respectively, $658...
-
You buy an 8% coupon paid annually, 10-year maturity bond when its annual yield to maturity is 9.9%. A year later you sell the bond when the annual yield to maturity is 19%. What is return over the...
-
In addition to the social media sites identified in this chapter, are there other social media sites that would be particularly helpful in a family law case? A personal injury case? Find other social...
-
A major city in the northeast wants to establish a central transportation station from which visitors can ride buses to four historic landmarks. The city is arranged in a grid, or block, structure...
-
The management of Jetson Company believes that the following capital structure is optimal: Components $ value Bond, coupon 8% (now selling at $1075, has 14 years to the maturity and the face value of...
-
Design the 4-to-1 MUX two ways Write a Verilog module called mux4to1 to implement 4-to-1 multiplexer using functional descriptions and if-else blocks. Write another Verilog module called...
-
Awash Winery produces two grades of beer: premium and regular. Premium sells for $10.50 per case and regular for $4.25 per case. Variable brewing costs per case are $5.10 for premium and $4.25 for...
-
Find a parametrisation of the hyperbola that is obtained by translating the hyperbola with equation -4y = 1 by 1 unit(s) left and 1 unit(s) up. A parametrisation is x = y= for a suitable range of the...
-
Internet Exercise: Go to the URL given below. http://www.nolo.com/legal-encyclopedia/types-of-defective-product-liability-30070.html Describe the three theories under which product-liability lawsuits...
-
a) You work for Dynamic Hardware Division (DHD) of Dynamic IT plc. DHD is considering the development of a wireless router that will provide both the hardware and the software necessary to connect...
-
The graph of f(x)=x'(1-x)' is shown below. The derivative of f is given by f'(x)=-5x'(1-x)*+3x (1-x)'. Factor f'(x) completely, and determine all values of x where f'(x) is zero.
-
Winston Corporation has 12,000 shares of 5%, $10 par cumulative preferred stock and 48,000 shares of common stock outstanding. Winston declared no dividends in 2023 and had no dividends in arrears...
-
1. Find the number of centimeters in 100 yards. [3 feet = 1 yard] 2 2. Find the number of meters in 1.00 mile. [1 mile = 5280 feet] 3. The speed of light is 186,000 miles per second. How many meters...
-
Kenneth Hubbard has prepared the following list of statements about managerial accounting and financial accounting. 1. Financial accounting focuses on providing information to internal users. 2....
-
Go to Chipotles webpage ( www.chipotle.com ) and click on Company. Then click on Development. Return to the main page and click on Food with Integrity. Watch one (or more) of the videos posted to...
-
Which organization is likely to face the most complex task environment: a biotechnology company trying to develop a new cure for cancer or a large retailer like the Gap or Macys? Why?
-
Pick an industry and identify four companies in the industry that pursue one of the four main business-level strategies (low-cost, focused low-cost, etc.).
-
Using Program12.m, find the first five natural frequencies of a thin fixed-fixed beam. Data From Example 8.4:- Find the natural frequencies of a bar with one end fixed and a mass attached at the...
-
Find the first two natural frequencies of a fixed-fixed uniform string of mass density \(ho\) per unit length stretched between \(x=0\) and \(x=l\) with an initial tension \(P\). Assume the...
-
A vehicle, of weight \(F_{0}\), moving at a constant speed on a bridge (Fig. 8.43(a)) can be modeled as a concentrated load traveling on a simply supported beam as shown in Fig. 8.43(b). The...
Study smarter with the SolutionInn App