代做COMP 412、代写python设计编程

项目预算：开发周期：发布时间：要求地区：

COMP 412, Fall 2024
Lab 2: Local Register Allocation
Table of Contents Critical Dates for the Project
1. Introduction 1 Code Due Date 10/23/2024
2. Overview of the Problem 2 Code Check #1 Due 10/04/2024
3. Code Specifications 3 Code Check #2 Due 10/16/2024
5. Submitting Your Code 5
6. Grading Rubric & Honor Policy 6
Please report suspected typographical
errors to the instructors via a message on
the class Piazza site.
7. Honor Policy 7
A. ILOC Simulator & Subset 8
B. Tools 10
C. Timing Results from Prior Years 11
D. Checklist for Lab 2 13
1. Introduction
In this programming assignment you will build a local register allocator—that is, a program that
reads in a single block of ILOC code, transforms that block so that it uses a specified number of
registers, and writes the transformed block out to the standard output stream. The input and
output blocks are both written in the ILOC subset used in Lab 1. Section A.1 of this document
describes the ILOC subset and its simulator.
For the purposes of this lab, an input program and an output program are considered
equivalent if and only if they print the same values in the same order to stdout and
each data-memory location defined by an execution of the input program receives the
same value when the output program executes.
The output program may define additional memory locations that are not defined by
the input program. In particular, it will define and use new locations to hold values that
it decides to spill from registers to memory.
The input blocks receive data in one of two ways. Either the values are is hard-coded into the
block, or they are specified on the simulator’s command line using the -i command-line option.
The concepts and algorithms behind register allocation are explained in two distinct places.
First, there are a series of short videos available on the course Canvas Site. You should watch
each of these videos. Second, Chapter 13 in the textbook explains register allocation in depth.
Sections 13.1 and 13.2 provide background and Section 13.3 presents, in detail, the algorithms
that pertain to Lab 2. You should read this material. An excerpt from Section 13.3 is posted on
Canvas. (The later sections of Chapter 13 describe global allocation, the more complex problem
that arises when the allocator looks at code that includes control-flow operations.)
Lab 2: Local Register Allocation Version 2024-1
COMP 412 2 Fall 2024
This document describes the specifications for your program, the policies for the lab, the
various logistics associated with the lab, the process for submitting the lab, and the grading
rubric. The document is long, but you should read it to ensure that you understand what is
expected of your lab and what tools are available to help.
2. Overview of the Problem
A register allocator is a compiler pass that transforms a version of the program that uses an
arbitrary number of registers into a version that uses a specified number of registers. That is,
the input program might be written to use seventy-three registers and the output program can
only use the number of registers available for application use on the target machine.
The number of registers available for the output program is a parameter, called k, that is passed
into the allocator on the command line. When invoked with a command line, such as
./412alloc 17 ~comp412/students/ILOC/SLOCs/T001k.1
The allocator should read the file, ~comp412/students/ILOC/SLOCs/T001k.i, determine if it is a
valid ILOC block, and produce an equivalent block that uses at most 17 registers.
To transform the program, the register allocator reads through the operations in the block and
makes, at each operation, a decision as to which values should remain in registers and which
values should be relegated to storage in memory. It inserts stores (spills) and loads (restores) as
necessary to ensure that the values are in the right places. It rewrites the code to use the
names of the actual hardware registers (r0 through r16 for the example command line).
Your allocator may not apply optimizations other than register allocation. All the loads, stores,
and arithmetic operations that appear in the input program must appear in the output
program, in the same relative order.
1
The output block must perform the original computation;
it cannot pre-compute the results. Allocators that perform optimizations other than register
allocation will lose substantial credit. Of course, the output block may use different register
names than the input block.
Your allocator may remove nops; they have no effect on the equivalence of the input and
output of programs. If your allocator performs rematerialization (see the Lab 2 Performance
Lecture), then it may move loadI operations around in ways that cannot happen with a load or
a store. Finally, your allocator must not perform optimizations based on the input constants
specified in ILOC test block comments; the autograder may use different input values to test
your code.
To evaluate your submission, we will use an autograder — a fairly-straightforward python
program that will unpack your submission, perform any actions needed to build the executable,
and test your executable against a series of test blocks. We will provide a distribution of the
autograder so that you can verify that your submission works with the autograder. The
production autograder will use additional files, not available in the distributed autograder, to
assess your submission.
1
We say “relative order” because the allocator may insert spills and/or restores between any two
operations in the original program. Lab 2: Local Register Allocation Version 2024-1
COMP 412 3 Fall 2024
3. Code Specifications
Your allocator must adhere to the following specifications.
• Name: The executable version of your allocator must be named 412alloc.
• Behavior: Your allocator must work in following three modes:
412alloc -h When passed the -h flag, 412alloc must print a list of the valid commandline
arguments that it accepts, along with a concise explanation for that option. That list
should include the arguments described in this table, as well as any others that your
allocator supports. After printing the message, 412alloc should sto.
412alloc -x The -x flag will only be used for Code Check 1. Again,
is a Linux pathname. With this flag, 412alloc should scan and parse the input block. It
should then perform renaming on the code in the input block and print the results to
the standard output stream (stdout). lab2_ref does not implement the -x flag.
412alloc k In this format, k is the number of registers available to the
allocator (3 ≤ k ≤ 64) and is a Linux pathname to the file containing the input
block. The pathname can be either a relative pathname or an absolute pathname.
If k is outside the valid range or it cannot open the file specified by , 412alloc
should print a reasonable error message and exit cleanly (e.g., no backtrace).
If the parameters are valid, 412alloc should scan parse, and allocate the code in the
input block so that it uses only registers r0 to rk-1 and print the resulting code to the
standard output stream (stdout).
In each mode, 412alloc should check the input parameters and report any problems on the
standard error stream (stderr). All error messages should be printed to the standard error
stream (stderr). Normal output should be printed to the standard output stream (stdout).
• Input File: The input file will consist of a sequence of ILOC operations (a block) in the subset
described in § A. If 412alloc cannot read the input file, or the code in the file is not valid
ILOC, it should write an error message to the standard error file (stderr). 412alloc should
detect as many errors in the file as it can before quitting.
If the ILOC code in the input block uses a value from a register that has no prior definition,
your allocator should handle the situation gracefully.
Scanning and Parsing: Your register allocator should use your front end from Lab 1 to read
and parse the input file. The front end should be prepared to handle large input files, such
as the file T128k.i from Lab 1 (also found in ~comp412/students/ILOC/Scalability/SLOCs/).
Makefile & Shell Script: As in Lab 1, you will submit a tar archive file that contains the
source code for your allocator, along with any scripts or Makefiles required to create and
execute the final code.2
For a Java lab, you must submit the code, not a jar file.
2
If you prefer to use another build manager (available on CLEAR), invoke that build manager in your Makefile. Your
build manager should not leave behind a repository— particularly hidden files in comp412’s home directory. Lab 2: Local Register Allocation Version 2024-1
COMP 412 4 Fall 2024
Lab 2 submissions written in languages that require a compilation step, such as C, C++, or
Java, must include a Makefile. The autograder will invoke make with the two commands:
make clean
make build
in that order. The clean target should remove any files from old attempts to build the
executable. The build target should ensure that the 412alloc executable is ready to run. If
your submission is written in a language that does not require compilation, such as python,
then it does not need a Makefile.
If your submission does not create a standalone executable named 412alloc, then it should
include a shell script named 412alloc that accepts the required command-line arguments
and passes them to the program. For example, a project written in python3
named lab2.py
could provide an shell script named 412alloc that includes the following instructions:
#!/bin/bash
python3 lab2.py $@
To invoke python2, you would use the command “python2” rather than “python3”.
Similarly, a project written in Java with a jar file named lab2.jar or a class named lab2.class
that contains the main function could provide, respectively, one of the following two
executable shell scripts, naming it 412alloc.
#!/bin/bash #!/bin/bash
java -jar lab2.jar $@ java lab2 $@
To ensure that your 412alloc shell script is executable on a Linux system, execute the
following command in the CLEAR directory where your 412alloc shell script resides:
chmod a+x 412alloc
To avoid problems related to the translation of carriage return and line feed between
Windows and Linux, we strongly recommend that you write your shell script and Makefile
on CLEAR rather than on a Windows system (see also man dos2unix).
• README: Your submission must include a file named README (uppercase letters, no suffix)
that provides directions for building and invoking your allocator. Include a description of all
command-line arguments required for Lab 2 as well as any additional command-line
arguments that your allocator supports. The autograder expects that the first two lines of
your README file are in the following format:
//NAME:
//NETID:
Note that there are no spaces after the slashes, and that the keywords NAME and NETID
are in all capital letters. Your name should be capitalized normally. Your netid should be
lowercase characters and numbers.

