X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Fdsd-paper.git;a=blobdiff_plain;f=c%CE%BBash.lhs;h=a9de945ea7659b65e6251a930a7f81db5ea776b5;hp=1b3dc1323f3e7fc61ce227c2d6f1c63bf6424273;hb=f5c0a08b8c7c946a9e10fedc0d5ae52675407db4;hpb=1f90a9bb5ae9a772a8c641360a84146b6295cb37

diff --git "a/c\316\273ash.lhs" "b/c\316\273ash.lhs"
index 1b3dc13..a9de945 100644
--- "a/c\316\273ash.lhs"
+++ "b/c\316\273ash.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}
@@ -1365,10 +1369,39 @@ for generics has been extended to types and subprograms, allowing a developer to
 
 
 \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, such as patter matching, 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 the 
+actual circuit description; a feature the embedded hardware description 
+languages do not offer.
+
+\section{Future Work}
+The choice of describing state explicitly as extra arguments and results can 
+be seen as a mixed blessing. Even though the description that use state are 
+usually very clear, one finds that dealing with unpacking, passing, receiving 
+and repacking can become tedious and even error-prone, especially in the case 
+of sub-states. Removing this boilerplate, or finding a more suitable 
+abstraction mechanism would make \CLaSH\ easier to use.
+
+The transformations in normalization phase of the prototype compiler were 
+developed in an ad-hoc manner, which makes the existence of many desirable 
+properties unclear. Such properties include whether the complete set of 
+transformations will always lead to a normal form or if the normalization 
+process always terminates. Though various use cases suggests that these 
+properties usually hold, they have not been formally proven. A systematic 
+approach to defining the set of transformations allows one to proof that the 
+earlier mentioned properties do indeed exist.
 
 % conference papers do not normally have an appendix