Options for targeting Windows XP?

Clinton Mead

24 Mar 2021 24 Mar '21

10:08 a.m.

I'm currently trying to bring my company around to using a bit of Haskell. One issue is that a number of our clients are based in South East Asia and need software that runs on Windows XP. Unfortunately it seems the last version of GHC that produces executables that run on Windows XP is GHC 7.10. Whilst this table https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms/windows suggests the issue may only running GHC 8.0+ on Windows XP, I've confirmed that GHC 8.0 executables (even "Hello World") will not run on Windows XP, presumably because a non-XP WinAPI call in the runtime. My first thought would be to restrict myself to GHC 7.10 features (i.e. 2015). This would be a slight annoyance but GHC 7.10 still presents a reasonable language. But my concern would be that increasingly I'll run into issues with libraries that use extensions post GHC 7.10, particularly libraries with large dependency lists. So there's a few options I've considered at this point: 1. Use GHCJS to compile to Javascript, and then dig out a version of NodeJS that runs on Windows XP. GHCJS seems to at least have a compiler based on GHC 8.6. 2. Patch GHC with an additional command line argument to produce XP/Vista compatible executables, perhaps by looking at the changes between 7.10 -> 8.0, and re-introducing the XP approach as an option. The issue with 1 is that is that as well as being limited by how up to date GHCJS is, this will increase install size, memory usage and decrease performance on Windows XP machines, which are often in our environments quite old and resource and memory constrained. Approach 2 is something I'd be willing to put some work into if it was practical, but my thought is that XP support was removed for a reason, presumably by using newer WinAPI functions simplified things significantly. By re-adding in XP support I'd be complicating GHC once again, and GHC will effectively have to maintain two approaches. In addition, in the long term, whenever a new WinAPI call is added one would now have to check whether it's available in Windows XP, and if it's not produce a Windows XP equivalent. That might seem like just an extra burden of support for already busy GHC developers. But on the other hand, if the GHC devs would be happy to merge a patch and keep up XP support this would be the cleanest option. But then I had a thought. If GHC Core isn't supposed to change much between versions is it? Which made me come up with these approaches: 3. Hack up a script to compile programs using GHC 9 to Core, then feed that Core output into GHC 7.10. OR 4. Produce a chimera style GHC by importing the GHC 9.0 API and the GHC 7.10 API, and making a version of GHC that does Haskell -> Core in GHC 9.0 and the rest of the code generation in GHC 7.10. One issue with 4 will be that presumably that because I'm importing GHC 9.0 API and the 7.10 API separately, all their data types will technically be separate, so I'll need to basically deep copy the GHC 9.0 core datatype (and perhaps others) to GHC 7.10 datatypes. But presuming their largely similar this should be fairly mechanical. So are any of these approaches (well, particularly 2 and 4) reasonable? Or am I going to run into big problems with either of them? Is there another approach I haven't thought of? Thanks, Clinton

Attachments:

attachment.html (text/html — 3.6 KB)

Show replies by date

Carter Schonwald

24 Mar 24 Mar

1:49 p.m.

In terms of net amount of work: I suspect ghcjs targeting either node or some sort of browser plug-in may be the most humane assuming associated browser / node suport on xp is turn key. I think there were some genuine changes to the io manager (the Haskell code in base for doing efficient file system api stuff) on windows plus a few other things. There may have also been changes elsewhere that andreask and Tamar and ben gamari can speak to better. More broadly, there’s so many bug fixes and improvements that you’d miss out on if you don’t try to keep yourself current within the 3 most recent ghc major version releases wrt associated libraries. On Wed, Mar 24, 2021 at 10:09 AM Clinton Mead wrote:

...

I'm currently trying to bring my company around to using a bit of Haskell. One issue is that a number of our clients are based in South East Asia and need software that runs on Windows XP.

Unfortunately it seems the last version of GHC that produces executables that run on Windows XP is GHC 7.10. Whilst this table https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms/windows suggests the issue may only running GHC 8.0+ on Windows XP, I've confirmed that GHC 8.0 executables (even "Hello World") will not run on Windows XP, presumably because a non-XP WinAPI call in the runtime.

