l. Introduction In this programming assignment, you will create a front end that is, a scanner and a parserfor the intermediate representation, ILOC, that will be used as input in the next two assignments: a local register allocator and an instruction scheduler. Your program will take, as input, a program written in ILOC. It will determine whether or not the input is a syntactically corTect ILOC program And generate an output. In a general sense, the front end should check the input code for validity. If the input program contains errors, your front end should find as many errors as possible and report each of them to the user. If the input program does not contain erors, your front end should report that the input file was a valid ILOC program and it should build an intemal representation for the input program that is suitable for use in the subsequent assignments. You will reuse the code that you write for this assignment in both the local register allocator and the instruction scheduler. Therefore, you should take care to make it comect, robust, and efficient. You do not want to spend time in the later assignments fixing work that you should have done in the first assignment. The work product of this assignment will be an archive tar file. The file will contain (1) the source code for your front end.(2) makefile that performs any necessary compilation and linking 3) a README file that describes the contents of the archive file and how to use them. Grading is largely dependent on you confoming to the specification, if these files do not conform to the specifications, the grading tools may not properly evaluate your submission. Your front end will be tested and evaluated on a UNIX or LINUX systems. Anything that you develop for this assignment or submit for this assignment should work on Both a UNIXor LINUX system. You are responsible for testing your code, and directions on how to run your file. The lecturer is not expected to fix incompatibilities in your submission. 2. Overview of the Problem You will build a front end-that is, a scanner and a parser-that will take, as input, a single basic block! written in the LOC subset described in 7. The scanner will break the input stream into a series of individual words. ILOC has a particularly simple syntax, and a small set of word types. The scanner produced, as output, a stream of classified words represented as tokens: a pair where category is the kind of word and lexeme is the specific word ( E.g. T- x+y; becomes id.y;word - lexeme, part of speech token type, pair e a token) The scanner should be incremental; that is, the parser will call it on demand and it will produce the next word in the input stream. In subsequent labs, you will test your code's performance (that is, the running time of your code) at scale. It is critical that your scanner and parser efficiently handle input programs with at least more than 100,000 lines of input. A batch scanner-that is, one that scans the entire program before returning its first token-is likely to break or run slowly on reasonably large files. The parser will examine the stream of tokens produced by the scanner, break them into operations, and check the syntax of each operation. The simple structure of ILOC allows the parser to perform detailed syntax checking based largely on the opcode for the operation (ILOC is described in Appendix A of the Course Book and also Chapter 13 which looks at Local Register Allocation). As the parser checks each operation, it will build a representation for that operation, for later use in subsequent compiler passes-specifically, in your local register allocator and your instruction scheduler. Section 8 describes the representation that we recommend, based on our experience You must decide the details of the representation used in your front end. Remember that your register allocator and instruction scheduler will re-use the code and data structures from this assignment, unless you choose to re-implement them. 3. Code Specifications You must adhere to the following interface specifications to ensure that your front end works correctly with the grading script going to be used. * Name: The executable version of your front end must be named 316fe * Behavior: Your front end must work in four distinct modes, as controlled by flags and parameters on the command line. Your front-end must check the comectness of the command line arguments and it should respond to incomect command line option by printing a reasonable error message and the printing the valid options specified for the -h command line flag. Outpurt from 316fe must be printed to the standard output stream to the user, as all error messages must be printed into an error log file and displayed to the user concurrently * Command Line Syntax: Your implementation of 316fe must support the following When a -h flag is detected, 316fe must produce a list of valid command-line all command-line arguments required for Lab 1 as well as any additional command-line arguments supported by your 316fe implementation. 316fe is not required to process command-line arguments that appear after the -h flag. 316fe -h arguments that includes a description of When a -s flag is detected, 316fe should read the file specified by and print, to the standard output stream, a ist of the tokens that the scanner found. For each token, it should print the line number, the token's type (or syntactic category), and its spelling (or lexeme). 316fe -s , scan it and parse it, build the intermediate and report either success or report all of the errors that * Command Line Syntax: Your implementation of 316fe must support the following When a -h flag is detected, 316fe must produce a list of valid command-line arguments that includes a description of all command-line arguments required for Lab 1 as well as any additional command-line arguments supported by your 316fe implementation. 316fe is not required to process command-line arguments that appear after the -h flag. 316fe -h When a -s flag is detected, 316fe should read the file specified by and print, to the standard output stream, a ist of the tokens that the scanner found. For each token, it should print the line number, the token's type (or syntactic category), and its spelling (or lexeme). 316fe -s , scan it and parse it, build the intermediate representation, and report either success or report all of the errors that it finds in the input file 316fe -r , scan it, parse it, build the intermediate representation, and print out the information in the e representation (in an appropriately human readable format These four command-line flags are intended to be exclusive; that is, your front end only needs to handle one of these flags in any given invocation. It the user invokes your front end with multiple command-line flags, it should politely report the error and implement the highest priority flag, Priority is, from highest to lowest, -h, -r, -p, and-s If no command-line flag is specified, the front end will behave as if it had received the flag -p. (That is, -p is the default behavior.) 1) Input file: The input file specified in the command line will contain a single basic block of ILOC code, written in the subset described in Section 7 of this document. Your front-end should scan and parse each line, checking them against the ILOC syntax specification. If your program cannot read the input file, or if it discovers that the code in the file is not a valid ILOC, it should produce an informative error message that includes the line number in the input file where the error occurs and brief description of the problem. The message should be sufficiently descriptive to allow a reasonable programmer to identify and fix the error. Your front-end should find as many errors as possible in the input file; that is, it should continue scanning and parsing after it finds an error. Once it finds an error in a given line, it may skip to the end of that line to avoid multiple error messages for a single line Scanning the input: ICT 316 is a course about the implementation of programming languages. Thus, you must write your own code to scan the input. You may not use formatted I/O, regular expression libraries, or other patterm-matching software, unless you write them yourself. Your scanner should process the input one character at a time. It may read one or more lines into a buffer and then process the buffer one character at a time. (See the discussion of double buffering in Chapter 2.5.3 of the textbook.) Character-by-character algorithms lend some clarity to the scanner. They can be significantly more efficient2 than calls to generalized pattern-matching libraries or formatted I/O routines. 2) Makefile & Shell Script: This lab submission is written in languages that require a compilation step, such as C, C+, or Java, which must include a makefile. If your submission is written in a language that does not require compilation, such as Python, your submission does not need to include a makefile. The makefile must produce an executable named 31fe. If your submission is written in a language in which it is not possible to create a standalone executable and rename it to 316fe, such as Python or Java, then you must submit an executable shell script named 316fe that correctly accepts the required command-line arguments and invokes the program. For example, a front end written in Python and named labl.py could inchude an executable shell script named 316fe that contained the following instructions: python lablpy $@ Similarly, a project written Java with a jar file named lab1jar or a class named lab1.class that contains the main function could provide, respectively, one of the following two executable shell scripts named 316alloc: #!bin bash #!binbash java-jar labl.jar S@ java labl S@ To ensure that such a script is executable on a Linux system, for either Python or Java, you must set its file permissions appropriately. In the directory where your script resides, execute the command shell script named 316fe that correctly accepts the required command-line arguments and invokes the program. For example, a front end written in Python and named labl.py could include an executable shell script named 316fe that contained the following instructions: #!bin/bash python labl py $@ Similarly, a project written Java with a jar file named labl.jar or a class named labl.class that contains the main function could provide, respectively, one of the following two executable shell scripts named 316alloc #!bin/bash #Mbinbash ava-jar lab1 jar Sa java labl S@ To ensure that such a script is executable on a Linux system, for either Python or Java, you must set its file permissions appropriately. In the directory where your script resides, execute the command chmod a+x 316fe To avoid problems related to the translation of carriage returm and line feed between Windows systems and Linux, we recommend that you write your shell script and makefile on Linux rather than on a Windows system. 3) Programming Language: You may use any programming language available with the excepting ofPerl. Your goal should be to use a language that you are comfortable programming. for which you have decent debugging tools, and with which you can reuse in subsequent lab assignments This freedom in not a call for language virtuosity; it is a bad idea to decide to learn a new language for this course. If you do and it does not work out well, you will be forced to reimplement your front-end during limited time allowed to build the local register allocator. If you decide to develop code on your laptop having Windows OS, as most students would do, be sure to check if it would be compatible on Linux. Minor differences between implementations can cause last minute panics when a program that runs fine on your laptop produces incorrect results on Limux. The best practice is to regularly test your code in the environment where it will be graded, on Linux. 4) README File: Your tar file must contain a README file that contains directions for building and invoking your program. (Note that Linux has a case-sensitive file system, so README must be in all capital letters.) Include a description of all command-line options that your code supports, including any that you added beyond the four required flags. To work with the grading scripts, the first two lines of your README file must be in the following format: INAME: cyour name INDEX NUMBER: your ID Notice that that there are no spaces after the slashes, and that the keywords NAME and ID are in all capital letters. Your name should be capitalized normally. Your id should be all lowercase letters and numbers. l. Introduction In this programming assignment, you will create a front end that is, a scanner and a parserfor the intermediate representation, ILOC, that will be used as input in the next two assignments: a local register allocator and an instruction scheduler. Your program will take, as input, a program written in ILOC. It will determine whether or not the input is a syntactically corTect ILOC program And generate an output. In a general sense, the front end should check the input code for validity. If the input program contains errors, your front end should find as many errors as possible and report each of them to the user. If the input program does not contain erors, your front end should report that the input file was a valid ILOC program and it should build an intemal representation for the input program that is suitable for use in the subsequent assignments. You will reuse the code that you write for this assignment in both the local register allocator and the instruction scheduler. Therefore, you should take care to make it comect, robust, and efficient. You do not want to spend time in the later assignments fixing work that you should have done in the first assignment. The work product of this assignment will be an archive tar file. The file will contain (1) the source code for your front end.(2) makefile that performs any necessary compilation and linking 3) a README file that describes the contents of the archive file and how to use them. Grading is largely dependent on you confoming to the specification, if these files do not conform to the specifications, the grading tools may not properly evaluate your submission. Your front end will be tested and evaluated on a UNIX or LINUX systems. Anything that you develop for this assignment or submit for this assignment should work on Both a UNIXor LINUX system. You are responsible for testing your code, and directions on how to run your file. The lecturer is not expected to fix incompatibilities in your submission. 2. Overview of the Problem You will build a front end-that is, a scanner and a parser-that will take, as input, a single basic block! written in the LOC subset described in 7. The scanner will break the input stream into a series of individual words. ILOC has a particularly simple syntax, and a small set of word types. The scanner produced, as output, a stream of classified words represented as tokens: a pair where category is the kind of word and lexeme is the specific word ( E.g. T- x+y; becomes id.y;word - lexeme, part of speech token type, pair e a token) The scanner should be incremental; that is, the parser will call it on demand and it will produce the next word in the input stream. In subsequent labs, you will test your code's performance (that is, the running time of your code) at scale. It is critical that your scanner and parser efficiently handle input programs with at least more than 100,000 lines of input. A batch scanner-that is, one that scans the entire program before returning its first token-is likely to break or run slowly on reasonably large files. The parser will examine the stream of tokens produced by the scanner, break them into operations, and check the syntax of each operation. The simple structure of ILOC allows the parser to perform detailed syntax checking based largely on the opcode for the operation (ILOC is described in Appendix A of the Course Book and also Chapter 13 which looks at Local Register Allocation). As the parser checks each operation, it will build a representation for that operation, for later use in subsequent compiler passes-specifically, in your local register allocator and your instruction scheduler. Section 8 describes the representation that we recommend, based on our experience You must decide the details of the representation used in your front end. Remember that your register allocator and instruction scheduler will re-use the code and data structures from this assignment, unless you choose to re-implement them. 3. Code Specifications You must adhere to the following interface specifications to ensure that your front end works correctly with the grading script going to be used. * Name: The executable version of your front end must be named 316fe * Behavior: Your front end must work in four distinct modes, as controlled by flags and parameters on the command line. Your front-end must check the comectness of the command line arguments and it should respond to incomect command line option by printing a reasonable error message and the printing the valid options specified for the -h command line flag. Outpurt from 316fe must be printed to the standard output stream to the user, as all error messages must be printed into an error log file and displayed to the user concurrently * Command Line Syntax: Your implementation of 316fe must support the following When a -h flag is detected, 316fe must produce a list of valid command-line all command-line arguments required for Lab 1 as well as any additional command-line arguments supported by your 316fe implementation. 316fe is not required to process command-line arguments that appear after the -h flag. 316fe -h arguments that includes a description of When a -s flag is detected, 316fe should read the file specified by and print, to the standard output stream, a ist of the tokens that the scanner found. For each token, it should print the line number, the token's type (or syntactic category), and its spelling (or lexeme). 316fe -s , scan it and parse it, build the intermediate and report either success or report all of the errors that * Command Line Syntax: Your implementation of 316fe must support the following When a -h flag is detected, 316fe must produce a list of valid command-line arguments that includes a description of all command-line arguments required for Lab 1 as well as any additional command-line arguments supported by your 316fe implementation. 316fe is not required to process command-line arguments that appear after the -h flag. 316fe -h When a -s flag is detected, 316fe should read the file specified by and print, to the standard output stream, a ist of the tokens that the scanner found. For each token, it should print the line number, the token's type (or syntactic category), and its spelling (or lexeme). 316fe -s , scan it and parse it, build the intermediate representation, and report either success or report all of the errors that it finds in the input file 316fe -r , scan it, parse it, build the intermediate representation, and print out the information in the e representation (in an appropriately human readable format These four command-line flags are intended to be exclusive; that is, your front end only needs to handle one of these flags in any given invocation. It the user invokes your front end with multiple command-line flags, it should politely report the error and implement the highest priority flag, Priority is, from highest to lowest, -h, -r, -p, and-s If no command-line flag is specified, the front end will behave as if it had received the flag -p. (That is, -p is the default behavior.) 1) Input file: The input file specified in the command line will contain a single basic block of ILOC code, written in the subset described in Section 7 of this document. Your front-end should scan and parse each line, checking them against the ILOC syntax specification. If your program cannot read the input file, or if it discovers that the code in the file is not a valid ILOC, it should produce an informative error message that includes the line number in the input file where the error occurs and brief description of the problem. The message should be sufficiently descriptive to allow a reasonable programmer to identify and fix the error. Your front-end should find as many errors as possible in the input file; that is, it should continue scanning and parsing after it finds an error. Once it finds an error in a given line, it may skip to the end of that line to avoid multiple error messages for a single line Scanning the input: ICT 316 is a course about the implementation of programming languages. Thus, you must write your own code to scan the input. You may not use formatted I/O, regular expression libraries, or other patterm-matching software, unless you write them yourself. Your scanner should process the input one character at a time. It may read one or more lines into a buffer and then process the buffer one character at a time. (See the discussion of double buffering in Chapter 2.5.3 of the textbook.) Character-by-character algorithms lend some clarity to the scanner. They can be significantly more efficient2 than calls to generalized pattern-matching libraries or formatted I/O routines. 2) Makefile & Shell Script: This lab submission is written in languages that require a compilation step, such as C, C+, or Java, which must include a makefile. If your submission is written in a language that does not require compilation, such as Python, your submission does not need to include a makefile. The makefile must produce an executable named 31fe. If your submission is written in a language in which it is not possible to create a standalone executable and rename it to 316fe, such as Python or Java, then you must submit an executable shell script named 316fe that correctly accepts the required command-line arguments and invokes the program. For example, a front end written in Python and named labl.py could inchude an executable shell script named 316fe that contained the following instructions: python lablpy $@ Similarly, a project written Java with a jar file named lab1jar or a class named lab1.class that contains the main function could provide, respectively, one of the following two executable shell scripts named 316alloc: #!bin bash #!binbash java-jar labl.jar S@ java labl S@ To ensure that such a script is executable on a Linux system, for either Python or Java, you must set its file permissions appropriately. In the directory where your script resides, execute the command shell script named 316fe that correctly accepts the required command-line arguments and invokes the program. For example, a front end written in Python and named labl.py could include an executable shell script named 316fe that contained the following instructions: #!bin/bash python labl py $@ Similarly, a project written Java with a jar file named labl.jar or a class named labl.class that contains the main function could provide, respectively, one of the following two executable shell scripts named 316alloc #!bin/bash #Mbinbash ava-jar lab1 jar Sa java labl S@ To ensure that such a script is executable on a Linux system, for either Python or Java, you must set its file permissions appropriately. In the directory where your script resides, execute the command chmod a+x 316fe To avoid problems related to the translation of carriage returm and line feed between Windows systems and Linux, we recommend that you write your shell script and makefile on Linux rather than on a Windows system. 3) Programming Language: You may use any programming language available with the excepting ofPerl. Your goal should be to use a language that you are comfortable programming. for which you have decent debugging tools, and with which you can reuse in subsequent lab assignments This freedom in not a call for language virtuosity; it is a bad idea to decide to learn a new language for this course. If you do and it does not work out well, you will be forced to reimplement your front-end during limited time allowed to build the local register allocator. If you decide to develop code on your laptop having Windows OS, as most students would do, be sure to check if it would be compatible on Linux. Minor differences between implementations can cause last minute panics when a program that runs fine on your laptop produces incorrect results on Limux. The best practice is to regularly test your code in the environment where it will be graded, on Linux. 4) README File: Your tar file must contain a README file that contains directions for building and invoking your program. (Note that Linux has a case-sensitive file system, so README must be in all capital letters.) Include a description of all command-line options that your code supports, including any that you added beyond the four required flags. To work with the grading scripts, the first two lines of your README file must be in the following format: INAME: cyour name INDEX NUMBER: your ID Notice that that there are no spaces after the slashes, and that the keywords NAME and ID are in all capital letters. Your name should be capitalized normally. Your id should be all lowercase letters and numbers