[fpc-devel] Regarding issue/patch 0032637

[J. Gareth Moreton]

With no further objections, I've uploaded the patch to https://bugs.freepascal.org/view.php?id=32637 - it is 
prefixed with "STACK_FRAME_" - ignore the other 3 patches, as they're incorrect.

Gareth aka. Kit


On Thu 30/11/17 04:47 , "J. Gareth Moreton" gareth at moreton-family.com sent:
> 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
> eth at 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 at 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 at lists.freepascal.org
> > > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > 
> 
> > 
> 
> > _______________________________________________
> 
> > 
> 
> > fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> 
> 
> 
> 
> 
>