<p dir="ltr">Limiting the scope for my own sanity here, there may yet be some application in various hardware level emulations of continuation passing calculi, perhaps building on static single assignment.</p>
<p dir="ltr">It might be possoble to derive an interesting instruction set from the sorts of intermediate representations we see in compiler infrastructures like LLVM, but it is hard to guess how these hardware designs would benefit haskell, rather than the other way around.</p>
<p dir="ltr">Cheers,<br>
Darren</p>
<div class="gmail_quote">On Jan 19, 2016 14:44, "Auke Booij" <<a href="mailto:auke@tulcod.com">auke@tulcod.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This question is much more involved than you seem to be suggesting.<br>
It's not just about adding "some instructions for Haskell support".<br>
You have to think about how you want to express /every/ haskell term<br>
as a series of bits (preferably predictably many bits), and find a<br>
(finite) combination of logical gates to do arbitrary computations<br>
with them.<br>
<br>
If you want to go anywhere in this directions, perhaps a good start<br>
would be implementing a processor with instructions for (untyped)<br>
lambda calculus. One approach for this could be to take a<br>
(mathematical) model of lambda calculus and see how its elements can<br>
be represented as natural numbers.<br>
<br>
This implementation, I suspect, would be terribly inefficient. Think<br>
about what the lambda application gate would look like in terms of<br>
NAND gates. Yes, it can probably be done in theory. No, it won't be<br>
pretty. And forget about practical.<br>
<br>
Finally, a major advantage of having such "raw" language as an<br>
instruction set is that it allows many many optimizations (e.g.<br>
pipelining (which, I would say, is the single most important reason<br>
that processors are able to run at GHzs instead of MHzs (Pentium 4<br>
processors, famed for their high clock speed, had 31 pipeline<br>
stages))) that I cannot imagine being possible in anything close to a<br>
"lambda calculus processor".<br>
<br>
What is the added value you hope to achieve?<br>
<br>
On 19 January 2016 at 22:12, Henning Thielemann<br>
<<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> every now and then I think it would be cool to have a microprocessor that<br>
> supports Haskell in a way. A processor where lazy evaluation is not overhead<br>
> but an optimization opportunity, a processor that can make use of the<br>
> explicit data dependencies in Haskell programs in order to utilize many<br>
> computation units in parallel. I know of the Reduceron project, which<br>
> evolves only slowly and if it somewhen is ready for use it is uncertain<br>
> whether it can compete with stock CPUs since FPGA's need much more chip<br>
> space for the same logic.<br>
><br>
> I got to know that in todays x86 processors you can alter the instruction<br>
> set, which is mainly used for bugfixes. Wouldn't it be interesting to add<br>
> some instructions for Haskell support? However, I suspect that such a patch<br>
> might be rendered invalid by new processor generations with changed internal<br>
> details. Fortunately, there are processors that are designed for custom<br>
> instruction set extensions:<br>
>    <a href="https://en.wikipedia.org/wiki/Xtensa" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Xtensa</a><br>
><br>
> Would it be sensible to create a processor based on such a design? I have no<br>
> idea what it might cost, and you would still need some peripheral circuitry<br>
> to run it. What could processor instructions for Haskell support look like?<br>
> Has anyone already thought in this direction?<br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div>