<HTML>
<div><style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>The main thing is the degree of control you have using pure assembler over intrinsics, and someone brought up that intrinsics don't give you good access to the FLAGS register. Additionally, unless you do some rather untidy nested parameter chaining (calling an intrinsic and passing its result into another intrinsic, several layers deep), you don't have too much control over how the results are stored. Normally not a terrible thing, but if you have a temporary value that you know will be discarded, you want it in a register and never stored on the stack, for example.</div><div><br>
</div><div>I know you keep saying the compiler should be smart enough to determine that, but it's not. It's not even smart enough to merge nearby "div" and "mod" instructions with the same denominator, and putting individual cases in the peephole optimizer can only go so far before you have to redesign it from the ground up (things like "full tree optimization"), and there comes a point where you can put so many possible
optimisations into a compiler that it becomes prohibitively slow or take
up too much memory... the main problem is that optimisation as a whole
is NP-complete. You'll never get everything, and assembly language is the only way to be sure you're making the most efficient code in specialised situations where speed is of paramount importance.<br>
</div><div><br>
</div><div>There's also the issue of maintenance... writing intrinsics for every single possible instruction on every single platform and determining that they behave in the way they should.</div><div><br>
</div><div>I guess we have been spoilt in a way because Pascal has always supported a clean and efficient way to drop into assembly language if you so choose, and this is what I've gotten used to rather than the intrinsics of C++. I don't like the idea of putting breakpoints on the intrinsics and opening up the Disassembly window just to check that the compiler isn't blindly storing temporary values on the stack.</div><div><br>
</div><div>If I had to give one final reason... there are already functions in the RTL that are written in pure assembly language that would easily benefit being inlined, such as SwapEndian and Trunc. Otherwise they'd have to be rewritten to use intrinsics if anyone remembers to.<br>
</div><div><br>
</div><div>There is one other thing... intrinsics haven't been merged into the trunk yet, so we can't test them or determine if they are actually what we desire.</div><div><br>
</div><div>Gareth aka. Kit<br>
</div><br>
<br>
<br>
<span style="font-weight: bold;">On Sun 24/03/19 09:45 , Florian Klämpfl florian@freepascal.org sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">Am 18.03.2019 um 02:57 schrieb Ben Grasset:
<br>
<span style="color: rgb(102, 102, 102);">> On Sun, Mar 17, 2019 at 1:57 PM Florian Klämpfl <florian@freepascal.org <<a="" href="mailto:florian@freepascal.org">florian@freepascal.org>> wrote:
</florian@freepascal.org></span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> How is it better than intrinsics support (similiar to gcc/icc etc.)?
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> Well, it wouldn't be better than a literal equivalent to those intriniscs, if that's what we're talking about. By which
</span><br>
<span style="color: rgb(102, 102, 102);">> I mean, like, say how in Clang/GCC (or languages such as Rust that use LLVM), if you do _mm_loadl_pd or whatever, that
</span><br>
<span style="color: rgb(102, 102, 102);">> translates not to a function call but directly to the "inlined" assembler instructions (at least in release builds.)
</span><br>
<br>
Yes, that's what I mean. So far I have not seen a single advantage of inlining pure assembler routines over such intrinsics.
<br>
_______________________________________________
<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<br>
<a target="_blank" href="<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span></a>
<br>
<br>
<br>
</blockquote></HTML>