Hi, Am Montag, den 06.10.2014, 19:55 +0000 schrieb p.k.f.holzensp...@utwente.nl: > Although I can't quite get what you're saying from the posts on that > link, I'm not immediately sure what you're saying should extend to > hi-files. These files are very much specific to the compiler version > you're using, as in, new GHCs add stuff to them all the time and their > binary format does not (seem to) provision for being able to skip > unknown things (i.e. it doesn't say how large the next semantic block > is in the hi-file).
Some of this may not be true, but to my knowledge (part of) that interface reading code is (or was?) used by haddock when generating its .haddock file. > If we're going to keep the formats the same for any architecture, > we're going to have to limit 64-bit machines to 32-bit (actually > 30-bits, another thing I don't quite understand in BinIface) Uniques. Why? You can just serialize Uniques always as 64 bit numbers, even on 32-bit systems. This way, the data format is the same across architectures, with little cost. > There seem to be possibilities to alleviate the issues with parallel > generation of fresh Uniques in a parallel version of GHC. The idea is > that, since 64-bits is more than we'll ever assign anyway, to use a > few for thread-ids, so we would guarantee non-conflicting Uniques > generated by different threads. > But that would only work on 64 bit systems, right? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
