-Language Design
-===============
-A central question is, what do we want our language to look like? Deciding to
-use haskell would be a first step, but that still leaves a lot of
-possibilities. However, why would we want to use Haskell?
-
- * Lots of existing support: Language specification, compilers, libraries,
- userbase. All of this reduces the workload to implement something.
- * All of Haskell is usable in simulation / testing: When not compiling to
- VHDL, but when doing functional tests, we can use all of Haskell's syntax,
- libraries, functions, etc. even when we don't support all of it in our
- compiler.
- * Haskell is probably expressive enough to be able to express a lot of
- different things and different approaches. By defining new (algebraic)
- types and operators, we can extend this even further. Finally, we could
- even use Template Haskell to do almost anything (The ForSyDe project uses
- Template Haskell extensively).
-
-Typing
-------
-What kind of types will we be using in our programs? The base type should be
-some kind of bit type, but there are two main options for these:
-
- * Use a single bit as a type. Calculations on these types represent the
- calculations in a single time slice (ie, during one clock cycle). Any
- state in the calculation is explicit, since the input state must be a
- function argument and the output state part of the function's value.
-
- Through the state values, these functions are closely tied to the clock
- domain in use (or whatever other model is used for the time domain). Ie,
- having different clock domains is non-trivial and will require
- modification to the function.
-
- Composition can be done by simply connection functions together. This does
- require that the "state" of a function contains the states of each of the
- function it calls. These are extracted from its state argument and passed
- on to the callees, while the states returned are again inserted into the
- resulting state of the outer function.
-
- This approach is the closest to normal functional programming and shows
- state very explicitly.
-
- * Use a stream of bits as a type. Each value models a continuous (infinite)
- stream of bits. Functions have streams as arguments and value and state
- could probably be implicit in the calculation or could be made explicit
- using delay elements (this is what Lava does).
-
- The primitive operations all operate on streams, which seems the
- fundamental difference between this and the previous approach.
-
- This approach shows structure more explicitly when delay elements are
- used, since the registers end up exactly there.
-
-It is probably possible to mix these approaches. In particular, the first
-approache eventually needs to do some I/O, which can be modeled as recursion
-over an infinite list of inputs resulting in an infinite list of outputs. This
-can be done at the top level always, but it is perhaps possible to move this
-recursion a bit downward and do composition based on stream functions instead
-of "single clock" functions. One problem that comes to mind is that one needs
-to guarantee that a function does not look into the future (ie, uses multiple
-input elements to generate one output element) and the state becomes a lot
-less explicit. This needs more thought.
-
-Implementation
-==============
-Assume we will want to translate a (subset of) haskell into something else.
-We will need to do parsing, typechecking, interpretation, etc. A few options
-for this are available:
-
- * Doing everything manually, possibly using a parser generator.
- Lot's of work. Requires us to write down the haskell grammar, create a
- parser, do all kinds of funky type checking -> Too much work.
- * Use the Language.Haskell library and write something in haskell. This
- library contains a Lexer, Parser and AST, but still does not do any type
- checking, desugaring and simplification. Still lots of work.
- * Hack into an existing compiler. By writing a backend for an existing
- compiler, we can save most of the haskell-specific work. This requires a
- compiler that is modular enough to have its backend replaced by another
- implementation. Also, the border between backend and frontend must be
- suited for the work we would like to do. This approach would use the
- original compiler's driver for the most part
- * Use components from an existing compiler. By reusing selected components
- and creating an own driver that uses these components, we can work with
- the haskell source without doing all the work ourselves. This requires a
- compiler that is very modular, so we can decide exactly which parts we
- would like to use and which we don't need.
-
-After some looking around it seems GHC provides a consistent and (as of
-version 6.10) documented API into its internals This allows us to write
-
- core <- compileToCoreSimplified "adder.hs"
-
-to compile the file `adder.hs` into a version in GHC's simplified CoreSyn
-representation. This is essentially an AST with type annotations, all
-syntactic sugar removed, redundant expressions simplified, etc. This seems to
-be a very useful form to work with. However, GHC provides other functions to
-access other parts of the compiler, so if we would like to access the source
-at another stage, or do some custom procesing in between, this is also
-possible (albeit a bit more complex than this).
-
-Problems
---------
-Some problems encountered or expected when trying to do some initial
-translator hackup:
-
- * Signal naming. In the generated VHDL the signals and ports need names.
- These can of course be generated, but if we want to do some actual
- debugging, we want useful signal names. For input ports generated from
- function arguments, the binder name could perhaps be used, but that is not
- always possible when patterns are more complex.
-
- For output ports, a name could be deduced when the output value is always
- computed in a where or let clause. However the simplification phase
- removes these clauses where possible, so this information is lost.
-
- Perhaps some way of explicitely labeling ports could be used.
- * Type classes and universal qualification types are a powerful way of
- making functions generic, which greatly increases their reusability.
- However, this extra genericity makes the resulting Core representation
- more complex. Since the actual types used are modeled as extra function
- arguments, this shouldn't be too hard, but this is something that probably
- needs implementation right away (because a lot of builtin haskell
- constructs, such as tuples, use it).
-
-<!-- vim: set sw=2 sts=2 ts=8: -->
projects / matthijs / master-project / report.git / blobdiff