|
From: Greg P. <gp...@us...> - 2005-09-06 01:35:07
|
Cerion Armour-Brown writes: > On Monday 05 September 2005 04:39, Greg Parker wrote: > > The biggest problem blocking Darwin/ppc32 right now is VEX/ppc32. > > It's not yet complete enough to run Darwin's dynamic loader, and > > I don't know enough about VEX yet to fix it myself. If anyone > > out there is listening, my current requests are `lwbrx`, `mftb`, > > and `lvsl`, particularly the latter. (Unfortunately, I don't have > > any Altivec-less machines to play with, and convincing Mac OS X > > not to use it when it's present is tricky.) > > I'm about to get going with remaining ppc32 insns + altivec again - > i'll put those insns at the top of the list :-) Sounds good. I found a kernel switch to disable the Altivec unit, so that's not blocking me anymore. The commented-out lwbrx seems to work after a small tweak, and a do-nothing mftb works well enough for the programs I'm running now. lswx and stswx are rearing their ugly heads again. I have two solutions coded up, but neither is great. 1. Abuse Mux0X by performing 128 1-byte memory ops from either the right place in memory or a scratch location. lswx generates about 1800 instructions, and 1400 for stswx. It also needs cooperation from memcheck, because memcheck needs to know about the scratch byte used to load and store when it shouldn't hit the real memory. 2. Use a dirty helper. This is fast, but for memcheck to work properly it really needs the "memory touched" size to be an expression instead of a constant. I don't know how messy this would be to deal with in memcheck. However, I don't care about memcheck yet, so both solutions run well enough. -- Greg Parker gp...@us... |