<HTML>
<style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>I guess there's no place for me here. I don't have the facilities or knowledge to develop beyond i386 and x86_64, and there's too much conflict. You win. What am I but a rowdy tyke who doesn't listen to his elders and betters?<br>
<div><br>
</div><div>Everyone talks about the wonders that are intrinsics, but they aren't in
the trunk, so as far as I'm concerned, they don't exist.</div><div><br>
</div><div>I guess I don't understand the philosophy of FPC after all, or can even program well.<br>
</div><div><br>
</div><div>Gareth<br>
</div><br>
<br>
<br>
<span style="font-weight: bold;">On Mon 18/03/19 23:34 , Jonas Maebe jonas@freepascal.org sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">On 18/03/2019 22:07, J. Gareth Moreton wrote:
<br>
<span style="color: rgb(102, 102, 102);">> On Mon 18/03/19 20:23 , "Jonas Maebe" <a href="mailto:jonas@freepascal.org">jonas@freepascal.org</a> sent:
</span><br>
<span style="color: rgb(102, 102, 102);">>> Similarly, replacing return instructions with jumps is something
</span><br>
<span style="color: rgb(102, 102, 102);">>> you cannot do.
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> Why not?
</span><br>
<br>
Because parsing and trying to understand the meaning of inline assembly
<br>
is something that is not supportable. Not even the most advanced
<br>
disassemblers and reverse-engeneering tools can do this with 100% certainty.
<br>
<br>
You can add a lot of fallbacks and safety checks, but even if you manage
<br>
to get those airtight in the end, then the feature will have a bunch of
<br>
limitations that are not necessarily foreseeable by users. This will
<br>
lead to more irritation and bug reports than knowing in advance that
<br>
something is not possible at all, because programmers will first waste
<br>
time on trying to get it to work.
<br>
<br>
Additionally, if you support parsing the inline assembler code on one
<br>
platform, you have to support it on all platforms. That is simply how
<br>
FPC gets developed. "Most users use platform X so we don't need to
<br>
support it for the rest" (or at least consider in advance how well it
<br>
can be supported for the rest) is not how we do things.
<br>
<br>
<span style="color: rgb(102, 102, 102);">> True, this "inline" for pure assembler procedures takes it one step
</span><br>
<span style="color: rgb(102, 102, 102);">> towards a higher-level language, but this is another reason why what you
</span><br>
<span style="color: rgb(102, 102, 102);">> can do is limited. In terms of control and power, I put it between
</span><br>
<span style="color: rgb(102, 102, 102);">> true, raw assembly language and intrinsics, since you're limited to
</span><br>
<span style="color: rgb(102, 102, 102);">> volatile registers but have much more control on where temporary values
</span><br>
<span style="color: rgb(102, 102, 102);">> are stored. I simply wish to develop a tool for programmer who need
</span><br>
<span style="color: rgb(102, 102, 102);">> that raw speed and control using semantics that already exist, while
</span><br>
<span style="color: rgb(102, 102, 102);">> making it as safe as possible. I myself have a number of uses for the
</span><br>
<span style="color: rgb(102, 102, 102);">> feature, and I can see where the RTL can benefit too.
</span><br>
<br>
I don't dispute that there are uses for this functionality. However, I
<br>
disagree that this is the best, or even a good, way to address those needs.
<br>
<br>
<span style="color: rgb(102, 102, 102);">> By the way, I updated the patches to patch the trick of assigning RSP to
</span><br>
<span style="color: rgb(102, 102, 102);">> another register and then deferencing that, and literal byte values via
</span><br>
<span style="color: rgb(102, 102, 102);">> DB etc are now forbidden. I do invite you to try to break it. (It is
</span><br>
<span style="color: rgb(102, 102, 102);">> overly conservative though... if you do something like MOV RAX, RSP
</span><br>
<span style="color: rgb(102, 102, 102);">> followed by MOV RAX, RDX (so it no longer depends on RSP) then
</span><br>
<span style="color: rgb(102, 102, 102);">> derefencing RAX, the compiler will still consider it writing to the
</span><br>
<span style="color: rgb(102, 102, 102);">> stack and forbid inlining - after all, you're obviously trying to do
</span><br>
<span style="color: rgb(102, 102, 102);">> something unusual)
</span><br>
<br>
You can still write that register to memory and then load the value in
<br>
another register from memory.
<br>
<br>
<span style="color: rgb(102, 102, 102);">> I hope that our philosophies don't conflict. I'm worried. I want to
</span><br>
<span style="color: rgb(102, 102, 102);">> find the balance between tradition and revolution, for lack of a better
</span><br>
<span style="color: rgb(102, 102, 102);">> term. If you're not allowed to do something, or something must be done
</span><br>
<span style="color: rgb(102, 102, 102);">> in a particular way, I ask "why?".
</span><br>
<br>
Several reasons have been given in this thread already:
<br>
* many of these things can be done equally as well or better using
<br>
(potentially cpu-specific) intrinsics. Additionally, intrinsics have the
<br>
advantage that they can generate different code at compile time
<br>
depending on the selected target processor (or give an error if the
<br>
target processor does not support them) rather than crash at run time,
<br>
and since they integrate in the code generator they can for better
<br>
overall code quality. Not today, but definitely in the future. With
<br>
inline assembler, especially inline pure assembler routines, you will
<br>
forever be limited to hardcoded registers. The compiler is almost 28
<br>
years old by now. While in the beginning a lot of short term quick-win
<br>
things were implemented, we have paid the price for those over the years
<br>
in terms of maintenance, have to rewrite them, having to support them
<br>
when adding support for new architectures/platforms etc.
<br>
* parsing assembly code and trying to understand what it does, or at
<br>
least figuring out it does not do anything dangerous, is insanely
<br>
difficult. At the same time, all of those limitations will reduce the
<br>
possible use cases for the result
<br>
* allowing optimizers to interact with inline assembly (apart from
<br>
constraints-related values) must never be done, because it is impossible
<br>
to guarantee that the result will be correct.
<br>
* my previous explanations for why allowing inlining of plain Pascal
<br>
procedures with assembler blocks is more logical, safer (does not need
<br>
any extra checks), portable (because no target-specific code other than
<br>
saving/restoring the tai's from/to ppu-files) and maintainable.
<br>
<br>
<br>
Jonas
<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>