Hi all, only want to add a small note: there was (is?) a ghc fork targeting the jvm where i had the luck to been able to contribute my two cents: eta-lang (https://github.com/typelead/eta) Unfortunately the startup behind it lost funds and it is stalled but i still have the hope some day can be resurrected.
Javi Neira El vie., 26 mar. 2021 10:42, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> escribió: > This link gives some (old) background > > > https://wiki.haskell.org/GHC/FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F > > Simon > > > > *From:* ghc-devs <ghc-devs-boun...@haskell.org> *On Behalf Of *Moritz > Angermann > *Sent:* 26 March 2021 08:00 > *To:* Clinton Mead <clintonm...@gmail.com> > *Cc:* ghc-devs <ghc-devs@haskell.org> > *Subject:* Re: Options for targeting Windows XP? > > > > I believe there is a bit of misconception about what requires a new > backend or not. GHC is a bunch of different intermediate representations > from which one can take off to build backends. The STG, or Cmm ones are the > most popular. All our Native Code Generators and the LLVM code gen take off > from the Cmm one. Whether or not that is the correct input representation > for your target largely depends on the target and design of the > codegenerator. GHCJS takes off from STG, and so does Csaba's GRIN work via > the external STG I believe. IIRC Asterius takes off from Cmm. I don't > remember the details about Eta. > > > > Why fork? Do you want to deal with GHC, and GHC's development? If not, > fork. Do you want to have to keep up with GHC's development? Maybe not > fork. Do you think your compiler can stand on it's own and doesn't follow > GHC much, except for being a haskell compiler? By all means fork. > > > > Eta is a bit special here, Eta forked off, and basically started > customising their Haskell compiler specifically to the JVM, and this also > allowed them to make radical changes to GHC, which would not have been > permissible in the mainline GHC. (Mainline GHC tries to support multiple > platforms and architectures at all times, breaking any of them isn't really > an option that can be taken lightheartedly.) Eta also started having Etlas, > a custom Cabal, ... I'd still like to see a lot from Eta and the ecosystem > be re-integrated into GHC. There have to be good ideas there that can be > brought back. It just needs someone to go look and do the work. > > > > GHCJS is being aligned more with GHC right now precisely to eventually > re-integrate it with GHC. > > > > Asterius went down the same path, likely inspired by GHCJS, but I think I > was able to convince the author that eventual upstreaming should be the > goal and the project should try to stay as close as possible to GHC for > that reason. > > > > Now if you consider adding a codegen backend, this can be done, but again > depends on your exact target. I'd love to see a CLR target, yet I don't > know enough about CLR to give informed suggestions here. > > > > If you have a toolchain that functions sufficiently similar to a stock c > toolchain, (or you can make your toolchain look sufficiently similar to > one, easily), most of it will just work. If you can separate your building > into compilation of source to some form of object code, and some form of > object code aggregates (archives), and some form of linking (objects and > archives into shared objects, or executables), you can likely plug in your > toolchain into GHC (and Cabal), and have it work, once you taught GHC how > to produce your target languages object code. > > > > If your toolchain does stuff differently, a bit more work is involved in > teaching GHC (and Cabal) about that. > > > > This all only gives you *haskell* though. You still need the Runtime > System. If you have a C -> Target compiler, you can try to re-use GHC's > RTS. This is what the WebGHC project did. They re-used GHC's RTS, and > implemented a shim for linux syscalls, so that they can emulate enough to > have the RTS think it's running on some musl like linux. You most likely > want something proper here eventually; but this might be a first stab at it > to get something working. > > > > Next you'll have to deal with c-bits. Haskell Packages that link against C > parts. This is going to be challenging, not impossible but challenging as > much of the haskell ecosystem expects the ability to compile C files and > use those for low level system interaction. > > > > You can use hackage overlays to build a set of patched packages, once you > have your codegen working. At that point you could start patching ecosystem > packages to work on your target, until your changes are upstreamed, and > provide your user with a hackage overlay (essentially hackage + patches for > specific packages). > > > > Hope this helps. > > > > You'll find most of us on irc.freenode.net#ghc > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Firc.freenode.net%2F%23ghc&data=04%7C01%7Csimonpj%40microsoft.com%7C3f53d0ae48044e3e077f08d8f02d481b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637523424594442431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VSkq2OreVK2qUHm02VAaTVsIXCqQ5eojNheKg4y4Rqw%3D&reserved=0> > > > > On Fri, Mar 26, 2021 at 1:29 PM Clinton Mead <clintonm...@gmail.com> > wrote: > > Thanks again for the detailed reply Ben. > > > > I guess the other dream of mine is to give GHC a .NET backend. For my > problem it would be the ideal solution, but it looks like other attempts in > this regard (e.g. Eta, GHCJS etc) seem to have difficulty keeping up with > updates to GHC. So I'm sure it's not trivial. > > > > It would be quite lovely though if I could generate .NET + Java + even > Python bytecode from GHC. > > > > Whilst not solving my immediate problem, perhaps my efforts are best spent > in giving GHC a plugin architecture for backends (or if one already > exists?) trying to make a .NET backend. > > > > I believe "Csaba Hruska" is working in this space with GRIN, yes? > > > > I read SPJs paper on Implementing Lazy Functional Languages on Stock > Hardware: The Spineless Tagless G-machine > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fresearch%2Fpublication%2Fimplementing-lazy-functional-languages-on-stock-hardware-the-spineless-tagless-g-machine%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C3f53d0ae48044e3e077f08d8f02d481b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637523424594452424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=07%2FrhWMwf8i%2F%2Bj0XJS9T4riHifILuxV0739ck9KQTYw%3D&reserved=0> > which > implemented STG in C and whilst it wasn't trivial, it didn't seem > stupendously complex (even I managed to roughly follow it). I thought to > myself also, implementing this in .NET would be even easier because I can > hand off garbage collection to the .NET runtime so there's one less thing > to worry about. I also, initially, don't care _too_ much about performance. > > > > Of course, there's probably a whole bunch of nuance. One actually needs > to, for example, represent all the complexities of GADTs into object > orientated classes, maybe converting sum types to inheritance hierarchies > with Visitor Patterns. And also you'd actually have to make sure to do > one's best to ensure exposed Haskell functions look like something > sensible. > > So I guess, given I have a bit of an interest here, what would be the best > approach if I wanted to help GHC develop more backends and into an > architecture where people can add backends without forking GHC? Where could > I start helping that effort? Should I contact "Csaba Hruska" and get > involved in GRIN? Or is there something that I can start working on in GHC > proper? > > Considering that I've been playing around with Haskell since 2002, and I'd > like to actually get paid to write it at some point in my career, and I > have an interest in this area, perhaps this is a good place to start, and > actually helping to develop a pluggable backend architecture for GHC may be > more useful for more people over the long term than trying to hack up an > existing GHC to support 32 bit Windows XP, a battle I suspect will have to > be refought every time a new GHC version is released given the current > structure of GHC. > > > > On Fri, Mar 26, 2021 at 1:34 PM Ben Gamari <b...@well-typed.com> wrote: > > Clinton Mead <clintonm...@gmail.com> writes: > > > Thanks all for your replies. Just going through what Ben has said step by > > step: > > > > My sense is that if you don't need the threaded runtime system it would > >> probably be easiest to just try to make a modern GHC run on Windows XP. > >> > > > > Happy to run non-threaded runtime. A good chunk of these machines will be > > single or dual core anyway. > > > That indeed somewhat simplifies things. > > >> As Tamar suggested, it likely not easy, but also not impossible. WinIO > >> is indeed problematic, but thankfully the old MIO IO manager is still > >> around (and will be in 9.2). > >> > > > > "Is still around"? As in it's in the code base and just dead code, or > can I > > trigger GHC to use the old IO manager with a GHC option? > > > > The possible reasons for Windows XP incompatibility that I can think of > >> off the top of my head are: > >> > >> * Timers (we now use QueryPerformanceCounter) > >> > > > > This page suggests that QueryPerformanceCounter > > < > https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fapi%2Fprofileapi%2Fnf-profileapi-queryperformancecounter&data=04%7C01%7Csimonpj%40microsoft.com%7C3f53d0ae48044e3e077f08d8f02d481b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637523424594452424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6P7AGhMYO9VHTzTOAtaYIdv2C4U63SXn%2BjPzQk8efGk%3D&reserved=0> > > > > should > > run on XP. Is this incorrect? > > > It's supported, but there are caveats [1] that make it unreliable as a > timesource. > > [1] > https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps#windowsxp-and-windows2000 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fsysinfo%2Facquiring-high-resolution-time-stamps%23windowsxp-and-windows2000&data=04%7C01%7Csimonpj%40microsoft.com%7C3f53d0ae48044e3e077f08d8f02d481b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637523424594462417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9Q7HyRzR%2F3OrbdsATvR9sQ87OlRH1%2BWP2F1eNy8%2Fp2o%3D&reserved=0> > > > >> * Big-PE support, which is very much necessary for profiled builds > >> > > > > I don't really need profiled builds > > > > Alright, then you *probably* won't be affected by PE's symbol limit. > > >> * Long file path support (mostly a build-time consideration as Haskell > >> build systems tend to produce very long paths) > >> > >> > > I don't need to build on Windows XP either. I just need to run on Windows > > XP so hopefully this won't be an issue. Although if GHC was modified for > > long file path support so it could build itself with long file path > support > > presumably it will affect everything else it builds also. > > > If you don't need to build on XP then I suspect this won't affect you. > > > > >> There may be others, but I would start looking there. I am happy to > >> answer any questions that might arise. > >> > > I'm guessing the way forward here might be a patch with two options: > > > > 1. -no-long-path-support/-long-path-support (default -long-path-support) > > 2. -winxp > > > > The winxp option shall: > > > > - Require -no-long-path-support > > - Conflicts with -threaded > > - Conflicts with profiled builds > > - Uses the old IO manager (I'm not sure if this is an option or how this > is > > done). > > > The old IO manager is still the default, although this will likely > change in 9.2. > > > What do you think (roughly speaking)? > > Yes, that is essentially correct. I would probably start by trying to > run a 32-bit GHC build on Windows XP under gdb and see where > things fall over. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=04%7C01%7Csimonpj%40microsoft.com%7C3f53d0ae48044e3e077f08d8f02d481b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637523424594472409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tmLfLI3ryyiyXOvnxHV4Lbm%2B3nePcbDNtVIl3djgS74%3D&reserved=0> > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
