<HTML>
<div><style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>True, the assembler reader needs to be programmed to recognise new instructions - I myself implemented BMI a few months ago. That's an issue with all assemblers... they need to be updated when a new instruction set comes out.</div><div><br>
</div><div>I do have a slight concern when it comes to intrinsic support, because support will be needed to be added for all platforms, (virtually) all instructions and tested to see if they expand into the expected instruction, along with determining what happens when you string several intrinsics together (i.e. passing the result of one such intrinsic into the actual parameter of another). I want to say that it will require just as much, if not more, maintenance than permitting inlined assembler routines under limited circumstances, including adding intrinsics for every individual platform's assembly language and showing that it works.<br>
<br>
P.S. I'll make fixes so it bans the use of DB etc in order to emit raw machine code, as well as catch naughty trickery in order to write to the stack via another register (it's easy enough to detect if a register has a dependency on ESP or EBP) - e.g. "mov %rsp, %rax; mov $0, (%rax)" - and trust me... don't try getting around it by setting a register to zero and then ADDING the stack pointer to it!<br>
</div><div><br>
</div><div>Gareth aka. Kit<br>
<br>
P.S. It goes to show though... it's always possible to break assembly language if you try hard enough, whether or not it's inlined. The intention behind the restrictions is to prevent as many accidental causes of it as possible.<br>
</div> <br>
<br>
<span style="font-weight: bold;">On Sun 17/03/19 20:47 , Martok listbox@martoks-place.de sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">Am 17.03.2019 um 18:57 schrieb Florian Klämpfl:
<br>
<span style="color: rgb(102, 102, 102);">> How is it better than intrinsics support (similiar to gcc/icc etc.)?
</span><br>
It *exists*?
<br>
<br>
Remember how long it took to get PopCnt support? How about the rest of the BMI?
<br>
TBM? AES-NI? Newer AVX?
<br>
<br>
Implementation of these would be a lot easier if they could be written in code,
<br>
even with native-pascal implementations as drop-ins for platforms that don't
<br>
support them (or use other mnemonics). Those would just be normal declarations
<br>
(in the RTL or in a package), and not require modifying the compiler for all
<br>
platforms.
<br>
It would also be easier to maintain, as there wouldn't be the need for new
<br>
inlinennodes or entirely different node types.
<br>
<br>
--
<br>
Regards,
<br>
Martok
<br>
<br>
<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>