Hello,<br><br>Actually, when I run the code with dlmzb on the 970 cpu, I get a SIGILL and what I would love to do is actually to add a hook on it to be able to run the code compiled with mcpu=440fp directly on the power-station. I do not think it's already done and as you said, it seems quite complicated to do that.<br>
<br>I use the power-station to host chrooted build environments. I'm currently able to build more than 300 Fedora srpms without any modification in them. This was true when I used gcc 4.0. gcc 4.4 is much better to optimized for amcc440 cpu and it is able to manage dlmzb instruction. My goal is to do as less modification as possible on the srpms, and thus cross-compilation would not be a good solution since most of the packages are not able to manage the HOSTCC parameter natively. I have only the problem with srpms that need to use their own built binary at compile time. Till now, I just remove the mcpu=440fp option when I build those srpms. Luckily, those rpms are not big cpu consumers and then, it is not a big deal if they are compiled with or wihout the 440fp option.<br>
<br>I like your solution of using
-mcpu=440fp and -mno-dlmzb option, this is less drastic than what I was doing till now.<br><br>The target CPU is a low power amcc 440 EPX:<br><a href="http://www.appliedmicro.com/MyAMCC/jsp/public/productDetail/product_detail.jsp?productID=PPC440EPx">http://www.appliedmicro.com/MyAMCC/jsp/public/productDetail/product_detail.jsp?productID=PPC440EPx</a><br>
<br> Thanks for your time and your help<br> <br> Patrice<br><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">> Is there a way to emulate those instructions on a Power Station (which<br>
> currently runs YDL 6.0)<br>
</div>...<br>
Eh, sorry, was suggesting work-arounds, didn't address your direct question...<br>
<br>
I suppose it is possible to emulate in theory. I believe all powerpcs<br>
will generate an exception when they attempt to execute an invalid<br>
instruction that does not translate to the equivalent of a NOP.<br>
<br>
I guess it is possible in theory to get an exception handler written<br>
(ie probably within the kernel) to translate dlmzb and related string<br>
opcodes implemented on the 440 but not the 970.<br>
<br>
However, I recall something about powerpc's in general that can treat<br>
quite a few hex words as NOPs. If this instruction actually translates<br>
to a NOP on a 970 it may get a little trickier, but if you're already<br>
getting an illegal instruction error, then, maybe an exception handler<br>
like that can be written.<br>
<br>
I do not however know if this is already done, or how easy it will be<br>
to do this. Presumably, one has to write the equivalent translation<br>
assembly code and then find a way to hook it up to the exception<br>
handler that already exists - and find a place for this code to live.<br>
And then debug it :)<br>
<br>
It looks to me like you've got to hack the kernel, if you want to try<br>
this, unless someone's already done this.<br>
<br>
Given the wide variation and differing degrees of implementation of<br>
the powerpc instruction set on the various processors, it may not be<br>
such idea to try implement some form of a kernel level handler to deal<br>
with unimplemented instructions - of course, this is a compromise.<br>
<br>
Again, perhaps just trying to cross-compile and run the resultant code<br>
on the target itself may be the simplest solution (otherwise you could<br>
turn off generation of the dlmzb instruction as I suggeested earlier<br>
if you want to try and run the code on your 970).<br>
<br>
What sort of target is this 440 on out of curiosity? I am assuming if<br>
you could run prior builds from older gccs it must be some sort of<br>
environment not too dissimilar to your build environment?<br>
<div class="im"><br>
> Patrice<br>
> _______________________________________________<br>
> yellowdog-general mailing list - <a href="mailto:yellowdog-general@lists.fixstars.com">yellowdog-general@lists.fixstars.com</a><br>
> Unsuscribe info: <a href="http://lists.fixstars.com/mailman/listinfo/yellowdog-general" target="_blank">http://lists.fixstars.com/mailman/listinfo/yellowdog-general</a><br>
> HINT: to Google archives, try '&lt;keywords> site:<a href="http://us.fixstars.com" target="_blank">us.fixstars.com</a>'<br>
<br>
</div><div class="im">Robert Spykerman<br>
<br>
--<br>
chown -R us ./base<br>
_______________________________________________<br>
</div><div><div class="h5">yellowdog-general mailing list - <a href="mailto:yellowdog-general@lists.fixstars.com">yellowdog-general@lists.fixstars.com</a><br>
Unsuscribe info: <a href="http://lists.fixstars.com/mailman/listinfo/yellowdog-general" target="_blank">http://lists.fixstars.com/mailman/listinfo/yellowdog-general</a><br>
HINT: to Google archives, try '&lt;keywords> site:<a href="http://us.fixstars.com" target="_blank">us.fixstars.com</a>'<br>
</div></div></blockquote>...<br>
</div><br>