My first thought would be to restrict myself to GHC 7.10 features (i.e. 2015). This would be a slight annoyance but GHC 7.10 still presents a reasonable language. But my concern would be that increasingly I'll run into issues with libraries that use extensions post GHC 7.10, particularly libraries with large dependency lists.

So there's a few options I've considered at this point:

1. Use GHCJS to compile to Javascript, and then dig out a version of NodeJS that runs on Windows XP. GHCJS seems to at least have a compiler based on GHC 8.6. 2. Patch GHC with an additional command line argument to produce XP/Vista compatible executables, perhaps by looking at the changes between 7.10 -> 8.0, and re-introducing the XP approach as an option.

The issue with 1 is that is that as well as being limited by how up to date GHCJS is, this will increase install size, memory usage and decrease performance on Windows XP machines, which are often in our environments quite old and resource and memory constrained.

Approach 2 is something I'd be willing to put some work into if it was practical, but my thought is that XP support was removed for a reason, presumably by using newer WinAPI functions simplified things significantly. By re-adding in XP support I'd be complicating GHC once again, and GHC will effectively have to maintain two approaches. In addition, in the long term, whenever a new WinAPI call is added one would now have to check whether it's available in Windows XP, and if it's not produce a Windows XP equivalent. That might seem like just an extra burden of support for already busy GHC developers. But on the other hand, if the GHC devs would be happy to merge a patch and keep up XP support this would be the cleanest option.

But then I had a thought. If GHC Core isn't supposed to change much between versions is it? Which made me come up with these approaches:

3. Hack up a script to compile programs using GHC 9 to Core, then feed that Core output into GHC 7.10. OR 4. Produce a chimera style GHC by importing the GHC 9.0 API and the GHC 7.10 API, and making a version of GHC that does Haskell -> Core in GHC 9.0 and the rest of the code generation in GHC 7.10.

One issue with 4 will be that presumably that because I'm importing GHC 9.0 API and the 7.10 API separately, all their data types will technically be separate, so I'll need to basically deep copy the GHC 9.0 core datatype (and perhaps others) to GHC 7.10 datatypes. But presuming their largely similar this should be fairly mechanical.

So are any of these approaches (well, particularly 2 and 4) reasonable? Or am I going to run into big problems with either of them? Is there another approach I haven't thought of?

Thanks, Clinton _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Phyx

2:29 p.m.

Hi,

...

XP. GHCJS seems to at least have a compiler based on GHC 8.6. 2. Patch GHC with an additional command line argument to produce XP/Vista compatible executables, perhaps by looking at the changes between 7.10 -> 8.0, and re-introducing the XP approach as an option.

This would be somewhat hard but not impossible for 8.0.. Which If I recalled drop XP for some linker functionality. The higher you go the more difficult it would become though. When you get to 9.0 you don't have much hope as there it's not just the linker, but the RTS itself heavily relies on functionality not available in XP, including how we manage memory and do synchronization. It's however not just GHC that would need patching but libraries such as process as well. That is not to say it's impossible, just you'd have to find ways to work around the bugs that caused us to change APIs to begin with... I can't speak for the community, but I wouldn't want to re-introduce XP as a supported options in mainline. Parts of e.g. 9.0 (like winio) just won't work on XP. The design itself is centered around new APIs. So supporting XP means essentially a new design. Kind regards, Tamar Sent from my Mobile On Wed, Mar 24, 2021, 14:09 Clinton Mead wrote:

...

I'm currently trying to bring my company around to using a bit of Haskell. One issue is that a number of our clients are based in South East Asia and need software that runs on Windows XP.

Unfortunately it seems the last version of GHC that produces executables that run on Windows XP is GHC 7.10. Whilst this table https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms/windows suggests the issue may only running GHC 8.0+ on Windows XP, I've confirmed that GHC 8.0 executables (even "Hello World") will not run on Windows XP, presumably because a non-XP WinAPI call in the runtime.

My first thought would be to restrict myself to GHC 7.10 features (i.e. 2015). This would be a slight annoyance but GHC 7.10 still presents a reasonable language. But my concern would be that increasingly I'll run into issues with libraries that use extensions post GHC 7.10, particularly libraries with large dependency lists.

