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" gar...@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
> e...@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