3 Alternatively, you can write a python program that runs directly. As an example, see the lab 1 testing script on
CLEAR. Its first line is a comment that tells the shell to invoke python; the main routine parses argv and argc. Lab 2: Local Register Allocation Version 2024-1
COMP 412 5 Fall 2024
• Programming Language: You may use any programming language provided on Rice’s CLEAR
facility, except for Perl. Your goal should be to use a language that is available on CLEAR, in
which you are comfortable programming, for which you have decent debugging tools, and
that allows you to easily reuse code in Lab 3. When coding, be sure to target the version of
your chosen programming language that is available on CLEAR.
• USE CLEAR: Your submission must work on CLEAR. If the code must be translated (e.g.,
compiled, linked, turned into a jar or an a.out), that must happen on CLEAR. Test the code
on CLEAR; test it in the distributed autograder. Students have, in previous years, found
differences between language and library versions on their laptops and on CLEAR.
4. Code Checks
Lab 2 has two intermediate code checks. To pass a code check, you should run the appropriate
script (see below) and submit a screen shot to the code check assignment on Canvas. The code
checks are intended to keep your progress on track, time wise. You get full credit at the due
date, half credit two days late, and no credit beyond two days late. Grace days do not apply.
(The grading rubric is discussed in § 5.)
Code Check #1: The due date for code check #1 is shown on page 1. To pass code check #1,
412alloc must correctly scan, parse, perform register renaming, and print the resulting
renamed ILOC block to stdout. The code check #1 script and test blocks are located on
CLEAR in the directory ~comp412/students/lab2/code_check_1/.
Code Check #2: The due date for code check #2 is shown on page 1. To pass code check #2,
412alloc must correctly perform register allocation on a limited set of test blocks. (That is,
the allocated code must produce the correct answers when run with only k registers on the
ILOC simulator.) The code check #2 script and the test blocks are found in
~comp412/students/lab2/code_check_2/.
The code check directories on CLEAR contain a README file that describes how to invoke the
code check script and interpret the results. As before, you may need an executable shell script
that to conform to the interface. A working Makefile is not critical for the code checks, but we
recommend that you create your Makefile or script before the first code check and use it while
developing your code.
5. Submitting Your Final Code
Due date: The due date for your code submission is shown on page 1. All work is due at
11:59PM on the specified day. Individual extensions to this deadline will not be granted.
Early-Submission Bonus: Submissions received before the due date will receive a bonus of one
semester point (1% of the final course grade).
Late Penalty: Submissions received after the due date will receive a penalty of one semester
point (1% of the final course grade). No code will be accepted after the date when the next
project is made available. Lab 2: Local Register Allocation Version 2024-1
COMP 412 6 Fall 2024
Grace Days: To cover situations that inevitably arise, we will waive up to four days of late
penalties per semester when computing your final COMP 412 grade. Note that we choose
where those days apply, after all grades are complete. We will apply these “grace” days in a
way that maximizes benefit to you.
Submission Details: To submit your work, you must create a tar archive that contains your
submission, including (1) the source code for the register allocator, (2) the Makefile and/or
shell script, (3) the README file, and (4) any other files that are needed for the autograder to
build and test your code. The tar file should unpack into the current working directory. The
README, Makefile, and executable script, if any, must reside in that top-level directory.
The document “NoteOnTarFiles.pdf”, available on the COMP 412 Canvas Site, provides more
details about the structure of the submission file system and the tar archive. You can test
your archive using the autograder. If your archive does not work with the autograder, that
will reduce the points you receive in the conformance portion of the grading rubric.
If your allocator does not work, include in your tar file a file named STATUS that contains a
brief description of its current state. You may include ILOC files that your lab handles
correctly and ILOC files that it handles incorrectly. List those file names in the STATUS file.
Name the tar file with your Rice netid (e.g., if your netid is jed12, you would name the
archive jed12.tar). To submit your tar file, move it to CLEAR and execute the command
~comp412/bin/submit_2
The submit_2 script will create a copy of your tar archive, timestamp it, and send an email
confirmation to you and to the comp412 email account (for record-keeping). You should
keep the tar archive until the end of the semester to record what you submitted.
6. Grading Rubric
The Lab 2 grade accounts for 20% of your final COMP 412 grade. The code rubric is based on
100 points, allocated as follows. Correctness and cycle count will be determined using the Lab 2
ILOC simulator.
• 10 points for passing code check #1 by its due date (see table on page 1). 5 points will be
awarded for passing code check #1 within three days of the due date. No points for code
check #1 will be awarded after that time. Grace days do not apply to this deadline.
• 10 points for passing code check #2 by its due date (see table on page 1). 5 points will be
awarded for passing code check #2 within three days of the due date. No points for code
check #2 will be awarded after that time. Grace days do not apply do this deadline.
• 10 points for conformance to the Lab 2 code specifications and submission requirements.
• 30 points for correctness of the allocated code produced by the final submission. Here,
correctness means that running the allocated code produces the correct answer.
• 20 points for effectiveness, measured as the number of cycles required to run the
allocated code produced by your final submission on the Lab 2 ILOC simulator. An
allocator that gets within 10% of the cycle counts for lab2_ref will receive full credit for Lab 2: Local Register Allocation Version 2024-1
COMP 412 7 Fall 2024
effectiveness. You can use the spreadsheet Lab2SpreadSheet.xlsx, in the lab 2
documents folder, to estimate effectiveness on the report blocks. The report blocks are a
subset of the blocks used to grade your allocator.
• 20 points for performance, split equally between scalability and efficiency. The autotimer
measures performance using blocks from ~comp412/students/ILOC/Scalability/SLOCs.
The autotimer is included with the distributed autograder.
Scalability: The register allocator should display linear scaling — that is, a doubling of the
input size should produce growth of no more than 2x in the runtime. You can see this by
plotting runtime as a function of non-comment lines in the input file; do not use a
logarithmic scale on either axis.
Efficiency: The table below shows the measured runtime on block T128k.i required for full
credit and the time that will produce zero credit. Runtimes between full credit and zero
credit will receive partial credit, on a linear scale between the breakpoints. The specific
breakpoints were determined by analyzing the lab 2 submissions from the Fall 2020 class.
Language Full Credit No Credit
C £ 1.0 second ³ 2.0 seconds
C++ £ 2.0 second ³ 4.0 seconds
Java £ 4.75 seconds ³ 12.0 seconds
Python £ 8.0 seconds ³ 20.0 seconds
Go £ 1.0 second ³ 2.0 seconds
For languages not shown in the table, the instructor will determine a set of breakpoints
based on the language, its implementation, and, perhaps, some additional testing.
7. Honor Policy
Your submitted source code and README file must consist of code and/or text that you wrote,
not edited or copied versions of code and/or text written by others or in collaboration with
others. You may not look at COMP 412 code from past semesters. Your submitted code may
not invoke the COMP 412 reference allocator, or any other allocator that you did not write.
You are free to collaborate with current COMP 412 students when preparing your Makefile
and/or shell script and to submit the results of your collaborative Makefile and/or shell script
efforts. However, as indicated in the previous paragraph, all other Lab 2 code and text
submitted must be your own work, not the result of a collaborative effort. You may not use
tools based on generative AI to assist you in creating the code for your allocator.
You are welcome to discuss Lab 2 with the COMP 412 staff and with students currently taking
COMP 412. You are also encouraged to use the archive of test blocks produced by students in
previous semesters. However, we ask that you not make your COMP 412 labs available to Lab 2: Local Register Allocation Version 2024-1
COMP 412 8 Fall 2024
students (other than COMP 412 TAs) in any form during or after this semester. We ask that you
not place your code anywhere on the Internet that is viewable by others.
Appendix A. ILOC Simulator & Subset
ILOC Simulator: An ILOC simulator, its source, and documentation are available in the subtree
under ~comp412/students/lab2 on CLEAR. The source code and documentation are available.
If you need to build a private copy of the simulator, § 7.1 of the simulator documentation
explains the various configuration options.
The simulator builds and executes on CLEAR. You can either run the simulator from comp412’s
directory or copy it into your local directory. You can build a copy to run on your laptop. It
appears to work on other OS implementations but that is not guaranteed. Your allocator will be
tested and graded on CLEAR, so you should be sure to test it on CLEAR.
ILOC Subset: Lab 2 input and output files consist of a single basic block4 of code written in a
subset of ILOC, detailed in the following table. ILOC is case-sensitive.
Syntax Meaning Latency
load r1 => r2 r2 ß MEM(r1) 3
loadI x => r2 r2 ß x 1
store r1 => r2 MEM(r2) ß r1 3
add r1, r2 => r3 r3 ß r1 + r2 1
sub r1, r2 => r3 r3 ß r1 - r2 1
mult r1, r2 => r3 r3 ß r1 * r2 1
lshift r1, r2 => r3 r3 ß r1 << r2 1
rshift r1, r2 => r3 r3 ß r1 >> r2 1
output x prints MEM(x) to stdout 1
nop idle for one cycle 1
All register names have an initial lowercase r followed immediately by a non-negative integer.
Leading zeros in the register name are not significant; thus, r017 and r17 refer to the same
register. Arguments that do not begin with r, which appear as x in the table above, are assumed
to be non-negative integer constants in the range 0 to 231 – 1. The assignment arrow is
composed of an equal sign followed by a greater than symbol, as shown (=>).
Each ILOC operation in an input block must begin on a new line and be completely contained on
that line.
5
Whitespace is defined to be any combination of blanks and tabs. ILOC opcodes must
4
A basic block is a maximal length sequence of straight-line (i.e., branch-free) code. We use the terms block and
basic block interchangeably when the meaning is clear. 5
Both Carriage returns (CR, \r, 0x0D) and line feeds (LF, \n, 0x0A) may appear as in end-of-line sequences. Lab 2: Local Register Allocation Version 2024-1
COMP 412 9 Fall 2024
be followed by whitespace. Whitespace preceding and following all other symbols is optional.
Whitespace is not allowed within operation names, register names, or the assignment arrow. A
double slash (//) indicates that the rest of the line is a comment and can be discarded. Empty
lines and nops in input files may also be discarded.
Memory Use in the ILOC Simulator: The ILOC simulator has separate address spaces for code
and data. The code memory is not accessible to a running ILOC program; this unreasonable
restriction avoids a class of errors in the allocated code that are quite difficult to debug.
The simulator only supports word-aligned accesses—that is, the address must be evenly
divisible by four. For this assignment, addresses above 32,767 are reserved for the register
allocator to use as spill locations. Any values that an ILOC test block stores to memory (other
than spills) must use an address between 0 and 32,764, inclusive.
For more details, see the ILOC Simulator document, in ~comp412/students/lab2/simulator/ on
CLEAR.
Simulator Usage Example: If test1.i is in your present working directory, you can invoke the
simulator on test1.i in the following manner to test your register allocator:
/clear/courses/comp412/students/lab2/sim -r 5 -i 2048 1 2 3 < test1.i
This command will cause the simulator to execute the instructions in test1.i, print the values
corresponding to ILOC output instructions, and display the total number of cycles, operations,
and instructions executed.
The -r parameter is optional and restricts the number of registers the simulator will use. (In the
example, the simulator only uses 5 registers, named r0, r1, r2, r3, and r4.). You can use the –r
parameter to verify that code generated by your allocator uses at most k registers. You should
not use -r when running the original (non-transformed) report and timing blocks.
The -i parameter is used to fill memory, starting at the memory address indicated by the first
argument that appears after -i, with the initial values listed after the memory address. The load
and store operations available in the ILOC subset require word-aligned addresses (that is,
addresses must be evenly divisible by 4). The example command line shown above initializes
location 2048 to 1, location 2052 to 2, and location 2056 to 3. (If the first operation in block
test1.i is "output 2048", the simulator will print the value 1 to stdout.) When computing
addresses for new spill locations, your allocator must generate word-aligned addresses.
The simulator’s -x parameter will be used to verify that your allocator passes the Lab 2 code
check. For example, if your 412alloc implementation produces a file of renamed ILOC code
called renamed_block.i, the following command can be used to check whether renaming was
correctly performed:
/clear/courses/comp412/students/lab2/sim -x < renamed_block.i
See the ILOC simulator document for additional information about supported command-line
options. (Note that the command-line options -d, -s, and -c are not relevant for Lab 2.)
Lab 2: Local Register Allocation Version 2024-1
COMP 412 10 Fall 2024
ILOC Input Blocks: A large collection of ILOC input blocks is available on CLEAR, in the directory
~comp412/students/ILOC/. Each block has the //SIM INPUT: and //OUTPUT: specifications to
allow the various testing scripts to check for correctness. If you experience problems with the
input blocks, please submit bug reports to the course Piazza site.
To estimate your allocator’s performance, you may want to use the report blocks, which are
available on CLEAR in ~comp412/students/lab2/report/. The report blocks all appear in the
production autograder’s test suite. The autotimer uses a subset of the blocks found on CLEAR in
~comp412/students/ILOC/Scalability/SLOCs/.
B. Tools
B.1 Reference Allocator
To help you understand the functioning of a local register allocator and to provide an exemplar
for your implementation and debugging efforts, we provide a reference allocator, lab2_ref. The
reference allocator is a C implementation of the allocator. It follows the basic outline of the
algorithm presented in class; it pays careful attention to how it generates spill code. You can
improve your understanding of register allocation by examining its output on small blocks. The
output code includes comments that are intended to help you understand what it did.
The reference allocator is an example. You do not need to duplicate its behavior, its results, or
the allocations that it produces.
You can use the reference allocator to determine how well your allocator performs in terms of
effectiveness (the number of execution cycles that the simulator reports when it runs the code
that your allocator generates) and efficiency (the runtime of your allocator itself).
The COMP 412 reference allocator can be invoked on CLEAR as follows:
~comp412/students/lab2/lab2_ref k
where k is an integer (3 £ k £ 64) that specifies the number of registers available to the
allocator and is a valid Linux pathname relative to the current working directory that
names an input file. For a description of the complete set of flags supported by the COMP 412
reference allocator, enter the following command on CLEAR:
~comp412/students/lab2/lab2_ref –h
Note that the COMP 412 reference allocator can only be run on CLEAR.
B.2 Testing and Timing Scripts
Scripts to test your allocator’s correctness and efficiency are available on CLEAR in the directory
~comp412/students/lab2/. Directions are provided in the related README files.
Lab 2: Local Register Allocation Version 2024-1
COMP 412 11 Fall 2024
C. Timing Results from Prior Years
The graphs below show the timing results for the fastest implementation written in each of C,
C++, Java, Python, and Go, from Fall 2021. In addition, we include graphs for Ruby (2014),
OCaml (2015), Haskell (2015), and R (2014). These graphs should provide you with a reasonable
notion of what kind of efficiency a student can achieve in the allocator project.
Note the units on the vertical axes of the graphs. They change significantly between languages.
D. Checklist for Lab 2
The following high-level checklist is provided to help you track your progress on Lab 2.
£ Implement a bottom-up local register allocator based on the algorithm in § 13.3 of
Engineering a Compiler, 3rd Edition, and the project videos. Submit your allocator by
October 23, 2024.
£ Use the ILOC simulator, described in § A-1, to ensure that the allocated code produced by
your program is correct—that is, it produces an equivalent sequence of operations as
described on page 1—and to measure the number of cycles that the ILOC simulator requires
to execute the allocated block. A large library of ILOC test blocks is available for you to use
when testing your allocator in comp412’s students/ILOC subtree on CLEAR.
£ Test your allocator thoroughly on CLEAR. It will be graded on CLEAR.
£ Ensure that your code passes Lab 2 code check #1. To pass the code check, your code must
correctly scan, parse, perform register renaming, and print the resulting renamed ILOC
block to stdout. To receive full credit, submit results that demonstrate that your allocator
passes code check #1 on or before October 4, 2024.
£ Ensure that your code passes Lab 2 code check #2. To pass the code check, your code must
conform to the interface described in § 3 and must perform register allocation correctly and
print the resulting allocated ILOC block to stdout. To receive full credit, submit results that
demonstrate that your allocator passes code check #2 on or before October 16, 2024.
£ Spend the rest of your time improving the effectiveness of the allocator, as measured by
the number of cycles that the simulator reports when it runs the allocated code, and the
efficiency of the allocator, as reported by the autotimer.
To produce an effectiveness grade, we will run the allocator on each of the report blocks
and on a set of private blocks. We will test each code with k set to 3, 4, 5, 6, 8, and 10. The
number of points awarded to an allocator for effectiveness will be based on a comparison
of the cycle counts produced by the allocator and the cycle counts produced by lab2_ref on
the same input file and k value.

Change History:
2024-1 posted on 09/23/2024