Timothy Robin BARBOUR <[EMAIL PROTECTED]> writes:
> No need to relocate on an Alpha - just use a different high 32-bits
> for each persistent store. Not that I've got an Alpha yet...
Sure - not a portable solution, though.
> BTW I will probably get an Alpha sometime for running ghc, but it
> will be running Linux. Am I right in thinking that porting ghc to
> Linux/Alpha would be just a matter of mixing and matching from the
> Linux/i386 and OSF/Alpha ports ?
I would *hope* that this won't be too painful. Alpha-specific parts
of the run-time system should be protected with #ifdef alpha_TARGET_ARCH,
whereas OSF specific bits should be surrounded by #ifdef osf_TARGET_OS.
If this isn't the case anywhere, it should be.
> Simon> - Heap-resident data in GHC refers (by address) to the
> Simon> code of the program itself, and to parts of the run-time
> Simon> system. You'd have to do some kind of dynamic linking to
> Simon> be able to load data back again.
>
> I didn't think of this. Are you referring to the way the STG machine
> always jumps (via a pointer) to entry code when entering a closure
> (even an evaluated one) ? Do you think the dynamic linking would be
> practical (it sounds like a lot of pain) ?
It sounds quite painful, unless it can be combined with the dynamic
linking that we're doing as part of the Hugs/GHC coalition (see
below).
> BTW does ghc support generating shared libraries (under Linux) ? Last
> time I tried (maybe a year ago) it didn't seem to like -optc-fpic -
> IIRC the executables just seg-v'ed.
Shared libraries (of the PIC variety - that includes ELF and a.out)
aren't supported under Linux because the PIC code requires reserving a
register, and we need all the registers we can get our hands on.
We're working on some kind of dynamic linking strategy for the
combined Hugs/GHC, which will probably do what you want (i.e. have a
dynamically loaded Prelude and run-time system). It will probably
involve some sort of per-module jump tables.
> Simon> program to save/load data. If you recompiled the program,
> Simon> you'd have to regenerate the persistent store.
>
> Even if the recompilation used the same compiler and flags ?
Yes, if you changed the program. Nevertheless, you can't rely on
re-compiling a program using an identical compiler and flags to
produce an identical binary.
> I remember that ghc historically did not support Binary, but maybe
> this has changed. In the ghc-3.01 Users Guide, section 4.9 ("Haskell
> 1.4 vs. Glasgow Haskell 3.00: language non-compliance") does not
> mention Binary. Did Binary support sneak in while I wasn't looking ?
> If Binary were available, I would be happy to use that - until someone
> develops a functional OS.
We don't have Binary at the moment, but it could happen if we find the
time to tackle it (or someone else implements it...)
Cheers,
Simon
--
Simon Marlow [EMAIL PROTECTED]
University of Glasgow http://www.dcs.gla.ac.uk/~simonm/
finger for PGP public key
