* Serge D. Mechveliani [2012-02-06 10:05:14+0400]
> I need a reliable portability for ages for the Haskell applications
> written in Haskell-2010 + Ext,
> where Ext = Overlapping instances + Multiparametric classes
> (as in GHC).
> In particular, my DoCon is such an application.
> And no Haske
On 5 February 2012 10:48, Serge D. Mechveliani wrote:
> Dear GHC team,
>
> I cannot understand why do you remove the C stage in GHC.
We didn't.
GHC itself can be built in two different ways, 'unregisterized' and
'registerized'. The former method is more portable while the latter
uses as many tri
On Mon, Feb 6, 2012 at 01:05, Serge D. Mechveliani wrote:
> And now GHC somehow seems to deviate from portability
Registerised GHC was never "portable". Or if it was, it was well before
GHC6. You just weren't aware of what was going on, and apparently built
yourself a fantasy world where GHC
On Sun, Feb 05, 2012 at 09:09:58PM +0100, Krzysztof Skrz??tnicki wrote:
> GHC code still depends on RTS code (written in C by the way) which has to
> be ported to a specific platform first. Native code generator offers
> 'registered' and 'unregistered' builds. The first are aware of specific
> regi
Being in C is very different than being 'portable'. The C code
generated by GHC never looked anything like what you would expect C
code to look like, it was basically a list of pre-proccessor macros
that expanded to STG-machine code sort of.
If you want to know what low-level operations ghc is doi
Hello,
as far as I understand, via-C was removed for registerised builds, but
is still supported for unregisterised builds.
So if you prefer via-C way, just compile GHC unregistered on your platform.
Cheers,
Karel
On 02/ 5/12 07:48 PM, Serge D. Mechveliani wrote:
Dear GHC team,
I cannot
GHC code still depends on RTS code (written in C by the way) which has to
be ported to a specific platform first. Native code generator offers
'registered' and 'unregistered' builds. The first are aware of specific
register layout of a architecture. You can find more rationale why it has
been remov
Dear GHC team,
I cannot understand why do you remove the C stage in GHC.
To my mind: let the result be 3 times slower, but preserve the C code.
Because it works everyhere, and there is no real need to rewrite
the same program separately for all the existing processors
(which number may become, for
I take back my two recent reports about the effect of -O2, -fvia-C.
Because
1) -O is sufficient,
2) there are too many issues that are more important than the behavior
under -O2 and via-C. So, it is a good idea to save effort.
Regards,
-
Serge Mechveliani
[EMAIL PROTECTED
