Reverse state and inputs in higher-order cpu

[matthijs/master-project/dsd-paper.git] / cλash.lhs

diff --git a/cλash.lhs b/cλash.lhs
index 9fb964773a948b737ee7055d4e86500b3202a3c5..3d4dfadbb23a1eea2e60df2865593ab7f31686ed 100644 (file)
--- a/cλash.lhs
+++ b/cλash.lhs
@@ -65,6 +65,7 @@
 %
 
 \documentclass[conference,pdf,a4paper,10pt,final,twoside,twocolumn]{IEEEtran}
+\IEEEoverridecommandlockouts
 % Add the compsoc option for Computer Society conferences.
 %
 % If IEEEtran.cls has not been installed into the LaTeX system files,
@@ -398,7 +399,9 @@
 \IEEEauthorblockA{%Computer Architecture for Embedded Systems (CAES)\\ 
 Department of EEMCS, University of Twente\\
 P.O. Box 217, 7500 AE, Enschede, The Netherlands\\
-c.p.r.baaij@@utwente.nl, matthijs@@stdin.nl, j.kuper@@utwente.nl}}
+c.p.r.baaij@@utwente.nl, matthijs@@stdin.nl, j.kuper@@utwente.nl}
+% \thanks{Supported through FP7 project: S(o)OS (248465)}
+}
 % \and
 % \IEEEauthorblockN{Homer Simpson}
 % \IEEEauthorblockA{Twentieth Century Fox\\
@@ -1200,17 +1203,18 @@ fu op inputs (addr1, addr2) = regIn
 \end{code}
 
 \begin{code}
-cpu :: Word -> [(Index 6, Index 6) | 4] 
-  -> State [Word | 4] -> (State [Word | 4], Word)
-cpu input addrs (State fuss) = (State fuss', out)
+cpu :: State [Word | 4] -> Word 
+  -> [(Index 6, Index 6) | 4]
+  -> (State [Word | 4], Word)
+cpu (State regsOut) input addrs = (State regsIn, out)
   where
-    fuss' =   [ fu const  inputs (addrs!0) (fuss!0)
-              , fu (+)    inputs (addrs!1) (fuss!1)
-              , fu (-)    inputs (addrs!2) (fuss!2)
-              , fu (*)    inputs (addrs!3) (fuss!3)
-              ]
-    inputs    = 0 +> (1 +> (input +> fuss))
-    out       = head fuss
+    regsIn    =   [ fu const  inputs (addrs!0)
+                  , fu (+)    inputs (addrs!1)
+                  , fu (-)    inputs (addrs!2)
+                  , fu (*)    inputs (addrs!3)
+                  ]
+    inputs    =   0 +> (1 +> (input +> regsOut))
+    out       =   head regsOut
 \end{code}
 
 \section{Related work}
@@ -1272,11 +1276,7 @@ mentioned in this section.
 The merits of polymorphic typing, combined with higher-order functions, are 
 now also recognized in the `main-stream' hardware description languages, 
 exemplified by the new \VHDL-2008 standard~\cite{VHDL2008}. \VHDL-2008 support 
-for generics has been extended to types, allowing a developer to describe 
-polymorphic components. Note that those types still require an explicit 
-generic map, whereas types can be automatically inferred in \CLaSH. There are 
-also no (generally available) \VHDL\ synthesis tools that currently support 
-the \VHDL-2008 standard, and thus the synthesis of polymorphic types.
+for generics has been extended to types and subprograms, allowing a developer to describe components with polymorphic ports and function-valued arguments. Note that the types and subprograms still require an explicit generic map, whereas types can be automatically inferred, and function-values can be automatically propagated by the \CLaSH\ compiler. There are also no (generally available) \VHDL\ synthesis tools that currently support the \VHDL-2008 standard, and thus the synthesis of polymorphic types and function-valued arguments.
 
 % Wired~\cite{Wired},, T-Ruby~\cite{T-Ruby}, Hydra~\cite{Hydra}. 
 % 
@@ -1369,10 +1369,11 @@ the \VHDL-2008 standard, and thus the synthesis of polymorphic types.
 
 
 \section{Conclusion}
-The conclusion goes here.
-
+This research demonstrates once more that functional languages are well suited for hardware descriptions: function applications provide an elegant notation for component instantiation. Where this research goes beyond the existing functional hardware descriptions languages is the inclusion of various choice elements that are well suited to describe the conditional assignments in control-oriented hardware. Besides being able to translate these basic constructs to synthesizable \VHDL, the prototype compiler can also correctly translate descriptions that contain both polymorphic types and function-valued arguments.
 
+Where recent functional hardware description languages have mostly opted to embed themselves in an existing functional language, this research features a `true' compiler. As a result there is a clear distinction between compile-time and run-time, which allows a myriad of choice constructs to be part of an actual circuit description; a feature the embedded languages do not offer.
 
+\section{Future Work}
 
 % conference papers do not normally have an appendix