4 ms·
Mul/Div are part of the M extension, which any non-trivial/tiny embedded implementation have. The chip in this link for instance supports this extension. Likewi
by legulere 9y ago
Mul/Div are part of the M extension, which any non-trivial/tiny embedded implementation have. The chip in this link for instance supports this extension. Likewise AES and SHA could be supported in a crypto extension.
REP MOVS/STOS is not optimized at all. The Architectures Optimization Reference Manual says that SIMD instructions are faster. The only reasons to use REP MOVS/STOS are to deal with unaligned parts of the data and to not have startup cost from checking if SIMD is available via CPUID when you have only a few bytes. Further the intel manual tells you to not use the other string instructions at all.
> if by definition all instructions already run in one clock cycle
Then you are using a different definition of RISC than RISC-V does
> the key difficulty here being that recognising and combining instruction sequences is much harder than decoding a single instruction to a sequence of uops or dispatching it to hardware internally.
Why is that supposed to be more difficult? Matching combinable instructions is trivial.
- userbinator 9y agoREP MOVS/STOS is not optimized at all That might've been true for a period some time ago, but before and after that it has been the preferred way to do memcpy() or memset() since it can operate on entire cachelines at a time. It's one of the fastest, if not the fastest, and also the absolute smallest (which helps with icache consumption), while leaving the SIMD registers free to do more... useful things than shuffling data around. https://stackoverflow.com/questions/43343231/enhanced-rep-movsb-for-memcpy https://stackoverflow.com/questions/43343231/enhanced-rep-mo... https://github.com/golang/go/issues/14630 https://github.com/golang/go/issues/14630 Why is that supposed to be more difficult? Matching combinable instructions is trivial. How is it "trivial" to match a round of AES or SHA, or a multiplication or division algorithm, or even a memory copy/store loop, so they can be replaced with the optimal hardware implementation...?