Hi Florian, I think the main thing is that Object Pascal has always supported the ability to drop into assembly language, unlike C++ which requires a dialect-specific extension and is not allowed at all under Microsoft Visual C++ 64-bit. Allowing certain assembler routines to be inlined seems like a logical extension using language semantics that already exist.
Part of it may be preference but I think some people like the fine degree of control that assembly language offers, while intrinsics, I find, can quickly get somewhat untidy and confusing, especially with instructions like CPUID that read and write to specific registers (although my code forbids that instruction because EBX is non-volatile). The other thing... no matter how good the compiler is, there are some situations where assembly language will always perform better. I suppose I would like to ask the community more than anything. Is this a feature that you'd like to see and use? I hoped the way that I designed the patch helps to alleviate the can of worms by simply not allowing inline if the platform doesn't have the ability to support it yet. "CanInline" simply returns False unless overridden. Gareth aka. Kit On Sun 17/03/19 17:37 , Florian Klämpfl flor...@freepascal.org sent: > Am 15.03.19 um 11:32 schrieb J. Gareth Moreton: > > > Hi everyone, > > > > > > Sorry for the slightly long-winded title. > This was something I've been > > working on for the past few weeks to allow the > use of "inline" with > > certain x86 assembler routines, subject to > restrictions for safety > > reasons. I have successfully written code > that implements this support > > while ensuring it doesn't affect platforms with > a different assembly > > languages. Regression tests have passed, > as have some new tests, some > > of which test modified RTL assembler functions > that have had "inline" > > added to their list of directives. > > > > As said before, I have a lot of concerns against this as it opens a can > > of worms hard to handle: > > * using inline assembler is always the worst solution to do something, > > it normally means either: > > - the compiler misses a certain feature > > - the compiler is generating bad code > > * intrinsics provide a much better way to achieve exactly what this > > approach aims at: > > - they enable the use of all registers as the compiler does register > > allocation > > - constraints on instructions (like a certain operand needs to be a > > constant) can be easily forced > > > > Is there any advantage over intrinsics, I missed so far? > > > > > > > > There was a previous concern about it breaking > too much and it being > > impossible to implement on all platforms - the > latter point may be true, > > but through the careful use of virtual methods > within the compiler, it > > should be possible to extend the inline support > one platform at a time > > without breaking the others. > > > > > > All the details, including a PDF specification > that explains the design > > and implementation choices, a couple of existing > tests that touch on the > > functionality, along with any new tests, > limitations or problems found, > > can be found here: https://bugs.freepascal.org/view.php? id=35232 > > > > > I hope it proves to be insightful and useful. > > > > > > Gareth aka. Kit > > > > > > P.S. Though this feature can be used for > implementing intrinsics, it is > > not a direct replacement for them because > instructions like SHUFPS > > cannot be flexibly encoded due to its immediate > operand (i.e. it has to > > be a raw number... it can't take its value from > a parameter). > > > Well, with intrinsics, this can be easily done. > > __________________________________________ _____ > > fpc-devel maillist - fpc- de...@lists.freepascal.org > http://lists.freepascal.org/cgi- bin/mailman/listinfo/fpc-devel > > > > _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