So there's a few options I've considered at this point:

1. Use GHCJS to compile to Javascript, and then dig out a version of NodeJS that runs on Windows XP. GHCJS seems to at least have a compiler based on GHC 8.6. 2. Patch GHC with an additional command line argument to produce XP/Vista compatible executables, perhaps by looking at the changes between 7.10 -> 8.0, and re-introducing the XP approach as an option.

The issue with 1 is that is that as well as being limited by how up to date GHCJS is, this will increase install size, memory usage and decrease performance on Windows XP machines, which are often in our environments quite old and resource and memory constrained.

Approach 2 is something I'd be willing to put some work into if it was practical, but my thought is that XP support was removed for a reason, presumably by using newer WinAPI functions simplified things significantly. By re-adding in XP support I'd be complicating GHC once again, and GHC will effectively have to maintain two approaches. In addition, in the long term, whenever a new WinAPI call is added one would now have to check whether it's available in Windows XP, and if it's not produce a Windows XP equivalent. That might seem like just an extra burden of support for already busy GHC developers. But on the other hand, if the GHC devs would be happy to merge a patch and keep up XP support this would be the cleanest option.

But then I had a thought. If GHC Core isn't supposed to change much between versions is it? Which made me come up with these approaches:

3. Hack up a script to compile programs using GHC 9 to Core, then feed that Core output into GHC 7.10. OR 4. Produce a chimera style GHC by importing the GHC 9.0 API and the GHC 7.10 API, and making a version of GHC that does Haskell -> Core in GHC 9.0 and the rest of the code generation in GHC 7.10.

One issue with 4 will be that presumably that because I'm importing GHC 9.0 API and the 7.10 API separately, all their data types will technically be separate, so I'll need to basically deep copy the GHC 9.0 core datatype (and perhaps others) to GHC 7.10 datatypes. But presuming their largely similar this should be fairly mechanical.

So are any of these approaches (well, particularly 2 and 4) reasonable? Or am I going to run into big problems with either of them? Is there another approach I haven't thought of?

Thanks, Clinton _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Ben Gamari

3:47 p.m.

Clinton Mead writes:

...

I'm currently trying to bring my company around to using a bit of Haskell. One issue is that a number of our clients are based in South East Asia and need software that runs on Windows XP.

Ooph, that is quite tricky. Indeed we dropped XP support for Windows 8.0, at which point XP had already been EoL'd for seven years.

...

Unfortunately it seems the last version of GHC that produces executables that run on Windows XP is GHC 7.10. Whilst this table https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms/windows suggests the issue may only running GHC 8.0+ on Windows XP, I've confirmed that GHC 8.0 executables (even "Hello World") will not run on Windows XP, presumably because a non-XP WinAPI call in the runtime.

Indeed. The dropping of XP support was prompted by the need to use a newer Win32 interface (I can't recall which in particular).

...

My first thought would be to restrict myself to GHC 7.10 features (i.e. 2015). This would be a slight annoyance but GHC 7.10 still presents a reasonable language. But my concern would be that increasingly I'll run into issues with libraries that use extensions post GHC 7.10, particularly libraries with large dependency lists.

I would also be concerned about this. I wouldn't expect to be able to get very far with GHC 7.10 in 2021.

...

So there's a few options I've considered at this point:

1. Use GHCJS to compile to Javascript, and then dig out a version of NodeJS that runs on Windows XP. GHCJS seems to at least have a compiler based on GHC 8.6.

This is an option, although only you know whether this would fit your application given your memory and CPU constraints. I also have no idea how easy it would be to find a functional version of NodeJS.

...

But then I had a thought. If GHC Core isn't supposed to change much between versions is it? Which made me come up with these approaches:

3. Hack up a script to compile programs using GHC 9 to Core, then feed that Core output into GHC 7.10. OR

4. Produce a chimera style GHC by importing the GHC 9.0 API and the GHC 7.10 API, and making a version of GHC that does Haskell -> Core in GHC 9.0 and the rest of the code generation in GHC 7.10.

Sadly, I suspect this isn't going to work. While Core itself doesn't change (that much), the primops do. Even getting Core produced by GHC 9.0 to build under GHC 8.10 would require a considerable amount of work.

...

One issue with 4 will be that presumably that because I'm importing GHC 9.0 API and the 7.10 API separately, all their data types will technically be separate, so I'll need to basically deep copy the GHC 9.0 core datatype (and perhaps others) to GHC 7.10 datatypes. But presuming their largely similar this should be fairly mechanical.

I'm not sure how mechanical this would be, to be honest.

...

So are any of these approaches (well, particularly 2 and 4) reasonable? Or am I going to run into big problems with either of them? Is there another approach I haven't thought of?

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. 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). The possible reasons for Windows XP incompatibility that I can think of off the top of my head are: * Timers (we now use QueryPerformanceCounter) * Big-PE support, which is very much necessary for profiled builds * Long file path support (mostly a build-time consideration as Haskell build systems tend to produce very long paths) There may be others, but I would start looking there. I am happy to answer any questions that might arise. Cheers, - Ben

