Would code like this be correct?
Procedure FillWord(var x; count: SizeInt; value: Word); assembler; nostackframe; asm { win64: rcx dest, rdx count, r8w value linux: rdi dest, rsi count, dx value } {$ifdef win64} push %rdi .seh_pushreg %rdi .seh_endprologue cmp $0x0, %rdx ... I recall now an assembler routine where RBX was modified midway through a procedure, but instead of pushing and popping it, it was written to a reserved part of the stack (configured in the prologue) and given a .seh_savereg hint - still trying to get my head around all of this! Kit On Thu 30/11/17 04:26 , "J. Gareth Moreton" gar...@moreton-family.com sent: > Ooh right, okay. Thanks for that Sergei. I just put it in somewhat > blindly because the compiler inserts it > for Pascal code after the normal prologue after creating a stack frame, but > complained and threw an error if > I used .seh_pushreg but then neglected to use .seh_endprologue. I agree > that the compiler should complain > if it finds things out of order like I did, otherwise one may not know any > better. > > > I'm still learning the nuances! I'll just fix my code. > > > > Gareth aka. Kit > > > > P.S. Is there any way to remove the other patches from that bug report. > > > > P.P.S. Would you be able to say my advice was plain wrong on the forum post > and correct it, just for the > sake of anyone else who stumbles across it. > > > > P.P.P.S. Any possibility of inserting similar functionality for Intel-style > assembler at some point? > > > > > > > On Wed 29/11/17 14:58 , "Sergei Gorelkin via fpc-devel" > fpc-devel@lists.freepascal.org sent: > > > > > > > > > > > > > > 29.11.2017 15:12, J. Gareth Moreton wrote: > > > > > > > Thanks Christo. > > > > > > > > > > > > > > Apologies for 4 messages coming in at once. > I > > think there were a few technical glitches with > the mailing > > > list. Either way, I have submitted an > updated > > patch to the bug report in question that > corrects the stack > > > unwinding for Windows. Any testing would > be > > greatly appreciated (I'm not in a position to > rigorously test > > > the code for Linux). > > > > > > > > > > > > > > Yeah, I got a little emotional with > Thaddy's > > response (which has since been deleted), partly > because he > > > mocked me a bit for even attempting to use > > > assembly language for optimisation. Granted, I > tend to do more > > > low-level and mathematical programming than > > > higher-level components, where assembler > optimisation can really > > > pay dividends. Plus in a perverted way, I > > > actually enjoy trying to squeeze another > microsecond out of > > > running time! > > > > > > > > > > > > > > Gareth aka. Kit. > > > > > > > > > > > > > > > > > > > I should have read and answered earlier, but > better late than never. > > > > > > > > > > > The x86-64 target (actually, all targets except > i386 and m68k) use concept > > of fixed stack. This > > > means: all changes to the stack pointer are done > at the beginning and at > > the end of procedure. > > > Pushing something in the middle is illegal. The > stack pointer itself needs > > to be aligned only at the > > > point of calling another procedure. As a > consequence, simple procedures > > that don't call other > > > procedures and don't use nonvolatile registers > can have the stack pointer > > misaligned by 8 bytes as > > > it naturally is at the first instruction (such > procedures don't need any > > SEH annotations at all, > > > which is a way to simplify things). > > > > > > Now, several first instructions where is stack > pointer is changed and > > nonvolatile registers are > > > saved is called prologue. It is delimited by > .seh_endprologue directive and > > can be at most 255 bytes > > > in size. > > > > > > The advice given at forum to insert > .seh_endprologue at the very beginning > > is plain wrong. > > > .seh_endprologue must be the last SEH directive > in procedure. Compiler > > probably needs to do more > > > checks and reject SEH directives coming after > .seh_endprologue. > > > > > > > > > > > Regards, > > > > > > Sergei > > > > > > > > > > > > _______________________________________________ > > > > > > fpc-devel maillist - fpc-devel@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 > > > > _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel