[Haskell-cafe] CPU with Haskell support
Serguey Zefirov
sergueyz at gmail.com
Wed Jan 20 12:43:45 UTC 2016
The "belt", as I can guess, either has same addressing problems as stack -
it shifts, so addresses of operands will be hard to compute knowing only
their state of stack. Or, if belt does not shift, it is equivalent to the N
(depends on arch) copies of regular two port register file. That was
attempted in Alpha AXP 21264, I believe - there were two register files to
reduce wiring overhead in them and they were masked by register renaming,
keeping architecture implementation minutae hidden. I also think you should
multiply that N above by 2, for at least two register files for two operand
operations and by M (number of ALUs) or risk developing your own register
file with M*2 ports (the wiring overhead of register file is O(ports^2)).
The infamous Elbrus 2K VLIW CPU suffered from slow register file for years
(as, I believe, Itanium do - compare its clock frequency with Xeons). I
believe Elbrus team more or less solved that in about 2010.
I can be wrong, of course, but I generally try to stay away from VLIW or
very high ILP single cores in my CPU designs (which I still do in my spare
time).
2016-01-20 15:20 GMT+03:00 Thomas Bereknyei <tomberek at gmail.com>:
> There is a CPU being design with an interesting architecture. Take a look
> at the Mill CPU at millcomputing.com.
>
> A facsinating feature is the use of a belt of values vs registers. The
> values on the belt are immutable and fall off (~auto gc'd?) unless
> expressly saved or returned.
>
> It is also desined to make function calls very cheap.
>
> tomberek
> On Jan 20, 2016 3:49 AM, <haskell-cafe-request at haskell.org> wrote:
>
> Send Haskell-Cafe mailing list submissions to
> haskell-cafe at haskell.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> or, via email, send a message with subject or body 'help' to
> haskell-cafe-request at haskell.org
>
> You can reach the person managing the list at
> haskell-cafe-owner at haskell.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Haskell-Cafe digest..."
>
>
> Today's Topics:
>
> 1. Re: Doc generation? (Patrick Redmond)
> 2. Re: Doc generation? (Mark Fine)
> 3. Host-Oriented Template Haskell (Ericson, John)
> 4. [ANN] ghc-mod-5.5.0.0: Happy Haskell Hacking (Daniel Gr?ber)
> 5. CPU with Haskell support (Henning Thielemann)
> 6. Re: Doc generation? (Noon Silk)
> 7. Re: Doc generation? (Mikhail Glushenkov)
> 8. Re: CPU with Haskell support (Auke Booij)
> 9. Re: CPU with Haskell support (Darren Grant)
> 10. Re: CPU with Haskell support (Henning Thielemann)
> 11. Re: CPU with Haskell support (Ben Lippmeier)
> 12. Re: CPU with Haskell support (Richard A. O'Keefe)
> 13. Re: CPU with Haskell support (Gleb Popov)
> 14. Re: Doc generation? (Sven Panne)
> 15. Re: Doc generation? (Mikhail Glushenkov)
> 16. Re: CPU with Haskell support (Joachim Durchholz)
> 17. Re: Doc generation? (Sven Panne)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 19 Jan 2016 08:39:20 -0800
> From: Patrick Redmond <plredmond at gmail.com>
> To: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
> "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] Doc generation?
> Message-ID:
> <CAHUea4Ht0p8=HwphL+--V7j3Xftt=
> 8drrZDuOQtcB38rPPkJ2w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I don't know what's happening with hackage, but if you're using stack in
> your workflow a simple workaround is to build docs locally and search them
> with a shell script. For example:
>
> $ stack haddock async
>
> And then muck around in .stack-work or ~/.stack. I've written a
> bash/fish script to do the search for you here:
> plredmond.github.io/posts/search-haddocks-offline.html
>
> On Tuesday, January 19, 2016, Francesco Ariis <fa-ml at ariis.it> wrote:
>
> > On Tue, Jan 19, 2016 at 04:24:24PM +1100, Noon Silk wrote:
> > > Does anyone know what is happening here?
> > >
> > > Not a single one of the packages on
> > > http://hackage.haskell.org/packages/recent has docs generated at the
> > moment.
> > >
> > > Some older ones, upload this year, also do not -
> > > http://hackage.haskell.org/package/pipes-concurrency
> >
> > Docs not being built can be quite frustrating; for those dark times I
> > build them locally:
> >
> > http://ariis.it/static/articles/no-docs-hackage/page.html
> >
> > Living with a flaky WiFi, saves me from screaming at the monitor quite
> > some times.
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org <javascript:;>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/517bfc2f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 19 Jan 2016 09:51:40 -0800
> From: Mark Fine <mark.fine at gmail.com>
> To: Patrick Redmond <plredmond at gmail.com>
> Cc: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
> "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] Doc generation?
> Message-ID:
> <
> CANRZ_fkC4-wM8-UyzeQEFJiiUZ02qo22CHdhfUt68wQeaRX8UA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Also, if the packages are on stackage, you can look at the documentation
> there:
>
> https://www.stackage.org/package/pipes-concurrency
>
> Mark
>
> On Tue, Jan 19, 2016 at 8:39 AM, Patrick Redmond <plredmond at gmail.com>
> wrote:
>
> > I don't know what's happening with hackage, but if you're using stack in
> > your workflow a simple workaround is to build docs locally and search
> them
> > with a shell script. For example:
> >
> > $ stack haddock async
> >
> > And then muck around in .stack-work or ~/.stack. I've written a
> > bash/fish script to do the search for you here:
> > plredmond.github.io/posts/search-haddocks-offline.html
> >
> > On Tuesday, January 19, 2016, Francesco Ariis <fa-ml at ariis.it> wrote:
> >
> >> On Tue, Jan 19, 2016 at 04:24:24PM +1100, Noon Silk wrote:
> >> > Does anyone know what is happening here?
> >> >
> >> > Not a single one of the packages on
> >> > http://hackage.haskell.org/packages/recent has docs generated at the
> >> moment.
> >> >
> >> > Some older ones, upload this year, also do not -
> >> > http://hackage.haskell.org/package/pipes-concurrency
> >>
> >> Docs not being built can be quite frustrating; for those dark times I
> >> build them locally:
> >>
> >> http://ariis.it/static/articles/no-docs-hackage/page.html
> >>
> >> Living with a flaky WiFi, saves me from screaming at the monitor quite
> >> some times.
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >>
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/c6010b86/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 19 Jan 2016 13:17:02 -0800
> From: "Ericson, John" <john_ericson at brown.edu>
> To: Haskell-Cafe <haskell-cafe at haskell.org>
> Subject: [Haskell-cafe] Host-Oriented Template Haskell
> Message-ID:
> <
> CA+Vhx4TF0x5-XrKi09A36xVww2HyWr0J3QysqJYdJbKDU3dhDw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> As is well known, TH and cross-compiling do not get along. There are
> various proposals on how to make this interaction less annoying, and I
> am not against them. But as I see it, the problem is largely inherent
> to the design of TH itself: since values can (usually) be lifted from
> compile-time to run-time, and normal definitions from upstream modules
> to downstream modules' TH, TH and normal code must "live in the same
> world".
>
> Now this restriction in turn bequeaths TH with much expressive power,
> and I wouldn't advocate getting rid of it. But many tasks do not need
> it, and in some cases, say in bootstrapping compilers[1] themselves,
> it is impossible to use TH because of it, even were all the current
> proposals implemented.
>
> For these reason, I propose a new TH variant which has much harsher
> phase separation. Normal definitions from upstream modules can not be
> used, lifting values is either not permitted or is allowed to fail
> (because of missing/incompatible definitions), and IO is defined to
> match the behavior of the host, not target, platform (in the cross
> compiling case). The only interaction between the two phases is that
> quoted syntax is resolved against the the run-time phase's definitions
> (just like today).
>
> Some of you may find this a shoddy substitute for defining a subset of
> Haskell which behaves identically on all platforms, and optionally
> constraining TH to it. But the big feature that my proposal offers and
> that one doesn't is to be able to independently specify compile-time
> dependencies for the host-oriented TH---this is analogous to the
> newish `Setup.hs` dependencies. That in turns leads to what I think is
> the "killer app" for Host-Oriented TH: exposing the various
> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries,
> and side-stepping any need for "executable dependencies" in Cabal.
> Note also that at least hsc2hs additionally requires host-IO---there
> may not even exist a C compiler on the target platform at all.
>
> Finally, forgive me if this has been brought up before. I've been
> thinking about this a while, and did a final pass over the GHC wiki to
> make sure it wasn't already proposed, but I could have missed
> something (this is also my first post to the list).
>
> John
>
> [1]:
> https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 19 Jan 2016 22:19:48 +0100
> From: Daniel Gr?ber <dxld at darkboxed.org>
> To: haskell-cafe at haskell.org
> Subject: [Haskell-cafe] [ANN] ghc-mod-5.5.0.0: Happy Haskell Hacking
> Message-ID: <20160119211948.GA16744 at grml>
> Content-Type: text/plain; charset="us-ascii"
>
> I'm pleased to announce the release of ghc-mod 5.5.0.0!
>
> This is primarily a maintenance and bug fix release. We are releasing this
> as a
> major version bump as we are following a policy of not trying to keep API
> compatibility until v6.0 to enable us to clean up ghc-mod's internals and
> API.
>
> What's new?
> ===========
>
> * Cabal flags are now preserved across automatic reconfigurations
>
> When ghc-mod detects something influencing the cabal configuration has
> changed
> since the last invocation it will automatically reconfigure the
> project. Previously this would call 'cabal configure' without any
> additional
> options thus possibly reverting flags the user might have added to the
> configure command previously. Now we extract the current set of flags
> from the
> existing configuration and pass the appropriate options to the configure
> command.
>
> * Rewritten command-line parser (again)
>
> The home grown sub-command parser based on getopt has been a user
> experience
> disaster so we've replaced it using a new optparse-applicative based
> parser.
> This does have the unfortunate side effect that we had to remove support
> for
> some optional arguments we had supported previously thus breaking
> compatibility with very old frontends.
>
> * Remove CWD requirement from command-line tools
>
> In v5.4.0.0 we had to add a workaround for a nasty race condition in
> 'ghc-mod
> legacy-interactive' (ghc-modi) which added a requirement that all ghc-mod
> command line tools are run in the root of each project's directory. This
> limitation has now been removed. Frontends which have implemented this
> workaround should be compatible going forward but for performance
> reasons it
> is advisable to disable the workaround for versions after v5.5.0.0.
>
> * Various bug fixes and smaller improvements
>
> From the change log:
> * Fix cabal-helper errors when no global GHC is installed (Stack)
> * Support for spaces in file names when using legacy-interactive
> * Fix "No instance nor default method for class operation put"
> * Fix a variety of caching related issues
> * Emacs: Fix slowdown and bugs caused by excessive use of `map-file`
> * Emacs: Add ghc-report-errors to inhibit *GHC Error* logging
>
>
> What is ghc-mod?
> ================
>
> ghc-mod is both a back-end program for enhancing editors and other kinds of
> development environments with support for Haskell and a library for
> abstracting
> the black magic incantations required to use the GHC API in various
> environments, especially Cabal and Stack projects. The library is used by
> ambitious projects like HaRe[1], mote[2] and haskell-ide-engine[3]
>
>
> Getting ghc-mod
> ===============
>
> GitHub: https://github.com/DanielG/ghc-mod
> Hackage: http://hackage.haskell.org/package/ghc-mod
>
> Editor frontends:
>
> - Emacs (native):
> https://github.com/DanielG/ghc-mod
> https://github.com/iquiw/company-ghc
> - Vim:
> https://github.com/eagletmt/ghcmod-vim
> https://github.com/eagletmt/neco-ghc
> - Atom:
> https://github.com/atom-haskell/ide-haskell
>
> Known issues
> ============
>
> For issues other than the ones mentioned below visit our issue tracker:
>
> https://github.com/DanielG/ghc-mod/issues
>
> Frequently reported issues
> --------------------------
>
> ghc-mod once compiled is bound to one version of GHC since we link against
> the
> GHC API library. This used to not be a very big problem but since Stack
> made it
> exceedingly easy for users to use more than one version of GHC without even
> knowing the number of problems in this area has exploded. We are tracing
> the
> issue in the following issue:
> https://github.com/DanielG/ghc-mod/issues/615
> (Support switching GHC versions without recompiling ghc-mod)
>
> ghc-mod's `case`, `sig` and `refine` commands still do not work properly
> with
> GHC>7.10 (See https://github.com/DanielG/ghc-mod/issues/438). Unless
> someone volunteers to fix this issue I will work towards replacing the
> features
> using mote[2] instead as the current code is, from my point of view,
> unmaintainable.
>
> If you do notice any other problems please report them:
>
> https://github.com/DanielG/ghc-mod/issues/new
>
> ----
> [1]: https://github.com/alanz/HaRe
> [2]: https://github.com/imeckler/mote
> [3]: https://github.com/haskell/haskell-ide-engine
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: not available
> URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/9fea4144/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 5
> Date: Tue, 19 Jan 2016 23:12:02 +0100 (CET)
> From: Henning Thielemann <lemming at henning-thielemann.de>
> To: Haskell Cafe <haskell-cafe at haskell.org>
> Subject: [Haskell-cafe] CPU with Haskell support
> Message-ID: <alpine.DEB.2.02.1601192250000.16459 at sputnik>
> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>
>
> Hi all,
>
> every now and then I think it would be cool to have a microprocessor that
> supports Haskell in a way. A processor where lazy evaluation is not
> overhead but an optimization opportunity, a processor that can make use of
> the explicit data dependencies in Haskell programs in order to utilize
> many computation units in parallel. I know of the Reduceron project, which
> evolves only slowly and if it somewhen is ready for use it is uncertain
> whether it can compete with stock CPUs since FPGA's need much more chip
> space for the same logic.
>
> I got to know that in todays x86 processors you can alter the instruction
> set, which is mainly used for bugfixes. Wouldn't it be interesting to add
> some instructions for Haskell support? However, I suspect that such a
> patch might be rendered invalid by new processor generations with changed
> internal details. Fortunately, there are processors that are designed for
> custom instruction set extensions:
> https://en.wikipedia.org/wiki/Xtensa
>
> Would it be sensible to create a processor based on such a design? I have
> no idea what it might cost, and you would still need some peripheral
> circuitry to run it. What could processor instructions for Haskell support
> look like? Has anyone already thought in this direction?
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 20 Jan 2016 09:37:26 +1100
> From: Noon Silk <noonslists at gmail.com>
> To: Mark Fine <mark.fine at gmail.com>
> Cc: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
> "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] Doc generation?
> Message-ID:
> <CADt_azZv_w+nFgQiOrRVGucKV7Wf4h-Y7YjVfO=
> pMc_QqhFjXw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks Mark and All,
>
> Indeed, I've been generating the docs myself offline; I didn't know about
> looking for the docs on stackage; thanks!
>
> --
> Noon
>
> On Wed, Jan 20, 2016 at 4:51 AM, Mark Fine <mark.fine at gmail.com> wrote:
>
> > Also, if the packages are on stackage, you can look at the documentation
> > there:
> >
> > https://www.stackage.org/package/pipes-concurrency
> >
> > Mark
> >
> > On Tue, Jan 19, 2016 at 8:39 AM, Patrick Redmond <plredmond at gmail.com>
> > wrote:
> >
> >> I don't know what's happening with hackage, but if you're using stack in
> >> your workflow a simple workaround is to build docs locally and search
> them
> >> with a shell script. For example:
> >>
> >> $ stack haddock async
> >>
> >> And then muck around in .stack-work or ~/.stack. I've written a
> >> bash/fish script to do the search for you here:
> >> plredmond.github.io/posts/search-haddocks-offline.html
> >>
> >> On Tuesday, January 19, 2016, Francesco Ariis <fa-ml at ariis.it> wrote:
> >>
> >>> On Tue, Jan 19, 2016 at 04:24:24PM +1100, Noon Silk wrote:
> >>> > Does anyone know what is happening here?
> >>> >
> >>> > Not a single one of the packages on
> >>> > http://hackage.haskell.org/packages/recent has docs generated at the
> >>> moment.
> >>> >
> >>> > Some older ones, upload this year, also do not -
> >>> > http://hackage.haskell.org/package/pipes-concurrency
> >>>
> >>> Docs not being built can be quite frustrating; for those dark times I
> >>> build them locally:
> >>>
> >>> http://ariis.it/static/articles/no-docs-hackage/page.html
> >>>
> >>> Living with a flaky WiFi, saves me from screaming at the monitor quite
> >>> some times.
> >>> _______________________________________________
> >>> Haskell-Cafe mailing list
> >>> Haskell-Cafe at haskell.org
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >>>
> >>
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >>
> >>
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
> >
>
>
> --
> Noon Silk, ?
>
> https://silky.github.io/
>
> "Every morning when I wake up, I experience an exquisite joy ? the joy
> of being this signature."
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/f8298446/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 7
> Date: Tue, 19 Jan 2016 23:40:31 +0100
> From: Mikhail Glushenkov <mikhail.glushenkov at gmail.com>
> To: Noon Silk <noonslists at gmail.com>
> Cc: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
> "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] Doc generation?
> Message-ID:
> <CA+tcxkC7EZdeL6jFK7bA4=
> oARD+WCsgctKUqyJ9yMEyV7z1O-Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi *,
>
> On 19 January 2016 at 23:37, Noon Silk <noonslists at gmail.com> wrote:
> > Thanks Mark and All,
> >
> > Indeed, I've been generating the docs myself offline; I didn't know
> about
> > looking for the docs on stackage; thanks!
>
> Note that with the Git version of cabal-install you can run 'cabal
> upload --doc' to upload the docs to Hackage manually.
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 19 Jan 2016 22:44:26 +0000
> From: Auke Booij <auke at tulcod.com>
> To: Henning Thielemann <lemming at henning-thielemann.de>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] CPU with Haskell support
> Message-ID:
> <
> CAP6YhL+GkGDjQSQuBE0HcrL8R6MAibSKRWu7jAR5Or8uwbDKfA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> This question is much more involved than you seem to be suggesting.
> It's not just about adding "some instructions for Haskell support".
> You have to think about how you want to express /every/ haskell term
> as a series of bits (preferably predictably many bits), and find a
> (finite) combination of logical gates to do arbitrary computations
> with them.
>
> If you want to go anywhere in this directions, perhaps a good start
> would be implementing a processor with instructions for (untyped)
> lambda calculus. One approach for this could be to take a
> (mathematical) model of lambda calculus and see how its elements can
> be represented as natural numbers.
>
> This implementation, I suspect, would be terribly inefficient. Think
> about what the lambda application gate would look like in terms of
> NAND gates. Yes, it can probably be done in theory. No, it won't be
> pretty. And forget about practical.
>
> Finally, a major advantage of having such "raw" language as an
> instruction set is that it allows many many optimizations (e.g.
> pipelining (which, I would say, is the single most important reason
> that processors are able to run at GHzs instead of MHzs (Pentium 4
> processors, famed for their high clock speed, had 31 pipeline
> stages))) that I cannot imagine being possible in anything close to a
> "lambda calculus processor".
>
> What is the added value you hope to achieve?
>
> On 19 January 2016 at 22:12, Henning Thielemann
> <lemming at henning-thielemann.de> wrote:
> >
> > Hi all,
> >
> > every now and then I think it would be cool to have a microprocessor that
> > supports Haskell in a way. A processor where lazy evaluation is not
> overhead
> > but an optimization opportunity, a processor that can make use of the
> > explicit data dependencies in Haskell programs in order to utilize many
> > computation units in parallel. I know of the Reduceron project, which
> > evolves only slowly and if it somewhen is ready for use it is uncertain
> > whether it can compete with stock CPUs since FPGA's need much more chip
> > space for the same logic.
> >
> > I got to know that in todays x86 processors you can alter the instruction
> > set, which is mainly used for bugfixes. Wouldn't it be interesting to add
> > some instructions for Haskell support? However, I suspect that such a
> patch
> > might be rendered invalid by new processor generations with changed
> internal
> > details. Fortunately, there are processors that are designed for custom
> > instruction set extensions:
> > https://en.wikipedia.org/wiki/Xtensa
> >
> > Would it be sensible to create a processor based on such a design? I
> have no
> > idea what it might cost, and you would still need some peripheral
> circuitry
> > to run it. What could processor instructions for Haskell support look
> like?
> > Has anyone already thought in this direction?
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 19 Jan 2016 15:00:12 -0800
> From: Darren Grant <dedgrant at gmail.com>
> To: Auke Booij <auke at tulcod.com>
> Cc: Henning Thielemann <lemming at henning-thielemann.de>, Haskell Cafe
> <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] CPU with Haskell support
> Message-ID:
> <CA+9vpFcay+6h97CqG+PBoVTjuEREfMCX5hkkXsqpdG4i=
> NxGBg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.
>
> 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.
>
> Cheers,
> Darren
> On Jan 19, 2016 14:44, "Auke Booij" <auke at tulcod.com> wrote:
>
> > This question is much more involved than you seem to be suggesting.
> > It's not just about adding "some instructions for Haskell support".
> > You have to think about how you want to express /every/ haskell term
> > as a series of bits (preferably predictably many bits), and find a
> > (finite) combination of logical gates to do arbitrary computations
> > with them.
> >
> > If you want to go anywhere in this directions, perhaps a good start
> > would be implementing a processor with instructions for (untyped)
> > lambda calculus. One approach for this could be to take a
> > (mathematical) model of lambda calculus and see how its elements can
> > be represented as natural numbers.
> >
> > This implementation, I suspect, would be terribly inefficient. Think
> > about what the lambda application gate would look like in terms of
> > NAND gates. Yes, it can probably be done in theory. No, it won't be
> > pretty. And forget about practical.
> >
> > Finally, a major advantage of having such "raw" language as an
> > instruction set is that it allows many many optimizations (e.g.
> > pipelining (which, I would say, is the single most important reason
> > that processors are able to run at GHzs instead of MHzs (Pentium 4
> > processors, famed for their high clock speed, had 31 pipeline
> > stages))) that I cannot imagine being possible in anything close to a
> > "lambda calculus processor".
> >
> > What is the added value you hope to achieve?
> >
> > On 19 January 2016 at 22:12, Henning Thielemann
> > <lemming at henning-thielemann.de> wrote:
> > >
> > > Hi all,
> > >
> > > every now and then I think it would be cool to have a microprocessor
> that
> > > supports Haskell in a way. A processor where lazy evaluation is not
> > overhead
> > > but an optimization opportunity, a processor that can make use of the
> > > explicit data dependencies in Haskell programs in order to utilize many
> > > computation units in parallel. I know of the Reduceron project, which
> > > evolves only slowly and if it somewhen is ready for use it is uncertain
> > > whether it can compete with stock CPUs since FPGA's need much more chip
> > > space for the same logic.
> > >
> > > I got to know that in todays x86 processors you can alter the
> instruction
> > > set, which is mainly used for bugfixes. Wouldn't it be interesting to
> add
> > > some instructions for Haskell support? However, I suspect that such a
> > patch
> > > might be rendered invalid by new processor generations with changed
> > internal
> > > details. Fortunately, there are processors that are designed for custom
> > > instruction set extensions:
> > > https://en.wikipedia.org/wiki/Xtensa
> > >
> > > Would it be sensible to create a processor based on such a design? I
> > have no
> > > idea what it might cost, and you would still need some peripheral
> > circuitry
> > > to run it. What could processor instructions for Haskell support look
> > like?
> > > Has anyone already thought in this direction?
> > > _______________________________________________
> > > Haskell-Cafe mailing list
> > > Haskell-Cafe at haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/58412564/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 10
> Date: Wed, 20 Jan 2016 00:03:06 +0100 (CET)
> From: Henning Thielemann <lemming at henning-thielemann.de>
> To: Auke Booij <auke at tulcod.com>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] CPU with Haskell support
> Message-ID: <alpine.DEB.2.02.1601192357580.16459 at sputnik>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>
> On Tue, 19 Jan 2016, Auke Booij wrote:
>
> > This question is much more involved than you seem to be suggesting.
> > It's not just about adding "some instructions for Haskell support".
> > You have to think about how you want to express /every/ haskell term
> > as a series of bits (preferably predictably many bits), and find a
> > (finite) combination of logical gates to do arbitrary computations
> > with them.
>
> I am not thinking about a radically different machine language, just a
> common imperative machine language with some added instructions for tasks
> often found in machine code generated from Haskell. E.g. mainstream
> processors support C function calls with special jump instruction and
> stack handling. Maybe there could be instructions that assist handling
> thunks or Haskell function calls.
>
>
> ------------------------------
>
> Message: 11
> Date: Wed, 20 Jan 2016 11:52:21 +1100
> From: Ben Lippmeier <benl at ouroborus.net>
> To: Henning Thielemann <lemming at henning-thielemann.de>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] CPU with Haskell support
> Message-ID: <3EAF442C-90D4-40BE-91CE-EB7AE3E6EAFC at ouroborus.net>
> Content-Type: text/plain; charset="utf-8"
>
>
> > On 20 Jan 2016, at 9:12 am, Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>
> > I got to know that in todays x86 processors you can alter the
> instruction set, which is mainly used for bugfixes. Wouldn't it be
> interesting to add some instructions for Haskell support? However, I
> suspect that such a patch might be rendered invalid by new processor
> generations with changed internal details. Fortunately, there are
> processors that are designed for custom instruction set extensions:
> > https://en.wikipedia.org/wiki/Xtensa
>
>
> Your post assumes that the time to fetch/decode the instruction stream is
> a bottleneck, and reducing the number of instructions will in some way make
> the program faster.
>
> Your typically lazy GHC compiled program spends much of its time building
> thunks and otherwise copying data between the stack and the heap. If it?s
> blocked waiting for data memory / data cache miss then reducing the number
> of instructions won?t help anything ? at least if the fancy new
> instructions just tell the processor to do something that would lead to
> cache miss anyway.
>
> See: Cache Performance of Lazy Functional Programs on Current Hardware
> (from 2009)
> Arbob Ahmad and Henry DeYoung
> http://www.cs.cmu.edu/~hdeyoung/15740/report.pdf <
> http://www.cs.cmu.edu/~hdeyoung/15740/report.pdf>
>
> Indirect branches are also a problem (load an address from data memory,
> then jump to it), as branch predictors usually cannot deal with them.
> Slowdowns due to mispredicted branches could perhaps be mitigated by
> improving the branch predictor in a Haskell specific way, but you might not
> need new instructions to do so.
>
> Or another way of putting it: ?If you tell a long story with less words,
> then it?s still a long story.?
>
> Ben.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/881d9bb6/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 12
> Date: Wed, 20 Jan 2016 18:16:49 +1300
> From: "Richard A. O'Keefe" <ok at cs.otago.ac.nz>
> To: Henning Thielemann <lemming at henning-thielemann.de>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] CPU with Haskell support
> Message-ID: <A1E52B20-6AF7-4153-A040-97DC2837ED85 at cs.otago.ac.nz>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On 20/01/2016, at 12:03 pm, Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
> > I am not thinking about a radically different machine language, just a
> common imperative machine language with some added instructions for tasks
> often found in machine code generated from Haskell. E.g. mainstream
> processors support C function calls with special jump instruction and stack
> handling. Maybe there could be instructions that assist handling thunks or
> Haskell function calls.
>
> I was at a presentation once where the speaker showed how
> (thanks to the fact that Prolog doesn't evaluate arguments
> in calls) calling a procedure and executing the procedure
> could be overlapped, getting a factor of 2 speedup for an
> important part of the code. At another presentation a
> speaker showed how using a special outboard coprocessor
> could dramatically speed up memory management.
>
> I suspect that neither technique would be much help on today's
> machines and for Haskell. However, there is a hint here that
> doing something quite different might pay off.
>
> For example, if branch predictors don't do well with thunk
> handling, maybe there is a way of processing thunks that a
> quite different kind of branch predictor *might* cope with.
> Or maybe something that's expecting to process thousands of
> microthreads might not care about branch prediction. (Although
> that idea has been tried as a way of handling memory latency,
> I don't think it's been tried for Haskell.)
>
> Perhaps you might look for something different; instead of
> 'faster on similar hardware' you might look at 'cheaper'.
> Could a specialised Haskell processor use less energy than
> a standard CPU?
>
> Don't quit your day job, but don't be too sure there's nothing
> left to think of either.
>
>
>
>
> ------------------------------
>
> Message: 13
> Date: Wed, 20 Jan 2016 10:05:48 +0300
> From: Gleb Popov <6yearold at gmail.com>
> To: Henning Thielemann <lemming at henning-thielemann.de>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] CPU with Haskell support
> Message-ID:
> <
> CALH631nuDoV_4kBkRWjZvNuZK59kJ6fV6A_hnAKGh9YYznHbSQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Jan 20, 2016 at 1:12 AM, Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>
> >
> > Hi all,
> >
> > every now and then I think it would be cool to have a microprocessor that
> > supports Haskell in a way. A processor where lazy evaluation is not
> > overhead but an optimization opportunity, a processor that can make use
> of
> > the explicit data dependencies in Haskell programs in order to utilize
> many
> > computation units in parallel. I know of the Reduceron project, which
> > evolves only slowly and if it somewhen is ready for use it is uncertain
> > whether it can compete with stock CPUs since FPGA's need much more chip
> > space for the same logic.
> >
> > I got to know that in todays x86 processors you can alter the instruction
> > set, which is mainly used for bugfixes. Wouldn't it be interesting to add
> > some instructions for Haskell support? However, I suspect that such a
> patch
> > might be rendered invalid by new processor generations with changed
> > internal details. Fortunately, there are processors that are designed for
> > custom instruction set extensions:
> > https://en.wikipedia.org/wiki/Xtensa
> >
> > Would it be sensible to create a processor based on such a design? I have
> > no idea what it might cost, and you would still need some peripheral
> > circuitry to run it. What could processor instructions for Haskell
> support
> > look like? Has anyone already thought in this direction?
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
>
> I remember reading relevent paper: The Reduceron reconfigured and
> re-evaluated. Authors are MATTHEW NAYLOR and COLIN RUNCIMAN.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/df0fdb6a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 14
> Date: Wed, 20 Jan 2016 08:09:38 +0100
> From: Sven Panne <svenpanne at gmail.com>
> To: Mikhail Glushenkov <mikhail.glushenkov at gmail.com>
> Cc: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
> "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] Doc generation?
> Message-ID:
> <CANBN=
> muZG_pSYHVyciMORC5nu0-y+ykhPdU-npLyCZ4J3srv3A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2016-01-19 23:40 GMT+01:00 Mikhail Glushenkov <
> mikhail.glushenkov at gmail.com>
> :
>
> > Note that with the Git version of cabal-install you can run 'cabal
> > upload --doc' to upload the docs to Hackage manually.
> >
>
> Are there any safeguards on the Hackage server side to guarantee
> consistency between the uploaded package and the uploaded docs? (i.e. make
> sure it's the right version etc.) Are there checks on the server side that
> the cross-package links are correct? Does the server make sure that the
> docs contain source links?
>
> If the answer to any of these questions is "no", I consider even the
> possibility of uploading docs by hand a bug. Wrong/partial documentation is
> worse than no documentation at all...
>
> Cheers,
> S.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/621dacc2/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 15
> Date: Wed, 20 Jan 2016 08:35:02 +0100
> From: Mikhail Glushenkov <mikhail.glushenkov at gmail.com>
> To: Sven Panne <svenpanne at gmail.com>
> Cc: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
> "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] Doc generation?
> Message-ID:
> <CA+tcxkDEk2pzTfGWuJ71KJuxY-ibwzOPwOvKhnoDu1Xe=
> u4q1Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On 20 January 2016 at 08:09, Sven Panne <svenpanne at gmail.com> wrote:
> > Are there any safeguards on the Hackage server side to guarantee
> consistency
> > between the uploaded package and the uploaded docs? (i.e. make sure it's
> the
> > right version etc.) Are there checks on the server side that the
> > cross-package links are correct? Does the server make sure that the docs
> > contain source links?
>
> If I'm reading [1] correctly, no such checks are performed.
>
> > If the answer to any of these questions is "no", I consider even the
> > possibility of uploading docs by hand a bug. Wrong/partial documentation
> is
> > worse than no documentation at all...
>
> You're welcome to open a ticket on the hackage-server bug tracker.
>
> [1]
> https://github.com/haskell/hackage-server/blob/master/Distribution/Server/Features/Documentation.hs#L223
>
>
> ------------------------------
>
> Message: 16
> Date: Wed, 20 Jan 2016 08:51:23 +0100
> From: Joachim Durchholz <jo at durchholz.org>
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] CPU with Haskell support
> Message-ID: <569F3C7B.80508 at durchholz.org>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Am 19.01.2016 um 23:12 schrieb Henning Thielemann:
> >
> > Fortunately, there are
> > processors that are designed for custom instruction set extensions:
> > https://en.wikipedia.org/wiki/Xtensa
>
> Unfortunately, the WP article does not say anything that couldn't be
> said about, say, an ARM core. Other than that Xtensa core being some
> VLIW design.
>
> > Would it be sensible to create a processor based on such a design?
>
> Very, very unlikely, for multiple reasons.
>
> Special-purpose CPUs have been built, most notably for LISP, less
> notably for Java, and probably for other purposes that I haven't heard of.
> Invariably, their architectural advantages were obsoleted by economy of
> scale: Mainstream CPUs are being produced in such huge numbers that
> Intel etc. could affort more engineers to optimize every nook and
> cranny, more engineers to optimize the structure downscaling, and larger
> fabs that could do more chips on more one-time expensive but per-piece
> cheap equipment, and in the end, the special-purpose chips were slower
> and more expensive. It's an extremely strong competition you are facing
> if you try this.
>
> Also, it is very easy to misidentify the actual bottlenecks and make
> instructions for the wrong ones.
> If caching is the main bottleneck (which it usually is), no amount of
> CPU improvement will help you and you'll simply need a larger cache. Or,
> probably, a compiler that knows enough about the program and its data
> flow to arrange the data in a cache-line-friendly fashion.
>
> I do not think this is going to be a long-term problem though. Pure
> languages have huge advantages for fine-grained parallel processing, and
> CPU technology is pushing towards multiple cores, so that's a natural
> match. As pure languages come into more widespread use, the engineers at
> Intel, AMD etc. will look at what the pure languages need, and add
> optimizations for these.
>
> Just my 2 cents.
> Jo
>
>
> ------------------------------
>
> Message: 17
> Date: Wed, 20 Jan 2016 09:49:31 +0100
> From: Sven Panne <svenpanne at gmail.com>
> To: Mikhail Glushenkov <mikhail.glushenkov at gmail.com>
> Cc: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
> "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] Doc generation?
> Message-ID:
> <CANBN=
> muhAXJaQQcTsbYGdsva-cTgC8si+U+-_Mjzt8Z3iJLZMA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2016-01-20 8:35 GMT+01:00 Mikhail Glushenkov <mikhail.glushenkov at gmail.com
> >:
>
> > You're welcome to open a ticket on the hackage-server bug tracker.
> >
>
> I've reported this several times through several channels, not sure if yet
> another report will have an impact. Here a quick summary of
> doc-generation-related issues:
>
> https://github.com/haskell/hackage-server/issues/464
> https://github.com/haskell/hackage-server/issues/463
> https://github.com/haskell/hackage-server/issues/421
> https://github.com/haskell/hackage-server/issues/420
> https://github.com/haskell/hackage-server/issues/368
> https://github.com/haskell/hackage-server/issues/244
> https://github.com/haskell/hackage-server/issues/183
> https://github.com/haskell/hackage-server/issues/145
> https://github.com/haskell/hackage-server/issues/55
>
> >From a packager maintainer POV, it's totally unpredictable if/when
> documentation gets built, see e.g.
> http://hackage.haskell.org/package/GLURaw-2.0.0.1: Currently there are no
> docs, while the previous version had docs, and the only change was relaxing
> the upper bound of OpenGLRaw (
> https://github.com/haskell-opengl/GLURaw/compare/v2.0.0.0...v2.0.0.1).
> Basically I gave up any hope and rely on stackage and/or local docs... :-(
>
> Cheers,
> S.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/505370f1/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
> ------------------------------
>
> End of Haskell-Cafe Digest, Vol 149, Issue 18
> *********************************************
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/1b7073b9/attachment-0001.html>
More information about the Haskell-Cafe
mailing list