Clinton Mead

11:37 p.m.

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.

...

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-... should run on XP. Is this incorrect?

...

* Big-PE support, which is very much necessary for profiled builds

I don't really need profiled builds

...

* 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.

...

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). What do you think (roughly speaking)?

Clinton Mead

25 Mar 25 Mar

2:25 p.m.

Another gotcha that I didn't think of. The machines I'm targeting often have 32 bit versions of Windows, which it looks like isn't supported after GHC 8.6. Does this move it into the too hard basket?

Ben Gamari

5:05 p.m.

Clinton Mead writes:

...

Another gotcha that I didn't think of. The machines I'm targeting often have 32 bit versions of Windows, which it looks like isn't supported after GHC 8.6.

Does this move it into the too hard basket?

Ooph, yeah, this makes matters a bit worse. The reason we ultimately dropped 32-bit Windows support wasn't even a GHC bug; rather, a (rather long-standing at this point) bug in binutils (#17961) which made it impossible to reliably produce binary distributions. My recollection is that this but only affected builds of the object files used by GHCi. If you don't use GHCi then you can likely disable the production of these objects. Cheers, - Ben

Ben Gamari

10:34 p.m.

Clinton Mead 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-... 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-resolu...

...

...
* 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

Clinton Mead

26 Mar 26 Mar

1:27 a.m.

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://www.microsoft.com/en-us/research/publication/implementing-lazy-funct... 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 wrote:

...

Clinton Mead 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-...

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-resolu...

...
...
* 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

Moritz Angermann

3:59 a.m.

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 On Fri, Mar 26, 2021 at 1:29 PM Clinton Mead 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://www.microsoft.com/en-us/research/publication/implementing-lazy-funct... 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 wrote:

...
Clinton Mead 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-...

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-resolu...

...
...
* 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

Simon Peyton Jones

5:41 a.m.

This link gives some (old) background https://wiki.haskell.org/GHC/FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_th... Simon From: ghc-devs On Behalf Of Moritz Angermann Sent: 26 March 2021 08:00 To: Clinton Mead Cc: ghc-devs 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#ghchttps://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 mailto:clintonmead@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-machinehttps://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 mailto:ben@well-typed.com> wrote: Clinton Mead mailto:clintonmead@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-...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-resolu...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.orgmailto: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

Javier Neira Sanchez

28 Mar 28 Mar

4:19 p.m.

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_th...

Simon

*From:* ghc-devs *On Behalf Of *Moritz Angermann *Sent:* 26 March 2021 08:00 *To:* Clinton Mead *Cc:* ghc-devs *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 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 wrote:

Clinton Mead 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-... 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-resolu... 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

amindfv＠mailbox.org

27 Mar 27 Mar

4:11 p.m.

On Fri, Mar 26, 2021 at 04:27:58PM +1100, Clinton Mead wrote:

...

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.

Worth mentioning if you haven't come across it: F# is sorta-kinda a bit like Haskell and .NET support is first-class. Tom

Ben Gamari

