On 18/01/2012 22:13, Gabor Greif wrote:
Hi all,
looks like I have an (almost) running binary on a PPC embedded target.
'Almost' because the native backend emits a 'lwsync' (light-weight
sync) instruction for the MO_WriteBarrier C-- instruction.
Unfortunately this is an e500 core that traps with "illegal
instruction" on 'lwsync'. Below I added some references that show that
many projects feel (felt) the pain.
From what I gather, write-barriers in GHC are only necessary in
multi-processor settings; when I am sure to have a uniprocessor, then
a simple 'nop' instruction will do. Can somebody confirm this?
So how to get out?
1) We could probe the target C compiler (when specified
'--with-target-gcc') whether it provides a __NO_LWSYNC__ macro (won't
work for us, i.e. my employer, as our GCC is probably older than
that).
2) some configure-time switch like '--enable-write-barrier={sync|nop|lwsync}'
sounds like a good solution, but clutters './configure --help'
3) Using the target triple to specify e500 or uniprocessor
how? are there conventions already?
Your build has $(GhcWithSMP) == NO, right? In that case, the compiler
should be generating no code for MO_WriteBarrier. We probably just
didn't implement that, but it would be an easy change to make.
The other solutions aren't very attractive - it would have to be a
configure-time option because the choice affects the RTS (except it
doesn't in your case, because GhcWithSMP is off).
Cheers,
Simon
Then we have to communicate the above to NCG; we could use
a) a #define and conditional compilation
quick, dirty, effective
b) Sub-architecture (ArchPPC e500)
elegant, but more work
I am very interested in input, do somebody have preferences or ideas
about the above?
Cheers,
Gabor
PS: added Wolfgang to 'CC:', as he wrote the 'lwsync' patch in the first place
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01238.html
http://code.google.com/p/google-perftools/issues/detail?id=140
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
