Re: Options for targeting Windows XP?

[Moritz Angermann]

>
>* 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/dotnet-windows-silverlight/56c08k0k(v=vs.95)?redirectedfrom=MSDN
>
> > 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-functional-languages-on-stock-hardware-the-spineless-tagless-g-machine/
> >
> > 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 H

Re: Options for targeting Windows XP?

[Ben Gamari]

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/dotnet-windows-silverlight/56c08k0k(v=vs.95)?redirectedfrom=MSDN

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

Re: Options for targeting Windows XP?

[Javier Neira Sanchez]

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  *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
&g

Re: Options for targeting Windows XP?

[amindfv--- via ghc-devs]

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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Options for targeting Windows XP?

[Simon Peyton Jones via ghc-devs]

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  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 
mailto: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 ha

Re: Options for targeting Windows XP?

[Moritz Angermann]

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
> 
>  which
> implemented STG in C and whilst it wasn't trivial, it didn't seem
> stupendously complex (even I managed to roughly follow it).

Re: Options for targeting Windows XP?

[Clinton Mead]

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

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

Re: Options for targeting Windows XP?

[Ben Gamari]

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


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Options for targeting Windows XP?

[Ben Gamari]

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


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Options for targeting Windows XP?

[Clinton Mead]

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?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Options for targeting Windows XP?

[Clinton Mead]

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

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)?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Options for targeting Windows XP?

[Ben Gamari]

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


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Options for targeting Windows XP?

[Phyx]

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
>  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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Options for targeting Windows XP?

[Carter Schonwald]

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
>  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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Options for targeting Windows XP?

[Clinton Mead]

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