<br><br>On Monday, March 6, 2023, Jacob Lifshay <<a href="mailto:programmerjake@gmail.com">programmerjake@gmail.com</a>> wrote:<br>> On Mon, Mar 6, 2023, 10:40 Jacob Lifshay <<a href="mailto:programmerjake@gmail.com">programmerjake@gmail.com</a>> wrote:<br>>><br>>> On Mon, Mar 6, 2023, 10:10 Jacob Lifshay <<a href="mailto:programmerjake@gmail.com">programmerjake@gmail.com</a>> wrote:<br>>>><br>>>> On Mon, Mar 6, 2023, 04:10 Luke Kenneth Casson Leighton <<a href="mailto:lkcl@lkcl.net">lkcl@lkcl.net</a>> wrote:<br>>>>><br>>>>> * carryless mul/div/mod<br>>>><br>>>> these are basically good to go, though imho are less critical so can be left for later when we need a break from more complex stuff.<br>>><br>>> imho carryless mul should be left till after submitting basic SVP64 FFT support, otherwise `cltmadd` has little justification as a scalar op.<br>><br>> alternative idea: submit everything but cltmadd to avoid someone else submitting an alternative clmul first in a way that doesn't work well with our proposal. cltmadd can then later be submitted as a separate RFC as SVP64 FFT support for clmul.<br><br>ack, makes sense.<br><br>ohh yargh, integer DCT/FFT maddsubs need designing as well,<br>that'll be fun as bitlevel accuracy is needed, ARM even divides<br>by 2 and rounds so as not to drop too many bits.<br><br>l.<br><br><br>-- <br>---<br>crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68" target="_blank">https://www.crowdsupply.com/eoma68</a><br><br>