Re: FreeBSD/amd64 registerised running
On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote:
>
> I have ghc-6.6 (darcs version from 20070405) running registerized on
> FreeBSD/amd64.
Excellent! Well done, and thanks for persevering!
It would be great if you could let us have a bindist and any necessary
patches.
> The fix is to patch libraries/base/Text/Regex/Posix.hs on the amd64
> target:
>
> --- libraries/base/Text/Regex/Posix.hs.sav Thu Apr 5 12:05:22 2007
> +++ libraries/base/Text/Regex/Posix.hs Thu Apr 5 12:05:45 2007
> @@ -106,7 +106,7 @@
> regexec (Regex regex_fptr) str = do
>withCString str $ \cstr -> do
> withForeignPtr regex_fptr $ \regex_ptr -> do
> - nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) regex_ptr
> + nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) regex_ptr
> {-# LINE 109 "Posix.hsc" #-}
>let nsub_int = fromIntegral (nsub :: CSize)
>allocaBytes ((1 + nsub_int) * (16)) $ \p_match -> do
Aha! That makes sense: When generating .hc files on the host machine,
hsc2hs makes a C program which generates a .hs module (with the host's
sizes embedded in it) which is finally compiled down to .hc as normal.
So I think to do this in a way that is porting-friendly, hsc2hs would
have to convert
f = ... #peek regex_t, re_nsub ...
into something like
-- Haskell:
foreign import re_nsub_off :: Int
f = ... (\hsc_ptr -> peekByteOff hsc_ptr re_nsub_off) ...
/* C */
#import "HsFFI.h"
HsInt re_nsub_off(void) { return ... }
Unfortunately I don't think we can do anything as nice with #type.
> With this patch, we are pretty close. However, there still seems to be
> something wrong with the splitter. I can make a working registerized
> compiler if I set splitObjs=NO in build.mk, but it seems as if
> whatever is
> wrong with ghc-split shouldn't be too hard to fix.
>
> I've glanced at ghc-split.lprl, but on what files is it invoked? Can
> I run it from the command line on a file and see check what comes out?
If you compile a module with
ghc -v -keep-tmp-files
then you should see the commandline it is using, and it should leave the
files for you to examine, and rerun the commands on, afterwards.
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Hi Ian, On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote: On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote: I have ghc-6.6 (darcs version from 20070405) running registerized on FreeBSD/amd64. Excellent! Well done, and thanks for persevering! It would be great if you could let us have a bindist and any necessary patches. I will certainly provide patches and a binary distribution that people can use to bootstrap their own compilers. I will try to get ghci running before I put out a release. If you compile a module with ghc -v -keep-tmp-files then you should see the commandline it is using, and it should leave the files for you to examine, and rerun the commands on, afterwards. I'm giving this a try right now. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Hi Ian, On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote: With this patch, we are pretty close. However, there still seems to be something wrong with the splitter. I can make a working registerized compiler if I set splitObjs=NO in build.mk, but it seems as if whatever is wrong with ghc-split shouldn't be too hard to fix. I've glanced at ghc-split.lprl, but on what files is it invoked? Can I run it from the command line on a file and see check what comes out? If you compile a module with ghc -v -keep-tmp-files then you should see the commandline it is using, and it should leave the files for you to examine, and rerun the commands on, afterwards. I did this and immediately discovered that the problem is not with ghc-split but with ghc-asm. ".globl" directives are being deleted when they shouldn't be. This is somewhat reminiscent of bug #1167, except that it seems to happen far more frequently on amd64. Perhaps someone has an idea of the top of their head for this one. I wouldn't be surprised if the fix for this also took care of the bug on the less loved linux-ppc platform. Best Wishes. Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Gregory Wright wrote:
I have ghc-6.6 (darcs version from 20070405) running registerized on
FreeBSD/amd64. The FreeBSD version is 6.2.
The problem with the compiler crash turned out to be simple. In the
FreeBSD header file regex.h, regex_t is defined as
typedef struct {
int re_magic;
size_t re_nsub; /* number of parenthesized
subexpressions */
__const char *re_endp; /* end pointer for REG_PEND */
struct re_guts *re_g; /* none of your business :-) */
} regex_t;
The problem is that the "re_magic" field is defined as an int. When
building
the .hc files on the i386 host, the re_nsub field is at an offset of 4.
On the
amd64 target, it is at an offset of 8. In the ghc binding to the regex
functions,
re_nsub is used to compute how much memory to allocate in a call to
allocaBytes. This leads to garbage being passed to newPinnedByteArray#.
The fix is to patch libraries/base/Text/Regex/Posix.hs on the amd64 target:
--- libraries/base/Text/Regex/Posix.hs.sav Thu Apr 5 12:05:22 2007
+++ libraries/base/Text/Regex/Posix.hs Thu Apr 5 12:05:45 2007
@@ -106,7 +106,7 @@
regexec (Regex regex_fptr) str = do
withCString str $ \cstr -> do
withForeignPtr regex_fptr $ \regex_ptr -> do
- nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) regex_ptr
+ nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) regex_ptr
{-# LINE 109 "Posix.hsc" #-}
let nsub_int = fromIntegral (nsub :: CSize)
allocaBytes ((1 + nsub_int) * (16)) $ \p_match -> do
With this patch, we are pretty close.
Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by hsc2hs, but
this is done on the *host* rather than the *target* when bootstrapping, and thus
generates the wrong results. If you'd run hsc2hs on the target, then
Text/Regex/Posix.hs would have been correct, but you can't do this because
hsc2hs is a Haskell program. You could take the .c file generated by hsc2hs on
the host and compile/run it on the target, but that's a hassle, so instead our
policy is that we don't rely on any hsc2hs-generated code for bootstrapping.
Unfortunately I broke the rules by accident when I introduced the dependency on
regex. I can't think of an easy way to enforce the rule, at least at the
moment, since there are other hsc2hs-processed modules that we happen to not
depend on in GHC (System.Time and System.CPUTime).
This will be fixed as a side effect of
http://hackage.haskell.org/trac/ghc/ticket/1160. Also after the base reorg we
might find we have no hsc2hs-generated code left in base and we can disable
hsc2hs to prevent this happening again.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Simon Marlow wrote: > Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by > hsc2hs, but this is done on the *host* rather than the *target* when > bootstrapping, and thus generates the wrong results. If you'd run > hsc2hs on the target, then Text/Regex/Posix.hs would have been correct, > but you can't do this because hsc2hs is a Haskell program. You could > take the .c file generated by hsc2hs on the host and compile/run it on > the target, but that's a hassle, so instead our policy is that we don't > rely on any hsc2hs-generated code for bootstrapping. > > Unfortunately I broke the rules by accident when I introduced the > dependency on regex. I can't think of an easy way to enforce the rule, > at least at the moment, since there are other hsc2hs-processed modules > that we happen to not depend on in GHC (System.Time and System.CPUTime). Could the solution be to depend on a pure Haskell regex implementation instead of on a regex-posix / Posix.hsc and the system regex library? The regex-tdfa backend could be modified to work with the regex-base in GHC 6.6 and then regex-compat could quickly be switched to use this instead of regex-posix. -- Chris Kuklewicz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Hi Olli, On Apr 10, 2007, at 1:23 PM, Oliver Braun wrote: Hi Gregory, * Gregory Wright <[EMAIL PROTECTED]> [2007-04-09 12:38 -0400]: I have ghc-6.6 (darcs version from 20070405) running registerized on FreeBSD/amd64. I will certainly provide patches and a binary distribution that people can use to bootstrap their own compilers. It would be nice if you cann provide a bootstrap tarball for integration in the FreeBSD lang/ghc port. I will do this as soon as I get the Linker bugs worked out so we can have ghci. Since this won't make it into 6.6.1 a few patches will have to be applied to the distribution. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Chris Kuklewicz wrote: Simon Marlow wrote: Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by hsc2hs, but this is done on the *host* rather than the *target* when bootstrapping, and thus generates the wrong results. If you'd run hsc2hs on the target, then Text/Regex/Posix.hs would have been correct, but you can't do this because hsc2hs is a Haskell program. You could take the .c file generated by hsc2hs on the host and compile/run it on the target, but that's a hassle, so instead our policy is that we don't rely on any hsc2hs-generated code for bootstrapping. Unfortunately I broke the rules by accident when I introduced the dependency on regex. I can't think of an easy way to enforce the rule, at least at the moment, since there are other hsc2hs-processed modules that we happen to not depend on in GHC (System.Time and System.CPUTime). Could the solution be to depend on a pure Haskell regex implementation instead of on a regex-posix / Posix.hsc and the system regex library? Yes, as I mentioned, ticket 1160 (http://hackage.haskell.org/trac/ghc/ticket/1160) is for replacing regex-posix with regex-tdfa, and that would fix this issue. However, Igloo just removed the regex packages from GHC's core package set, so we don't have the problem any more. The regex-tdfa backend could be modified to work with the regex-base in GHC 6.6 and then regex-compat could quickly be switched to use this instead of regex-posix. It sounds like a good idea to switch regex-compat to depend on regex-tdfa anyway. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Simon Marlow wrote: > Chris Kuklewicz wrote: >> Could the solution be to depend on a pure Haskell regex implementation >> instead >> of on a regex-posix / Posix.hsc and the system regex library? > > Yes, as I mentioned, ticket 1160 > (http://hackage.haskell.org/trac/ghc/ticket/1160) is for replacing > regex-posix with regex-tdfa, and that would fix this issue. > > However, Igloo just removed the regex packages from GHC's core package > set, so we don't have the problem any more. > >> The regex-tdfa backend could be modified to work with the regex-base >> in GHC 6.6 >> and then regex-compat could quickly be switched to use this instead of >> regex-posix. > > It sounds like a good idea to switch regex-compat to depend on > regex-tdfa anyway. > After I upgrade to 6.6.1 (using OS X on PPC) then I will make new versions of regex-compat and regex-tdfa. The thing I have to fix is that the current "unstable" regex-tdfa depends on the "unstable" regex-base and I have to make a new branch of regex-tdfa that works against the "stable" regex-base that 6.6 and 6.6.1 use. Mainly this will be erasing code. For 6.8 we can upgrade regex-base to whatever the latest version is then. Current changes in regex-base are (1) use of 'fail' for error handling in RegexMaker, (2) use of newtypes to make avoid Hugs seeing overlapping instances in RegexContext (no more conditional compilation). -- Chris ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Just a further note on the FreeBSD/amd64 port. I have the mangler fixed up now, so the only remaining issue is the linker. I hope to send patches soon. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Simon Marlow <[EMAIL PROTECTED]> wrote: > Also after the base > reorg we might find we have no hsc2hs-generated code left in base and > we can disable hsc2hs to prevent this happening again. Ah. I was about to checkin a replacement for System.Posix.Types (in base) that uses hsc2hs instead of autoconf. Will that cause a problem? I'm guessing that even the autoconf'd sources are currently bootstrapped on the host rather than the target, so maybe the changeover will make no difference? Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Malcolm Wallace wrote: Simon Marlow <[EMAIL PROTECTED]> wrote: Also after the base reorg we might find we have no hsc2hs-generated code left in base and we can disable hsc2hs to prevent this happening again. Ah. I was about to checkin a replacement for System.Posix.Types (in base) that uses hsc2hs instead of autoconf. Will that cause a problem? I'm guessing that even the autoconf'd sources are currently bootstrapped on the host rather than the target, so maybe the changeover will make no difference? I'm confused. I thought we copied the configuration from the target to the host as part of the bootstrapping process, but now I can't see how this is supposed to happen for HsBaseConfig.h. It looks like following the instructions in the building guide will result in failure if you try to cross-compile between machines with different word sizes, but I know I've done this in the past :-/ Ian, any idea how this is supposed to work? Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target without GHC, but we can run configure. I suppose we could add a dependency on another Haskell compiler just to run hsc2hs, but that's a pain. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Simon Marlow <[EMAIL PROTECTED]> wrote: > I suppose we could add a dependency on another Haskell compiler just to > run hsc2hs, but that's a pain. I'm hoping that by the end of this summer, nhc98 will be able to compile the whole of ghc. :-) Also, and alternatively, the yhc chaps have mooted the idea of moving from nhc98's front end to ghc's, which might eventually give you a fully portable bytecode route to bootstrapping ghc on new machines. Pipe dreams for now though. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Hi I'm hoping that by the end of this summer, nhc98 will be able to compile the whole of ghc. :-) Also, and alternatively, the yhc chaps have mooted the idea of moving from nhc98's front end to ghc's, which might eventually give you a fully portable bytecode route to bootstrapping ghc on new machines. We half thought about that, but a more direct goal is to be able to convert GHC Core to Yhc Core, then we can use either GHC's front end (via system) or Yhc's (natively). This would mean that we would be able to compile any library with GHC then use it with Yhc. This project will take about three days, once GHC has a non-broken Core library. Thanks Neil ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
I'm confused. I thought we copied the configuration from the target to the host as part of the bootstrapping process, but now I can't see how this is supposed to happen for HsBaseConfig.h. It looks like following the instructions in the building guide will result in failure if you try to cross-compile between machines with different word sizes, but I know I've done this in the past :-/ Ian, any idea how this is supposed to work? Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target without GHC, but we can run configure. I suppose we could add a dependency on another Haskell compiler just to run hsc2hs, but that's a pain. how about a repository for platform-specific configuration files? that way you only need the first user on each platform to figure things out, either by installing extra tools or by modifying existing configuration files? btw, lots of things have changed since i last built ghc, but i thought it strange that configure used to rediscover platform-specific configuration data for each sub-project (each running its own configure, but not seeming all that specific in what to test for). claus ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Simon Marlow <[EMAIL PROTECTED]> writes: > > Ah. I was about to checkin a replacement for System.Posix.Types (in > > base) that uses hsc2hs instead of autoconf. > > Anyway, to answer your question, using hsc2hs in System.Posix.Types > will cause problems for bootstrapping GHC, yes, because we can't run > hsc2hs on the target without GHC, but we can run configure. But it is only a problem for cross-compiling - yes? And no more of a problem than ghc already has? So, should I push my patch for building System.Posix.Types with nhc98 (i.e. without autoconf, with hsc2hs) or not? At the moment, the lack of System.Posix.Types is breaking the nightly builds of Cabal/nhc98. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
On Thu, Apr 12, 2007 at 04:33:27PM +0100, Simon Marlow wrote: > > I'm confused. I thought we copied the configuration from the target to the > host as part of the bootstrapping process, but now I can't see how this is > supposed to happen for HsBaseConfig.h. It looks like following the > instructions in the building guide will result in failure if you try to > cross-compile between machines with different word sizes, but I know I've > done this in the past :-/ > Ian, any idea how this is supposed to work? I guess we've just been lucky. "#define HTYPE_INT Int32" is probably true everywhere we've tried in recent years, and probably covers most of the potentially troublesome cases. Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
On Thu, Apr 12, 2007 at 08:49:03PM +0100, Malcolm Wallace wrote: > Simon Marlow <[EMAIL PROTECTED]> writes: > > > > Ah. I was about to checkin a replacement for System.Posix.Types (in > > > base) that uses hsc2hs instead of autoconf. > > > > Anyway, to answer your question, using hsc2hs in System.Posix.Types > > will cause problems for bootstrapping GHC, yes, because we can't run > > hsc2hs on the target without GHC, but we can run configure. > > But it is only a problem for cross-compiling - yes? Yes. > And no more of a problem than ghc already has? No, with the configure method we can run configure on the target and copy the files back to the host. The instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/Porting do so for includes/ghcautoconf.h includes/DerivedConstants.h includes/GHCConstants.h and look like they ought to for libraries/base/include/HsBaseConfig.h too. But we can't run hsc2hs on the target without having a Haskell compiler there. Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Neil Mitchell wrote: Hi I'm hoping that by the end of this summer, nhc98 will be able to compile the whole of ghc. :-) Also, and alternatively, the yhc chaps have mooted the idea of moving from nhc98's front end to ghc's, which might eventually give you a fully portable bytecode route to bootstrapping ghc on new machines. We half thought about that, but a more direct goal is to be able to convert GHC Core to Yhc Core, then we can use either GHC's front end (via system) or Yhc's (natively). This would mean that we would be able to compile any library with GHC then use it with Yhc. This project will take about three days, once GHC has a non-broken Core library. How do you plan to implement unboxed types? AFAIK, implementing unboxed types requires a typed intermediate language. Maybe you could get away with boxing all the unboxed types, but then Int would have an extra level of boxing. And the other big problem with implementing GHC core is all the primitives... Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Claus Reinke wrote: I'm confused. I thought we copied the configuration from the target to the host as part of the bootstrapping process, but now I can't see how this is supposed to happen for HsBaseConfig.h. It looks like following the instructions in the building guide will result in failure if you try to cross-compile between machines with different word sizes, but I know I've done this in the past :-/ Ian, any idea how this is supposed to work? Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target without GHC, but we can run configure. I suppose we could add a dependency on another Haskell compiler just to run hsc2hs, but that's a pain. how about a repository for platform-specific configuration files? that way you only need the first user on each platform to figure things out, either by installing extra tools or by modifying existing configuration files? The case we're worried about is the first time you port to a new platform, because after that we have a working compiler so there's no problem. The instructions in the GHC building guide describe how to do this (http://hackage.haskell.org/trac/ghc/wiki/Building/Porting). It's not especially well supported by the build system, so the process is a bit fiddly, but we have to be careful to make sure it is at least possible to do it and not too tortuous. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Hi How do you plan to implement unboxed types? AFAIK, implementing unboxed types requires a typed intermediate language. Maybe you could get away with boxing all the unboxed types, but then Int would have an extra level of boxing. Indeed, we intend to box everything. Plus there were compilers which did unboxing before having unboxed types - as the paper said, it wasn't as neat, but it was possible. I also have a design for a C backend where the Int can be packed into the pointer, which removes the boxes from all evaluated Ints. And the other big problem with implementing GHC core is all the primitives... The Yhc primitives aren't particularly nice, but we have a design in which they could be made much nicer, and also allow implementation of the GHC core primitives easily. This will probably be the larger chunk of work. Thanks Neil ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Neil Mitchell wrote: Hi How do you plan to implement unboxed types? AFAIK, implementing unboxed types requires a typed intermediate language. Maybe you could get away with boxing all the unboxed types, but then Int would have an extra level of boxing. Indeed, we intend to box everything. Plus there were compilers which did unboxing before having unboxed types - as the paper said, it wasn't as neat, but it was possible. Right, but the problem is that if you box all of GHC's unboxed types, you end up with an extra layer of boxing compared to an implementation that just boxes everything. ie. it'll be worse than YHC is currently, so you'll need extra trickery to get back to where YHC is now. I also have a design for a C backend where the Int can be packed into the pointer, which removes the boxes from all evaluated Ints. Presumably you lose one bit of precision though, so GHC's Int# type would be 31 bits. We did at one stage have a GHC->OCaml translator with a 31-bit Int#, so it might be possible, but I think there will be some assumptions in the libraries that break (eg. Int32 will need to be implemented using Int64#). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Hi > Indeed, we intend to box everything. Plus there were compilers which > did unboxing before having unboxed types - as the paper said, it > wasn't as neat, but it was possible. Right, but the problem is that if you box all of GHC's unboxed types, you end up with an extra layer of boxing compared to an implementation that just boxes everything. ie. it'll be worse than YHC is currently, so you'll need extra trickery to get back to where YHC is now. Possible, I'll have to think about this further. I was thinking along the lines of newtype Box a = Box !a then Int# = Box Int but I'm not sure if that will work or not. Anyway, its only a question of efficiency, and Yhc has a lot more things that will destroy efficiency than this! Presumably you lose one bit of precision though, so GHC's Int# type would be 31 bits. We did at one stage have a GHC->OCaml translator with a 31-bit Int#, so it might be possible, but I think there will be some assumptions in the libraries that break (eg. Int32 will need to be implemented using Int64#). We loose 2 bits, to leave room for enough tag bits. Fortunately this still fills the Haskell specification. We will have some method for implementing Int32, probably as a pointer once again. Thanks Neil ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
I wrote: > So, should I push my patch for building > System.Posix.Types with nhc98 (i.e. without autoconf, with hsc2hs)? OK, I have pushed a revised patch, which should not alter the behaviour for ghc at all. I moved the invocation of hsc2hs into the NHC.* hierarchy, and just re-export that module from System.Posix.Types instead. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
