Introduce fast processor

[plafer]

Work towards: #1558

The current rather naive implementation achieves 40 MHz on the fibonacci benchmark. So achieving 50 MHz should be quite doable, and maybe even 100 MHz (as hoped) - that is for stack-heavy workloads. It's still unclear to me the kind of performance we can expect for workloads that need a lot of memory accesses.

[bobbinth]

The current rather naive implementation achieves 40 MHz on the fibonacci benchmark.

Very cool! I wonder where the bottlenecks are here (i.e., is is the match statement to select between different instructions, or is it something else)? If it is the match statement, one other potential way could be to have an array of function pointers and instead of doing match statement, look up functions to execute from that array. Not sure if it will be much faster (or much slower) though.

[bobbinth]

I wonder how much of an impact it has that the Operation is pretty heavy. Specifically, I think memory footprint of a single instance is something like 16 bytes. Maybe the compiler can optimize this away somehow, but if not, loading an operation may require multiple memory reads.

[bobbinth]

I wonder if there is a way to avoid handling different cases for the current stack length. Maybe we pre-allocate a vector with a bunch of zeros and would always have more than 16 values on the stack. The, we could reduce this to something like:

let last = self.stack.len() - 1;
let ptr = self.stack.as_mut_ptr();
unsafe {
    std::ptr::swap(ptr.add(last), ptr.add(last - 1));
}

Which should have something like 10x smaller cycle count than the current code.