Rust's llvm_asm! macro was never intended to be stabilized, switch to using the new asm! macro that will be stabilized. new asm! macro RFC: https://github.com/rust-lang/rfcs/pull/2843 WIP branch: https://salsa.debian.org/Kazan-team/power-instruction-analyzer/-/tree/update-for-new-asm
Created a rustc pull request adding support for clobbering xer and cr: https://github.com/rust-lang/rust/pull/88350
(In reply to Jacob Lifshay from comment #1) > Created a rustc pull request adding support for clobbering xer and cr: > https://github.com/rust-lang/rust/pull/88350 merged!
Finished changing the procedural macro to generate the new-style asm! macro calls rather than llvm_asm!, and pushed to master. If you want to build the version with native ppc64le instruction testing, you'll need a rustc version later than: rustc 1.56.0-nightly (50171c310 2021-09-01) since it includes: https://github.com/rust-lang/rust/pull/88350 Lkcl, does EUR 200 sound good, since it was several days of work?
if this is for rust then no. also i believe i made it clear that pia needs to be removed as a dependency and replaced with an equivalent in portable python. the difficulty that dmitry is having, and its lack of portability between versions unless compiled specifically for a particular version of python, and the fact that an external compiler is needed at all, and many other factors which i have outlined many times over the past 4 months, means that pia has to be replaced. it was an experiment that turned out to be a costly mistake. the sooner it is replaced, the less time and NLnet funding will be wasted on replacing something that is even larger.
(In reply to Luke Kenneth Casson Leighton from comment #4) > if this is for rust then no. > > also i believe i made it clear that pia needs to be removed as a dependency > and replaced with an equivalent in portable python. well, python doesn't have inline assembly...
(In reply to Jacob Lifshay from comment #5) > (In reply to Luke Kenneth Casson Leighton from comment #4) > > if this is for rust then no. I think it's worth paying for this work, because, since pia is currently necessary, maintaining it is very much part of what libre-soc is funded to do. Also, some of the work also helps out with implementing Kazan, since Kazan will probably need inline assembly.
(In reply to Luke Kenneth Casson Leighton from comment #4) > the difficulty that dmitry is having, and its lack of portability > between versions unless compiled specifically for a particular > version of python, it's just as portable between python versions as numpy...which no one's complained about afaict > and the fact that an external compiler is needed > at all, and many other factors which i have outlined many times over > the past 4 months, means that pia has to be replaced.
(In reply to Jacob Lifshay from comment #6) > (In reply to Jacob Lifshay from comment #5) > > (In reply to Luke Kenneth Casson Leighton from comment #4) > > > if this is for rust then no. > > I think it's worth paying for this work, because, since pia is currently > necessary, maintaining it is very much part of what libre-soc is funded to > do. that is precisely and exactly one of the many reasons why it has to go. the fact that it has a maintenance cost AT ALL, one that was NOT evaluated or discussed, that IS the costly mistake which we made. when the decision to evaluate funding of pia was done, we did not know enough to say whether it would even HAVE a maintenance burden, and so there was no planning. the fact that a cost has EMERGED severely interferes with the Project Planning. remember: NLnet Grants take about **SIX MONTHS** to become active, and **CANNOT** be retroactively modified. if we make a planning mistake like this it is extremely serious. code that is written in python on the other hand will continue to function and be portable. please listen to what i am saying: the fact that pia failed to compile for a new developer and, six weeks later they still cannot get it installed, i have explained already that this is unacceptable. pia has beeen an important learning exercise and the sooner it is removed and replaced the better. it is sufficiently urgent that Dmitry be able to run unit tests that i am happy to put up a budget of EUR 200 to make it optional to install. i am not happy - at all - to put further NLnet funding towards something that has demonstrate in multiple ways that it is too much of a headache to continue to fund. > Also, some of the work also helps out with implementing Kazan, since Kazan > will probably need inline assembly. then that can be justified when some work on Kazan takes place. no work on Kazan has taken place in over 18 months. (In reply to Jacob Lifshay from comment #7) > it's just as portable between python versions as numpy...which no one's > complained about afaict 1) numpy is maintained by a large team that has other people paying for it. 2) it is also not a dependency. 3) it is also a mature and stable library, 4) it uses a stable programming language with a mature well defined release cycle that is integrated into distros ("Rust's llvm_asm! macro was never intended to be stabilized") there are many other reasons why this is an invalid perspective which actually helps illustrate why pia should be removed and replaced. (In reply to Jacob Lifshay from comment #5) > well, python doesn't have inline assembly... then we find a way to do that (in a way that does NOT include rust or any rust tools or any rust libraries or any other dependencies which are not already used). i am happy to put up a budget to find out how that can be done. please understand and accept the seriousness of the lesson that has been learned from the incident where new developers were unable to use the automated install scripts. and the many other reasons all of which combine to sound a massive alarm bell that pia has to go.