29 Mar 29 Mar

11:06 p.m.

Clinton Mead writes:

...

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.

This is an interesting (albeit ambitious, for the reasons others have mentioned) idea. In particular, I think the CLR has a slightly advantage over the JVM as a Haskell target in that it has native tail-call support [1]. This avoids a fair amount of complexity (and performance overhead) that Eta had to employ to work around this lack in the JVM. I suspect that writing an STG -> CLR IR wouldn't itself be difficult. The hard part is dealing with the primops, RTS, and core libraries. [1] https://docs.microsoft.com/en-us/previous-versions/windows/silverlight/dotne...

...

I believe "Csaba Hruska" is working in this space with GRIN, yes?

Csaba is indeed using GHC's front-end and Core pipeline to feed his own compilation pipeline. However, I believe his approach is currently quite decoupled from GHC. This may or may not complicate the ability to integrate with the rest of the ecosystem (e.g. Cabal; Csaba, perhaps you could comment here?)

...

I read SPJs paper on Implementing Lazy Functional Languages on Stock Hardware: The Spineless Tagless G-machine https://www.microsoft.com/en-us/research/publication/implementing-lazy-funct... 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.

Indeed, STG itself is reasonably straightforward. Implementing tagged unions in the CLR doesn't even look that hard (F# does it, afterall). However, there are plenty of tricky bits: * You still need to implement a fair amount of RTS support for a full implementation (e.g. light-weight threads and STM) * You need to shim-out or reimplement the event manager in `base` * What do you do about the many `foreign import`s used by, e.g., `text`? * How do you deal with `foreign import`s elsewhere?

...

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?

At the moment we rather lack a good model for how new backends should work. There are quite a few axes to consider here: * How do core libraries (e.g. `text`) work? Various choices are: * Disregard the core libraries (along with most of Hackage) and just take the Haskell language * Reimplement many of the core libraries in the target language (e.g. as done by GHCJS) * How does the compiler interact with the Haskell build toolchain (e.g. Cabal)? Choices are: * Disregard the Haskell build toolchain. My (possibly incorrect) understanding is this is what GRIN does. * Implement something that looks enough like GHC to fool Cabal. * Upstream changes into Cabal to make your new compiler a first-class citizen. This is what GHCJS did. * How does the backend interact with GHC? Choices: * The GRIN model: Run the GHC pipeline and serialise the resulting IR (in the case of GRIN, STG) to a file to be slurped up by another process * The Clash/GHCJS model: Implement the new compiler as an executable linking against the GHC API. * The frontend plugin model: For many years now GHC has had support for "front-end plugins". This mechanism allows a plugin to fundamentally redefine what the GHC executable does (e.g. essentially adding a new "mode" to GHC, a la --interactive or --make). It's not impossible that one could use this to implement a new backend. * A hypothetical "backend plugin" mechanism: Currently GHC has no means of introducing plugins after the Core pipeline. Perhaps this should change? This would need a fair amount of design as aspects of the backend currently tend to leak into GHC's frontend. John Ericson has been keen on cleaning this up. Anyways, lots to think about.

...

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.

