Re: Recompile with -fPIC (was building a patched ghc)
You've got an object file compiled with 32-bit code, hence the relocation error. fPIC won't help you much (the linker error isn't helpful.) It's a matter of sifting through the make output to find the file or files that aren't compiled in 64-bit mode. Sent from my Verizon Wireless BlackBerry -Original Message- From: José Pedro Magalhães j...@cs.uu.nl Sender: glasgow-haskell-users-boun...@haskell.org Date: Fri, 18 Feb 2011 11:34:03 To: GHC usersglasgow-haskell-users@haskell.org Cc: braverdelivera...@gmail.com Subject: Recompile with -fPIC (was building a patched ghc) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release/git plans
Llvm is also a good reference for compiler plugin design; it would appear that Scala borrowed from their approach. -scooter Sent from my Verizon Wireless BlackBerry -Original Message- From: austin seipp a...@hacks.yi.org Sender: glasgow-haskell-users-boun...@haskell.org Date: Fri, 21 Jan 2011 17:59:32 To: Simon Peyton-Jonessimo...@microsoft.com Cc: Simon Marlowmarlo...@gmail.com; glasgow-haskell-users@haskell.orgglasgow-haskell-users@haskell.org Subject: Re: Release/git plans Simon, On Fri, Jan 21, 2011 at 3:13 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Austin | So, given that 7.2 will be released much earlier than the normal | release cycle, is there any room for anything else to get into HEAD | for the 7.2 release before everything is switched? In particular I | fixed up Max Bolingbroke's old compiler plugin work to be usable with | the latest HEAD, and all the fundamental work is there and done, just | some additional small things are needed (notably having ghc dump | plugin information a la -ddump flags, and testsuite patches are about | it I think.) The patch itself is pretty small and doesn't touch *too* | much code, mostly adding dynamic loading and the plugin API, but it's | arguably adding a 'big' feature for users of GHC to start utilizing, | and perhaps a release in 7.2 would cause problems merging changes | until you cut a new STABLE branch with git, like you said. I'm sorry I've been slow on this. Review and apply the plugins patch is in my inbox, but it's been queued up behind too many other things, notably making the new typechecker work. That's fine! One thing at a time. The typechecker overhaul is great IMO, and I've noticed it's fixed many strange GHC bugs relating to type system feature interactions (including a few I hit.) Much appreciated work! I'm pretty keen on the whole plugin idea, because it makes the compiler more extensible and lowers the barrier to entry. My only reason for delay is that I wanted to review the design (as seen by a plug-in author). Once we provide it, we have to support it, and it's harder to change. This is very reasonable and I was going to mention it once someone responded. Up to this point, Max has really been the main person to write any plugins for GHC using the current interface. I would really welcome anybody interested in hacking on GHC look at the current API in the patch - my main concern up to this point is that the actual means of installing passes into the Core pipeline, the installation function of type `[CoreToDo] - CoreM [CoreToDo]`, is a little fragile. Scala's approach seems to be to have plugins specify 'runAfter' and 'runBefore' constraints, which specify what compiler phases should run before and after the plugin's pass in question (and certain phases may run multiple times, so as a consequence, so does your plugin.) If I remember correctly, this was somewhat similar to the original design Max proposed which was to specify in which phase the pass is run, and it essentially amounted to a phase constraint. Perhaps Max can elaborate on why this design was rejected in favor of the current one, so we can see how and where it falls down, and what we really want. Thomas pointed out the Scala compiler plugin design document, so I'll be sure to read over it this weekend when I get the chance to cook up ideas. Also worth noting, like I said, is I would inevitably like to extend compiler plugins to work on Cmm, once the new codegen (using hoopl) hits. Maybe even allow you to write a new backend ultimately if you wanted to, although I'd call that the last and ultimate challenge at this point (because from my cursory glances, it would require quite a bit of re-engineering and re-design of the driver and compilation pipeline, much more so than just the Core plugins did or Cmm plugins might. That's a bit more time than I have... at the moment ;) To accumulate ideas and comments I've spent the past few days writing up a wiki page (mostly written in the wee hours of the morning no less), documenting the current API, how it might be improved, and future work like C-- plugins or plugins implementing new backends. Most of it is half baked. And half-written. Probably grammatical errors and run-on sentences. Incomplete sections. Likely with big, stupid ideas. Caveat emptor, etc. The wiki page in all its (horrid, half-written and mangled) glory can be located here: http://hackage.haskell.org/trac/ghc/wiki/NewPlugins If people can comment and add ideas, it will be much easier to determine if this should go into 7.2.1. If the current API is too fragile or needs to be expanded, it would likely be best to back out and do some work, and try again for 7.4.1. That will also give a much bigger window for feedback and testing, since 7.2 will be on a much shorter cycle it seems. I'll probably end up throwing up a RFC on both glasgow-haskell-users and cvs-ghc sometime in the next week to get feedback after
Re: RFC: migrating to git
I'm not sure if your statement regarding the decoupling between contributors and VCSes holds water. The VCS is definitely a factor, but certainly not the only one. I've been demotivated by VCSes before and it has directly impacted whether I continued my involvement. Granted that the VCS was SCCS, but still... Sample size of one, not the basis for a system of government and statements regarding watery bints lying in ponds apply. -scooter Sent from my Verizon Wireless BlackBerry -Original Message- From: Manuel M T Chakravarty c...@cse.unsw.edu.au Sender: glasgow-haskell-users-boun...@haskell.org Date: Tue, 11 Jan 2011 15:01:43 To: GHCcvs-...@haskell.org; GHC Listglasgow-haskell-users@haskell.org Cc: Simon Marlowmarlo...@gmail.com Subject: Re: RFC: migrating to git I agree with Roman's position. I would prefer to stay with darcs (it has its advantages and disadvantages, but has definitely been improving much in the past). In any case, all of GHC including all dependencies must be available and patchable with a *single* VCS. Mixing VCS' will lead to madness. Manuel PS: This talk about contributing to a project if it changes its VCS seems a bit lame to me. You contribute to a project in a serious way because you care about the project and because you need whatever improvements you are implementing, not because you like the VCS. Roman Leshchinskiy: On 10/01/2011, at 13:27, Simon Marlow wrote: On 10/01/2011 13:02, Max Bolingbroke wrote: However, I remember the last time this came up there were some issues that might make migration painful. From the top of my head: 1) Some people expressed concern that they would have to use two revision control systems to work on GHC, because not all GHC dependencies would be git-based. It would be a prerequisite to switching that a GHC developer only has to use one VCS. So we either migrate dependencies to git, or mirror them in GHC-specific git branches. I'm not sure how that is going to work. It might well be possible to build GHC using only git. But most GHC developers also contribute to various libraries which are often quite intimately linked to GHC. In particular, GHC patches are often accompanied by library patches. Unless all those libraries switch to git, too, we'll have to use both git and darcs which would be *really* annoying. Personally, I rather dislike git, mostly for the reasons that Malcolm already mentioned. Compared to darcs, it seems to get in the way much too often. It also seems to make finding buggy patches rather hard. But maybe I just don't know how to use it properly. In any case, a switch to git wouldn't deter me from contributing to GHC, but neither would a switch to any other VCS. I would certainly swear more often while developing, though. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Implementation of Scalable Event Handling for GHC
Depends on what your kernel supports. But that's just infrastructure, so (theoretically) it should just be invisible to the Haskell runtime user. Surprised that the RT wasn't using the more advanced interfaces. Web servers have been using them for years; that's why they exist. Sent from my Verizon Wireless BlackBerry -Original Message- From: tsuraan tsur...@gmail.com Sender: glasgow-haskell-users-boun...@haskell.org Date: Mon, 22 Nov 2010 22:42:27 To: Don Stewartd...@galois.com Cc: glasgow-haskell-users@haskell.org Subject: Re: Implementation of Scalable Event Handling for GHC It was integrated in GHC 7, released earlier this month. http://article.gmane.org/gmane.comp.lang.haskell.general/18297 On POSIX platforms, there is a new I/O manager based on epoll/kqueue/poll, which allows multithreaded I/O code to scale to a much larger number (100k+) of threads -- Don Ok, thanks! Are there any caveats to know about, or any documentation on the new manager? Is it safe to assume that so long as I'm using the standard threading and network/io libraries, I'll be using it correctly? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using the GHC API: pretty printing with qualified names
Claus: Respectfully, No duh! as schoolkids here in the US like to say when someone points out the obvious to them. And impossible is the right word since the predicate evaluates to a boolean. Since false is the outcome, impossible refers correctly to the status of fetching the documentation. Yes, we've been looking at the GHC sources. Why else would the question be posed with regard to is there a better way of doing this? Personally, I've had my fun re-implementing cabal package reading, and recreating someone else's work is counterproductive. -scooter Sent from my Verizon Wireless BlackBerry -Original Message- From: Claus Reinke claus.rei...@talk21.com Date: Thu, 18 Nov 2010 10:53:05 To: scooter@gmail.com; glasgow-haskell-users@haskell.org Subject: Re: Using the GHC API: pretty printing with qualified names scion-server mimics a GHCi command line, of sorts. scion-server is used very successfully to syntax-highlight the Eclipse editor, show a source's outline, provide type information when hovering over a name, and provide completions. That's not the problem, per se. Let's say I'm hovering over a function that's imported by Data.Map. When resolved, the symbols appear to come from Ghc.Map (if memory serves correctly), which makes finding the correct haddock impossible. Impossible is such an ugly word;-) The problem you encounter is that the GHC API is still, to a large part, just an open window into what happens to be in GHC. Since GHC's aims as a compiler differ from those of IDEs, its exposed functionality will sometimes be too limited to serve your purposes (eg, if GHC knows where a function is defined, it doesn't need to know how it was imported, once it gets past error reporting). If you tie yourself too closely to GHC's view, some things you'd like to do in an IDE will _appear_ to be impossible. That is why I recommend looking into the GHCi sources, because GHCi's needs are closer to those of an IDE. I assume you mean things like Data.List.map being a re-exported GHC.List.map being a re-exported GHC.Base.map, and :info not knowing about the intended abstractions: Prelude :i map map :: (a - b) - [a] - [b] -- Defined in GHC.Base You can actually get information about possible import paths via :browse! Prelude :m +Data.List Prelude Data.List :grep map|imported :browse! -- imported via Data.List mapAccumL :: (acc - x - (acc, y)) - acc - [x] - (acc, [y]) mapAccumR :: (acc - x - (acc, y)) - acc - [x] - (acc, [y]) -- imported via Data.List, Prelude map :: (a - b) - [a] - [b] (:browse! is standard GHCi, :grep is non-standard, just to filter :browse! output). So the :browse! command seems to be able to find more of the information you want. haskellmode for Vim, on the other hand, has long provided haddock lookup, and will offer you a menu of possible destinations when your cursor is over 'map'. This menu is built from an index of Haddock entries, which is extracted from installed Haddock documentation. Nothing impossible about that, just ugly: so far, the index is scraped from Haddock's HTML index files. That route breaks occasionally (recent Haddock HTML changes, ghc-pkg listing wrong Haddock paths, ..; I'm about to publish updated scraping code for GHC-7.0.1's Haddock..). To get something less ugly, I'm currently recoding the extraction by using Haddock's API and .haddock files (that'll still break when the API changes, also there is a pending bug about ghc-pkg, cabal, and haddock disagreeing about filepath formats, meaning that .haddock files aren't found on Windows). I assume that code will be useful to other Haskell IDEs, though it is mostly exposing Haddock's internal ability to build an index from .haddock files, which I'd like to see exposed in Haddock's less-than-well-known API: http://trac.haskell.org/haddock/ticket/157 Claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using the GHC API: pretty printing with qualified names
Claus: scion-server mimics a GHCi command line, of sorts. scion-server is used very successfully to syntax-highlight the Eclipse editor, show a source's outline, provide type information when hovering over a name, and provide completions. That's not the problem, per se. Let's say I'm hovering over a function that's imported by Data.Map. When resolved, the symbols appear to come from Ghc.Map (if memory serves correctly), which makes finding the correct haddock impossible. -scooter Sent from my Verizon Wireless BlackBerry -Original Message- From: Claus Reinke claus.rei...@talk21.com Sender: glasgow-haskell-users-boun...@haskell.org Date: Wed, 17 Nov 2010 23:25:29 To: JP Moresmaujpmores...@gmail.com; glasgow-haskell-users@haskell.org Subject: Re: Using the GHC API: pretty printing with qualified names Hello, I'm the maintainer for EclipseFP, which involves using the scion library and the GHC API to provide IDE functionality. I have a little issue that no doubt stems from me not understanding the GHC API well, and I would be grateful for any light on the matter. A meta-comment: the GHC API is much easier to grasp if you have a client at hand. In the case of IDE-like tools, my recommendation would be to look at the GHCi source - there is a wide range of overlap between what makes sense for GHCi and what makes sense for an IDE (think of GHCi as a commandline IDE;-). For your particular question: GHCi provides :info, which does manage to get (rough) source info for plain unqualified names, within a session context. So, starting from the source of the :info implementation might give you some hints (the command itself also helps you to find the GHC API source in question). Prelude :set -package ghc Prelude :info GHC.getName class Name.NamedThing a where ... Name.getName :: a - Name.Name -- Defined in Name Prelude :info Monad class Monad m where (=) :: m a - (a - m b) - m b () :: m a - m b - m b return :: a - m a fail :: String - m a -- Defined in GHC.Base instance Monad Maybe -- Defined in Data.Maybe instance Monad [] -- Defined in GHC.Base instance Monad IO -- Defined in GHC.Base Prelude :info mapM mapM :: Monad m = (a - m b) - [a] - m [b] -- Defined in Control.Monad Of course, those sources and GHCi commands aren't perfect (some of the code might still pre-date the API), and batch-processing an AST is different from an interactive read-eval-print loop, but some of the API was abstracted from GHCi and GHCi always needs to build with the current API version. Another side note: as you can see from the examples, you may not always have any source code to point to, in a typical GHC installation. That is why haskellmode for Vim links to the haddocks for those ids (somewhat oddly, the haddocks might come with HTML-ified sources, even when the original source is not installed..). Hope this helps, Claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1
This is indicative of a 32-bit object being linked into the shared library, FWIW. Sent from my Verizon Wireless BlackBerry -Original Message- From: Vivian McPhail haskell.vivian.mcph...@gmail.com Sender: glasgow-haskell-users-boun...@haskell.org Date: Wed, 29 Sep 2010 19:25:10 To: glasgow-haskell-users@haskell.org Subject: Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: __emutls_get_address link problem
Christian: Is it possible that you might have code compiled with an older version of ghc lying around in an odd place in your build hierarchy? I would imagine that you upgraded cabal-installed packages. If for some reason you copied or used rsync to replicate a directory tree onto the older machine, then that would explain why you are seeing these difficulties. -scooter Sent from my Verizon Wireless BlackBerry -Original Message- From: Simon Marlow marlo...@gmail.com Sender: glasgow-haskell-users-boun...@haskell.org Date: Wed, 25 Aug 2010 16:39:43 To: Christian Maederchristian.mae...@dfki.de Cc: glasgow-haskell-users@haskell.org Subject: Re: __emutls_get_address link problem On 25/08/2010 16:37, Christian Maeder wrote: Christian Maeder schrieb: Simon Marlow schrieb: On 23/08/2010 17:45, Brandon S Allbery KF8NH wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/23/10 11:57 , Christian Maeder wrote: However, when I try to compile the simplest source with on older gcc-3.4.4 I get the link error below, but only for the threaded rts! With ghc-6.12.1 and gcc-4.x.y (x 3) I did not have such a problem when switching to a machine that only has gcc-3.4.4. You got lucky; mixing GCC major versions like that is not expected (much less guaranteed) to work in general. GCC evidently changed the way it implements some thread support routines between gcc3 and gcc4. Why should it not be possible to create object files (like also dynamic libs) with (very) different compilers? This is a case where the ABI changed between versions of gcc (I presume). It rarely happens with C code, but happens more often with C++, and, of course, in GHC we change the ABI with every single release so you should be used to this by now :-) In particular, thread-local variables, which are used by the parallel GC. I'm just testing if I get runtime problems, but the linking error goes away, if I put libgcc_eh.a from gcc-4.3.3 into ghc's libdir. The hack seems to work, although it looks dangerous regarding other symbols from libgcc_eh.a that should be in sync with the used gcc-3.4.4. I wouldn't trust it. Why do you need to mix code compiled by two different gcc versions? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using associated data types to create unpacked data structures
C++ template instantiations are exported as weak linker symbols. It's just that the linker elides all of the implementations. Sent from my Verizon Wireless BlackBerry -Original Message- From: Johan Tibell johan.tib...@gmail.com Sender: glasgow-haskell-users-boun...@haskell.org Date: Thu, 12 Aug 2010 13:28:25 To: Simon Marlowmarlo...@gmail.com Cc: glasgow-haskell-usersglasgow-haskell-users@haskell.org Subject: Re: Using associated data types to create unpacked data structures ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: What does interruptibility mean exactly?
It seems to me that the documentation could be further refined: An acquisition operation cannot be interrupted when the requested resource is available; the resource is successfully acquired and the subsequent computation can proceed. On the other hand, if the resource is unavailable, then the acquisition operation is in a blocked state and can be interrupted. I'm not sure that this is the exact phrasing, but it does convey the meaning a bit more clearly. Also missing is that interruptable implies restartable. Sent from my Verizon Wireless BlackBerry -Original Message- From: Bas van Dijk v.dijk@gmail.com Date: Tue, 15 Jun 2010 20:36:44 To: Simon Marlowmarlo...@gmail.com Cc: glasgow-haskell-users@haskell.org; Don Stewartd...@galois.com Subject: Re: What does interruptibility mean exactly? On Tue, Jun 15, 2010 at 12:41 PM, Simon Marlow marlo...@gmail.com wrote: On 15/06/2010 09:00, Bas van Dijk wrote: On Mon, Jun 14, 2010 at 11:20 PM, Don Stewartd...@galois.com wrote: v.dijk.bas: Hello, I've a short question about interruptible operations. In the following program is it possible for 'putMVar' to re-throw asynchronous exceptions even when asynchronous exception are blocked/masked? newEmptyMVar= \mv - block $ putMVar mv x The documentation in Control.Exception about interruptible operations[1] confused me: Some operations are interruptible, which means that they can receive asynchronous exceptions even in the scope of a block. Any function which may itself block is defined as interruptible... I think the best definition of interruptible is in this paper: www.haskell.org/~simonmar/papers/async.pdf Section 5.3 Thanks for the link Don! Next time I will re-read the paper before asking ;-) The definition makes it clear indeed: Any operation which may need to wait indefinitely for a resource (e.g., takeMVar) may receive asynchronous exceptions even within an enclosing block, BUT ONLY WHILE THE RESOURCE IS UNAVAILABLE So I guess I can update my threads package to use MVars again. Nice! because they were a bit faster in an informal benchmark I performed some time ago. This is currently true for takeMVar/putMVar but it is no longer true for throwTo (in 6.14+). I'll update the docs to make that clear. The reason is that throwTo now works by message passing when the target is on another CPU, and we consider a thread that is waiting for a response to a message to be blocked - even if the throwTo can in fact proceed immediately because the target is interruptible. Thanks for the heads-up. BTW I just released threads-0.3 which, among other things, uses MVars again for waiting for the termination of a thread: http://hackage.haskell.org/package/threads-0.3 Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Removing/deprecating -fvia-c
It seems to me, in the absence of any other fallback, that the C backend should stay around. Assume that one is porting to a new platform, the C backend at least gives one code from which to bootstrap. Calling convention handling: weak argument IMHO for ditching. Sounds like refactoring is required, and, yes, it's platform-specific. Perl script postprocessing foo: I haven't looked at the code, but again, it sounds like platform-specific refactoring. Yes, I've looked at the web page. There's a reason why backends are messy goo and have target triples, etc. It's like Monad: not everything is pure. My vote is to keep the C backend. If it's good enough for LLVM, it's probably good enough for GHC. -scooter --Original Message-- From: Don Stewart Sender: glasgow-haskell-users-boun...@haskell.org To: glasgow-haskell-users@haskell.org Subject: Re: Removing/deprecating -fvia-c Sent: Feb 14, 2010 09:58 igloo: Hi all, We are planning to remove the -fvia-c way of compiling code (unregisterised compilers will continue to compile via C only, but registerised compilers will only use the native code generator). We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in 6.16. Simon Marlow has recently fixed FP performance for modern x86 chips in the native code generator in the HEAD. That was the last reason we know of to prefer via-C to the native code generators. But before we start the removal process, does anyone know of any other problems with the native code generators that need to be fixed first? Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? As recently as last year -fvia-C -optc-O3 was still useful for some microbenchmarks -- what's changed in that time, or is expected to change? -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Sent from my Verizon Wireless BlackBerry___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Removing/deprecating -fvia-c
Before the Pile on Scooter fest starts, bear in mind that LLVM effectively restricts you to its current backends. As the guy who started CellSPU in LLVM and who needs a good couple of research months off to finish it, think this through. Carefully. FWIW: I lead a computer systems research department for a non-for-profit in real life. Sent from my Verizon Wireless BlackBerry -Original Message- From: scooter@gmail.com Date: Wed, 17 Feb 2010 03:26:08 To: Don Stewartd...@galois.com; glasgow-haskell-users@haskell.org Subject: Re: Removing/deprecating -fvia-c It seems to me, in the absence of any other fallback, that the C backend should stay around. Assume that one is porting to a new platform, the C backend at least gives one code from which to bootstrap. Calling convention handling: weak argument IMHO for ditching. Sounds like refactoring is required, and, yes, it's platform-specific. Perl script postprocessing foo: I haven't looked at the code, but again, it sounds like platform-specific refactoring. Yes, I've looked at the web page. There's a reason why backends are messy goo and have target triples, etc. It's like Monad: not everything is pure. My vote is to keep the C backend. If it's good enough for LLVM, it's probably good enough for GHC. -scooter --Original Message-- From: Don Stewart Sender: glasgow-haskell-users-boun...@haskell.org To: glasgow-haskell-users@haskell.org Subject: Re: Removing/deprecating -fvia-c Sent: Feb 14, 2010 09:58 igloo: Hi all, We are planning to remove the -fvia-c way of compiling code (unregisterised compilers will continue to compile via C only, but registerised compilers will only use the native code generator). We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in 6.16. Simon Marlow has recently fixed FP performance for modern x86 chips in the native code generator in the HEAD. That was the last reason we know of to prefer via-C to the native code generators. But before we start the removal process, does anyone know of any other problems with the native code generators that need to be fixed first? Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? As recently as last year -fvia-C -optc-O3 was still useful for some microbenchmarks -- what's changed in that time, or is expected to change? -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Sent from my Verizon Wireless BlackBerry___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: DPH and CUDA status
I'm personally pessimistic about the STI Cell, but it's a reasonable example wrt the difficulty of writing the backends. Barring the data and message orchestration, which also aflicts GPUs, there's the decision function as to when to migrate a computation to the accelerator (GPU, SPU, ...) Not so much of a problem in chip symmetric mcore, but gets pretty dicey for hybrid mcore. Been trying to wrap my head around that problem for a couple of years. -scooter Sent from my Verizon Wireless BlackBerry -Original Message- From: Jeff Heard j...@renci.org Date: Wed, 3 Feb 2010 14:06:02 To: Brad Larsenbrad.lar...@gmail.com Cc: GHC Usersglasgow-haskell-users@haskell.org Subject: Re: DPH and CUDA status You're quite correct. I should say supplant for normal uses. The OpenCL drivers are built on top of CUDA, and they intend CUDA to continue to be available, but OpenCL is more portable and thus something that we should probably target at some point. On Wed, Feb 3, 2010 at 1:54 PM, Brad Larsen brad.lar...@gmail.com wrote: On Wed, Feb 3, 2010 at 12:34 PM, Jeff Heard j...@renci.org wrote: [...] One thing though, is that CUDA is being supplanted by OpenCL in the next few years, and OpenCL can handle data parallelism on multicore CPUs as well as GPUs with the same code. It's a little more flexible overall than CUDA, and will be portable across ATI/nVidia/Intell/AMD/Sony Cell in the end, and is well supported on Linux, Mac, and Windows systems. [...] I have been told by NVIDIA folks that CUDA is not going to disappear. Its C++ API (as opposed to its ``driver interface'') is quite a bit higher level than OpenCL, suitable for (painful) application development, whereas OpenCL seems more targeted for compiler and framework writers. Sincerely, Brad ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling to ANSI C
Do we have a native LLVM bitcode writer or is it still FFI? --Original Message-- From: Thomas DuBuisson Sender: glasgow-haskell-users-boun...@haskell.org To: han Cc: glasgow-haskell-users@haskell.org Subject: Re: Compiling to ANSI C Sent: Nov 7, 2009 09:56 If I were you, I'd look at using the recent LLVM backend work as a means to translate Haskell - ARM. Thomas On Sat, Nov 7, 2009 at 9:08 AM, han e...@xtendo.org wrote: I am (in fact we are) working to make Haskell code to run on an ARM Linux machine called GP2X Wiz, the open-source based handheld game console. I wish to finally make a Haskell cross-compiler for ARM Linux, and for now I am trying to make main = putStrLn Hello, World! to run on the machine. At first I did $ ghc hello.hs -o hello -fvia-C -keep-hc-files and tried to use the generated hc file, but figured that the code is (or at least some code in the included headers is) x86-dependent. I heard that the GHC can compile to ANSI C, and I want to use it as an intermediate code to ARM Linux before we can actually port the GHC to it. Is there any specific option I have to give in order to generate an ANSI C code from a Haskell source code? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Sent from my Verizon Wireless BlackBerry___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling to ANSI C
Believe it when it shows up in GHC pristine. --Original Message-- From: Thomas DuBuisson To: scooter@gmail.com Cc: han Cc: glasgow-haskell-users@haskell.org Subject: Re: Compiling to ANSI C Sent: Nov 7, 2009 11:28 On Sat, Nov 7, 2009 at 11:16 AM, scooter@gmail.com wrote: Do we have a native LLVM bitcode writer or is it still FFI? I was referring to a paper [1] I just ran into on reddit. I only skimmed it, but it seems they (or just he?) integrated LLVM as a new backend for GHC. Thomas [1] http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf Sent from my Verizon Wireless BlackBerry ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Update on GHC 6.12.1
Is there a good motivating example for recursive do? So far, I haven't grokked the various use cases, which are pretty terse. Maybe the syntax sugar gets in the way (dangling lets are a good case in point). It's a bit like grokking a Monad: it's the way to alter state, through a chain of binds, culminating in a return, where values can't escape outside the Monad itself. Using IO as the example w/the (hidden) realworld parameter makes the explanation more opaque than it need be. -scooter Sent from my Verizon Wireless BlackBerry -Original Message- From: Greg Fitzgerald gari...@gmail.com Date: Thu, 29 Oct 2009 10:24:23 To: Simon Peyton-Jonessimo...@microsoft.com Cc: GHC usersglasgow-haskell-users@haskell.org Subject: Re: Update on GHC 6.12.1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
