I would have allowed writing to the stack with inline assembly functions if a way could be found to ensure that the compiled program behaves the same way whether the function is inlined or called directly (e.g. through a direct CALL or a function pointer), which would otherwise require shifting byte offsets depending on if the function return address was pushed or not, so I decided to just forbid it completely.
If you want to inline regular functions with assembler blocks, you'll need the attached bug fixes. The rest I'll leave up to you. What is Florian's and your vision for Free Pascal? You already have a cross-platform Object Pascal compiler... what's next for it? Does any of my proposals even have a place in that vision, because honestly I don't know if the following is wanted: - pure functions - XML node dump (compiler debugging feature) - I personally need it for pure functions and for fixing #32913. - faster and smarter optimization on x86-64 Gareth aka. Kit On Tue 19/03/19 08:04 , Jonas Maebe jo...@freepascal.org sent: On 2019-03-18 23:41, J. Gareth Moreton wrote: > 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? I don't consider myself to be better than you, and you giving up is not me "winning". You also don't need to develop beyond i386/x86-64, but you do have to take into account that they exist. This means that unless a feature is inherently specific to a particular platform, it has to be generalisable and can be made to function in a predictable way everywhere (within the bounds of defined behaviour; what that is, is defined by the implementer of the functionality, but it should be possible to specify it and preferably with not too many rules, so it can be understood easily by users and other platform maintainers alike). That is not possible for parsing and trying to understand inline assembly using automated means. It is very fragile, which makes specifying the defined behaviour very hard. It needs a ton of exceptions, many of which will be platform specific, which makes its functionality unpredictable. > I guess I don't understand the philosophy of FPC after all, or can even > program well. This is not about your programming skills, those are quite good. It is, however, indeed very much about FPC's philosophy. That said, this particular feature is something that at least most other compilers (even for other languages) don't implement either, afaik. Most of them even don't support defining pure assembler functions inside the host language's source file, and require you to use external assembler files. They do allow you to inline regular functions that contain inline assembly though. Jonas _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org [1] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: ------ [1] mailto:fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
x86_asm_node_fixes.patch
Description: Binary data
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