Yes, 32-bit Windows support sounds like something of a futile exercise. If the problem were *merely* GHC, then perhaps it would be possible. However, the entirety of the open-source compiler community struggles with Windows. For instance, binutils struggles to support even 64-bit Windows without regressions (e.g. see https://gitlab.haskell.org/ghc/ghc/-/issues/16780#note_342715). Cheers, - Ben

Moritz Angermann

11:24 p.m.

...

* Upstream changes into Cabal to make your new compiler a first-class citizen. This is what GHCJS did.

Just a word of caution, please don't do this. It leads to non-negligible maintainence burden on your and on the cabal side. Rather try as hard as you can to make your compiler behave like a ghc wrt to cabal. Or add generic support for more powerful compilers to cabal. Adding special handling for one additional compiler will just result in bitrot, odd quirks that only happen with that one compiler, and just a maintenance nightmare for everyone involved. We will be ripping out GHCJS custom logic from cabal. And I've also advised the Asterius author not to go down that route. My suggesting--if I may--is to try and build a c-like toolchain around your compiler. That has some notion of compiler, archiver, linker, and those could you empty shell wrappers, or no-ops, depending on your target. Cheers, Moritz On Tue, Mar 30, 2021 at 11:08 AM Ben Gamari wrote:

...

Clinton Mead writes:

...
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.

This is an interesting (albeit ambitious, for the reasons others have mentioned) idea. In particular, I think the CLR has a slightly advantage over the JVM as a Haskell target in that it has native tail-call support [1]. This avoids a fair amount of complexity (and performance overhead) that Eta had to employ to work around this lack in the JVM.

I suspect that writing an STG -> CLR IR wouldn't itself be difficult. The hard part is dealing with the primops, RTS, and core libraries.

[1] https://docs.microsoft.com/en-us/previous-versions/windows/silverlight/dotne...

...
I believe "Csaba Hruska" is working in this space with GRIN, yes?

Csaba is indeed using GHC's front-end and Core pipeline to feed his own compilation pipeline. However, I believe his approach is currently quite decoupled from GHC. This may or may not complicate the ability to integrate with the rest of the ecosystem (e.g. Cabal; Csaba, perhaps you could comment here?)

...
I read SPJs paper on Implementing Lazy Functional Languages on Stock Hardware: The Spineless Tagless G-machine <

https://www.microsoft.com/en-us/research/publication/implementing-lazy-funct...

...
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.

...
Indeed, STG itself is reasonably straightforward. Implementing tagged unions in the CLR doesn't even look that hard (F# does it, afterall). However, there are plenty of tricky bits:

* You still need to implement a fair amount of RTS support for a full implementation (e.g. light-weight threads and STM)

* You need to shim-out or reimplement the event manager in `base`

* What do you do about the many `foreign import`s used by, e.g., `text`?

* How do you deal with `foreign import`s elsewhere?

...
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?

At the moment we rather lack a good model for how new backends should work. There are quite a few axes to consider here:

* How do core libraries (e.g. `text`) work? Various choices are:

* Disregard the core libraries (along with most of Hackage) and just take the Haskell language

* Reimplement many of the core libraries in the target language (e.g. as done by GHCJS)

* How does the compiler interact with the Haskell build toolchain (e.g. Cabal)? Choices are:

* Disregard the Haskell build toolchain. My (possibly incorrect) understanding is this is what GRIN does.

* Implement something that looks enough like GHC to fool Cabal.

* Upstream changes into Cabal to make your new compiler a first-class citizen. This is what GHCJS did.

* How does the backend interact with GHC? Choices:

* The GRIN model: Run the GHC pipeline and serialise the resulting IR (in the case of GRIN, STG) to a file to be slurped up by another process

* The Clash/GHCJS model: Implement the new compiler as an executable linking against the GHC API.

* The frontend plugin model: For many years now GHC has had support for "front-end plugins". This mechanism allows a plugin to fundamentally redefine what the GHC executable does (e.g. essentially adding a new "mode" to GHC, a la --interactive or --make). It's not impossible that one could use this to implement a new backend.

* A hypothetical "backend plugin" mechanism: Currently GHC has no means of introducing plugins after the Core pipeline. Perhaps this should change? This would need a fair amount of design as aspects of the backend currently tend to leak into GHC's frontend. John Ericson has been keen on cleaning this up.

Anyways, lots to think about.

...
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.

Yes, 32-bit Windows support sounds like something of a futile exercise. If the problem were *merely* GHC, then perhaps it would be possible. However, the entirety of the open-source compiler community struggles with Windows. For instance, binutils struggles to support even 64-bit Windows without regressions (e.g. see https://gitlab.haskell.org/ghc/ghc/-/issues/16780#note_342715).

Cheers,

- Ben

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1515

Age (days ago)

1521

Last active (days ago)

List overview

Download

14 comments

8 participants

participants (8)

amindfv＠mailbox.org
Ben Gamari
Carter Schonwald
Clinton Mead
Javier Neira Sanchez
Moritz Angermann
Phyx
Simon Peyton Jones

Options for targeting Windows XP?

tags

participants (8)