To clarify my last message, what I had said previously was that FPC needs
*either* inlinable assembler *or* intrinsics. Just basically something that
ultimately can be called as a "normal" Pascal function, but that does *not*
end up as an un-inlined function call. I have no preference as to how
On Sun, Mar 17, 2019 at 1:57 PM Florian Klämpfl
wrote:
>
> How is it better than intrinsics support (similiar to gcc/icc etc.)?
>
Well, it wouldn't be better than a literal equivalent to those intriniscs,
if that's what we're talking about. By which I mean, like, say how in
Clang/GCC (or
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
I've actually had this problem myself - sometimes it's quite critical as
well because you might want things like
const
Pi: Double = 3.14159265359;
HalfPi: Double = Pi / 2; TwoPi: Double = 2 * Pi;
Will return the illegal expression error as well, even if Pi is fully
declared elsewhere,
Just wrote some Pascal functions for ClampInt to test it:
function ClampInt1(X: LongInt): LongInt; inline;
begin
if (X < 0) then
Result := 0
else
Result := X;
end;
function ClampInt2(X: LongInt): LongInt; inline;
begin
Result := 0;
if (X > 0) then Result := X;
end;
I just realized that typed constants exist and may need to be supported as
constants for generics but I’ve never used them myself (not sure when they were
introduced).
First test gives an error so it makes me wonder if they’re buggy and should be
allowed for generics. Should they?
const
- Reply to message -
Subject: Re: [fpc-devel] Successful implementation
of inline support for pure assembler routines on x86
Date: 2019. gada 17. marts 19:38:03
From: Florian Klämpfl
To:
> Am 15.03.19 um 11:32 schrieb J. Gareth Moreton:
> * using inline assembler is always the worst
- Reply to message -
Subject: Re: [fpc-devel] Successful implementation
of inline supportforpureassembler routines on x86
Date: 2019. gada 18. marts 00:28:10
From: J. Gareth Moreton
To: FPC developers' list
> To use the integer clamp function as an
example (if x < 0 then x := 0):
I think one of the main issues with intrinsics is that you don't have much
control over where results are stored. Unless you're chaining a load of
intrinsics together in a mess of function calls in actual parameters, the
result is going to have to be stored in a local variable, which even on
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 3/17/19 9:58 PM, Florian Klämpfl wrote:
Am 17.03.19 um 21:47 schrieb Martok:
Am 17.03.2019 um 18:57 schrieb Florian Klämpfl:
How is it better than intrinsics support (similiar to gcc/icc etc.)?
It *exists*?
Remember how long it took to get PopCnt support?
PopCnt is not really an
Am 17.03.19 um 21:47 schrieb Martok:
Am 17.03.2019 um 18:57 schrieb Florian Klämpfl:
How is it better than intrinsics support (similiar to gcc/icc etc.)?
It *exists*?
Remember how long it took to get PopCnt support?
PopCnt is not really an intrinsic as it has a fallback counter part and
Martok schrieb am So., 17. März 2019, 21:47:
> Am 17.03.2019 um 18:57 schrieb Florian Klämpfl:
> > How is it better than intrinsics support (similiar to gcc/icc etc.)?
> It *exists*?
>
> Remember how long it took to get PopCnt support? How about the rest of the
> BMI?
> TBM? AES-NI? Newer AVX?
>
Il 14/03/2019 18:32, Bart ha scritto:
That is not really the issue.
My machine is Win10 on i5 with 8GB memory.
I run Mint in aVirtualBox VM (a bit sluggish, but do-able).
I don't have a Windows installable medium with license that I can
install into a VM.
And I'm not gonna buy it, nor am I gonna
Am 17.03.19 um 18:18 schrieb J. Gareth Moreton:
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.
On 17/03/2019 18:18, J. Gareth Moreton wrote:
Part of it may be preference but I think
some people like the fine degree of
control that assembly language offers,
That is absolutely correct. That is both its strength and its weakness.
The weakness is that it is impossible to integrate such
The other thing is that it will benefit
cross-platform functions like Trunc and
ReadWriteBarrier better, which call only
single assembler commands. One can simply
add "inline" to their platform-specific
implementation for the performance gains
without having to rewrite the routines to
use
Am 17.03.19 um 02:54 schrieb Ben Grasset:
Inlining of pure assembler functions would actually be immediately,
specifically useful to me! I've been having a go at improving FPC scores
on "BenchmarksGames", and was so far successful with Binary Trees simple
by throwing a really good threading
Am 15.03.19 um 14:06 schrieb J. Gareth Moreton:
I mention intrinsics because, according to Florian, someone is already
developing support for them, although I can't remember the SVN
repository off-hand.
https://svn.freepascal.org/svn/fpc/branches/laksen/intrinsics/
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
> 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
On Sat, Mar 16, 2019 at 4:36 PM Michael Van Canneyt
wrote:
> > I can declare the type there as well, but for the compiler these will
> > be 2 different types.
>
> In Delphi yes, but normally not in FPC. If the base type is the same, 2
> array definitions will be assignment-compatible.
Thanks
24 matches
Mail list logo
