{"size": 6738, "ext": "scrbl", "max_stars_repo_path": "www/project.scrbl", "max_stars_repo_name": "themooer1/www", "max_stars_repo_stars_event_min_datetime": null, "max_stars_repo_stars_event_max_datetime": null, "max_issues_repo_path": "www/project.scrbl", "max_issues_repo_name": "themooer1/www", "max_issues_repo_issues_event_min_datetime": null, "max_issues_repo_issues_event_max_datetime": null, "max_forks_repo_path": "www/project.scrbl", "max_forks_repo_name": "themooer1/www", "max_forks_repo_forks_event_min_datetime": null, "max_forks_repo_forks_event_max_datetime": null}
{"max_stars_count": null, "max_issues_count": null, "max_forks_count": null, "avg_line_length": 39.6352941176, "max_line_length": 73, "alphanum_fraction": 0.7775304245}
#lang scribble/manual
@(require "defns.rkt")
@title[#:style '(unnumbered)]{Project}

There will be a final course project to be completed over the last
several weeks of the course.  The project will involve extending the
design and implementation of the programming language and its compiler
that we will develop throughout the semester.

For your project you should turn in your extension code, a directory
of examples that showcase your extension and the differences in
behavior compared to the original language, and a @bold{short}
paragraph describing anything you found interesting. Submission will
be handled by gradescope, with more details to follow.

The suggested deadline is the last date of classes - May 11th - to
avoid overlap with finals week. That said, you're free to take a few
extra days and submit after that deadline until the nominal date
of the final exam (which would have been on Tuesday, May 18th if it
was happening). That is a strict deadline, not imposed by me, so make
sure you have turned in your projects by then.

As a first step, you have to pick a project idea as your "assignment"
for this week. Just write a @bold{short} paragraph with your project
of choice: what you hope to accomplish and a high-level description of
your approach. This assignment should be live on Gradescope.

Here are some project ideas that have been discussed throughout the
semester:

@itemlist[

  @item{Error handling. Currently, our languages return a
  not-very-informative @tt{'err} symbol when things go wrong. Real
  languages offer a lot more information: the reason that something
  went wrong, context, expressions involved, file name, line numbers,
  etc. This project would aim to improve the error reporting for Loot.
  Improving that behavior for an interpreter is pretty straightforward
  and should be an easy first step for this project until you're happy
  with the output error messages.  Porting that better error behavior
  on the compiler is a bit more involved - there are multiple possible
  approaches to this, but hacking on the runtime system is always an
  option!
  }

  @item{Typing Loot. We have discussed typing for @tt{Hustle} and its
  implications in the compiler (deleting a whole lot of assertions), as
  well as typing for a simple lambda calculus. This project would aim
  to combine the two threads, implementing a type system on top of Loot.
  There are interesting design decisions here, so feel free to reach out
  to talk about them!}

  @item{Loot Optimizations. Sky's the limit here. You can try
  high-level optimizations (e.g. inlining, lambda lifting, dead-code
  elimination, partial evaluation, etc.) or low-level ones (register
  allocation, register-based calling conventions etc.). Optimizations
  can be tricky to get right, so make sure you reuse all the unit
  tests we have provided throughout the semester and expand upon them!}

  @item{Whatever feature you want to add! Get in touch to discuss whether
  its scope is appropriate for a final project.}
]


@;{


@(define repo "https://classroom.github.com/a/t5KO9b5-")

The goal of this project is to put together everything you've
learned over the semester to complete a full-featured compiler.

Project repository:
@centered{@link[repo repo]}

@link["code/project.pdf"]{Slides} from lecture on the project.

You are given a working compiler for an extension of the language we
have been developing all semester.

Your overall object is to improve the @emph{run-time} performance of
code generated by your compiler while maintaining correctness.

There will be two releases of benchmark programs:

@itemlist[
@item{Tuesday 12/3}
@item{Tuesday 12/10}
]

The final due date for your project is 10:30 AM on Saturday 12/14.

You will have an allowance of 10 minutes to @emph{compile} all benchmark
programs.  Exceeding the allowance result in a penalty, but there is
no reward for improving @emph{compile-time} performance so long as you
come in under the 10 minute mark.

You will have an allowance of 10 minutes to @emph{run} all benchmark
programs.  For full-credit, you must improve the overall run-time
performance by 20\%.  Run-time will compute as the average of three
runs, done on the GRACE cluster.

Full credit solutions will be entered in a compiler tournament to
determine the most performant (and correct) compiler.  Tournament
results do not count toward your grade and will involve compiling
programs not included in the benchmark suite.

Benchmark programs will be batch I/O programs: read some input,
compute something, produce a result and/or write some output.

I/O primitives include @racket[read-char], @racket[write-char]
(limited to the standard input and output ports).

The compiler supports a standard library, with source level
definitions provided to you.  See the @racket[stdlib] function 
in the compiler.

There will be a garbage collector provided by the second round of
benchmarks which you will need to incorporate in to your compiler.

@section[#:tag-prefix "fp-" #:style 'unnumbered]{Measuring run-times}

Let's look at an example of how to measure the run-time performance of
the code your compiler generates.

First, let's start with fairly computationally intensive program.
Here is a @link["code/fp/sieve.rkt"]{program} that computes the
@emph{n}th prime number using the ancient
@link["https://en.wikipedia.org/wiki/Sieve_of_Eratosthenes"]{Sieve of
Eratosthenes} method.

Save it to the directory where your compiler lives and run @tt{make
sieve.run}.  This will run the compiler to generate the @tt{sieve.run}
executable.  This program expects to read a number from the standard
input port.

Run:

@centered{@tt{echo -n 100 | ./sieve.run}}

to compute the 100th prime number.

To measure the time it takes, add the time command:

@centered{@tt{echo -n 100 | time ./sieve.run}}

This will run the program and show the result @emph{and} timing
information.  We will be concerned with improving the real time it
takes to run the program.


@section[#:tag-prefix "fp-" #:style 'unnumbered]{Testing}

@bold{There is separate a repository for tests.} When you push your
code, Travis will automatically run your code against the tests.  If
you would like to run the tests locally, clone the following
repository into the directory that contains your compiler and run
@tt{raco test .} to test everything:

@centered{@tt{https://github.com/cmsc430/fp-test.git}}

This repository will evolve as the week goes on, but any time there's
a significant update it will be announced on Piazza.

@section[#:tag-prefix "fp-" #:style 'unnumbered]{Submitting}

Pushing your local repository to github ``submits'' your work.  We
will grade the latest submission that occurs before the deadline.

}