Am 24.03.2019 um 11:33 schrieb J. Gareth Moreton:
> The main thing is the degree of control you have using pure assembler over
> intrinsics, and someone brought up that
> intrinsics don't give you good access to the FLAGS register.
Juggling with the flags is rarely possible on x86 anyways as
The main thing is the degree of control you have using pure assembler over
intrinsics, and someone brought up that intrinsics don't give you good
access to the FLAGS register. Additionally, unless you do some rather
untidy nested parameter chaining (calling an intrinsic and passing its
result
J. Gareth Moreton schrieb am So., 17. März
2019, 22:26:
> I do have a slight concern when it comes to intrinsic support, because
> support will be needed to be added for all platforms, (virtually) all
> instructions and tested to see if they expand into the expected
> instruction, along with
Speaking of POPCNT, there's an interesting webpage here regarding assembly
v. intrinsics in C++: https://danluu.com/assembly-intrinsics/
One point that's been raised is that on older Intel processors, POPCNT has
a bug in that it has a false dependency on the destination register, so it
will
Am 17.03.19 um 21:37 schrieb J. Gareth Moreton:
My take on the whole "inlined assembler routines" vs. "intrinsics"...
why not both?
Maintenance effort.
They both fill a different niche,
What niche do inline assembler routines fill, intrinsics dont't ? This
is imo the central question.
My take on the whole "inlined assembler routines" vs. "intrinsics"... why
not both? They both fill a different niche, and as I've stated, my
feature doesn't replace intrinstics because you can't directly encode
SHUFPS with them, for example.
Me personally, if I'm going to be playing around with
True, the assembler reader needs to be programmed to recognise new
instructions - I myself implemented BMI a few months ago. That's an issue
with all assemblers... they need to be updated when a new instruction set
comes out.
I do have a slight concern when it comes to intrinsic support,
> On Mar 16, 2019, at 10:25 PM, J. Gareth Moreton
> wrote:
>
> I hate to say it, but I've kind of blocked myself with a lot of things... I
> can't make any more peephole optimizer improvements until the x86_64 overhaul
> is merged or outright rejected, and a bug and the "pure" feature are
Hi Ryan,
I haven't forgotten about "pure" functions - that's still definitely an
area of research for me. I got myself a little bit lost because I'm still
trying to work out a solid design plan (for major changes to FPC, I now
write a full specification, which are the PDF files I've attached to
Thank you so much Ben! I'm glad I'm not the only person who gets a kick
out of assembly language programming! There's still a place for it even
in today's world.
I myself have a passion for games development, and it was partly my
driving force behind implementing "vectorcall" for FPC,
10 matches
Mail list logo
