This week was cut short due to a bit of travelling, but it wasn't without some genuine productivity :)

The first thing I did was finish up getting Bonzomatic to build on OS X. Not that it's a super amazing port (it basically only plays nicely when opened from command line as it's not a proper app bundle), but it was fun to dig into a bit of C++ and help move that project forward. So that was rad.

The other thing I did was start playing with an idea that I've had for awhile. Basically, I want to do a purely functional language for describing hardware that can be used to produce verilog for hardware synthesis as well as performant code, and would be ideal for writing, for example, an emulator for something like NES or Gameboy. It's something I've toyed with in my head for months, only to just now start making it concrete.

Generally, the language looks something like Haskell or F# or Elm (basically it's in the ML family). For example, a trivial system might look like this:

type System =
  { cpu : DerpCpu
  }

type DerpCpu =
  { x : U8
  , y : U8
  }

main : System
main = unitialized

cycle : Bit -> System -> System
cycle reset system =
  system where { cpu = cycleCpu reset system.cpu }

cycleCpu : Bit -> DerpCpu -> DerpCpu
cycleCpu reset cpu =
  match reset with
  | High ->
    DerpCpu
      { x = 0
      , y = 0
      }
  | _ ->
    cpu where
      { x = cpu.x + 1
      , y = 0
      }

Some key insights:

• Any such system should be able to be described by a data structure that models the entire state of the system, and a cycle function that transitions from one instance of the data structure to another. This execution forms a loop, not unlike the main loop in a typical interactive program, or the loops of combinational logic connecting a register's output to its input in an RTL system.
• Since this tool would generate hardware and a performant program, the computation model should be removed from both a structural RTL description and an imperative list of instructions. In theory, a functional style is just one of many styles that could work, and I just happen to like doing things that way, so I have a feeling it will work.

After spending hours thinking of how it might work, I've concluded the only way to move forward for me is to start implementing, build up more and more complex cases to make them concrete, and see what walls I run into. So far, I've only started a basic parser for the language, and I've still got lots of demoscene stuff to work on, so progress will likely move slowly, but it feels good to start this and get it moving. I'll write more as I discover more and formalize it a bit. Also, for now it's closed-source, but if successful, that will likely change at some point down the line.

Last Edited on Mon May 30 2016 18:49:05 GMT-0400 (EDT)