Jump to content
kaarigar

How to compile against ASM versions of System unit code?

Recommended Posts

The System unit has various conditional compile flags etc. One of them is PUREPASCAL define that I want to undefine so that ASM versions of the System functions would be compiled. I am specifically interested in the Pos function. The PUREPASCAL gets defined at the beginning as 

{$IF defined(CPUX86) and defined(ASSEMBLER)}
  {$DEFINE X86ASMRTL}
{$ELSE}
  {$DEFINE PUREPASCAL}
{$ENDIF}

How can I ensure that the PUREPASCAL doesn't get defined? I have tried and define CPUX86 and ASSEMBLER defines, but that doesn't seem to work. Does this require modifying the System unit? Any help is greatly appreciated.

Share this post


Link to post

What is your target platform?

If it is Win32, the ASM version will be chosen. 

  • Like 1

Share this post


Link to post

I am compiling for Win64 target in Delphi Alexandria with latest update/patch. The intention is to have faster code with the help of assembly code, but I am not sure if that's what is achievable with what I am attempting.

Share this post


Link to post

If there are faster asm versions in the system unit, that work on x64, then they will be used. But you can't compile an x86 asm procedure in x64 and expect it to work. You need a bespoke x64 version. 

 

In other words, I don't think what you describe is going to be possible. 

 

What is your specific performance issue? 

  • Like 1

Share this post


Link to post

The PUREPASCAL Pos code in Delphi 11 has been changed to a more optimised version, in fact the same code that the ASM version is based on. Using the PUREPASCAL version even in WIN32 would give the same execution speed as the ASM version. 

  • Like 1
  • Thanks 1

Share this post


Link to post

This is a pointless endeavor unless you have some proof that the new code in Delphi 11 has a performance regression - the generated assembly code for the purepascal code is almost identical to the handwritten version before on x86 and all other platforms it should be significantly faster than the previous pure pascal implementation. (I should know - I did that change)

  • Like 3
  • Thanks 2

Share this post


Link to post
7 hours ago, Stefan Glienke said:

This is a pointless endeavor unless you have some proof that the new code in Delphi 11 has a performance regression - the generated assembly code for the purepascal code is almost identical to the handwritten version before on x86 and all other platforms it should be significantly faster than the previous pure pascal implementation. (I should know - I did that change)

Thank you for your response. No, I don't have any proof, nor do I know any assembly to even look for any proof or done any benchmarks. I was assuming that the the presence of the ASM blocks would indicate that it's purpose was to make code more efficient in terms of execution.

Share this post


Link to post
10 hours ago, David Heffernan said:

If there are faster asm versions in the system unit, that work on x64, then they will be used. But you can't compile an x86 asm procedure in x64 and expect it to work. You need a bespoke x64 version. 

 

In other words, I don't think what you describe is going to be possible. 

 

What is your specific performance issue? 

Yes, my mistake in asking mixing up X86 code with x64.

 

It's not really any performance issue that I have run into as such - it's that my application repeated search on strings inside a loop - and depending upon situation, there could be billions of computationally generated strings. I was checking that sure that the Pos function that gets called repeatedly is efficient.

Share this post


Link to post
17 hours ago, Leif Uneus said:

What is your target platform?

If it is Win32, the ASM version will be chosen. 

Yes! I misinterpreted that the conditional compile was for x64. My bad.

Edited by kaarigar

Share this post


Link to post
2 hours ago, kaarigar said:

It's not really any performance issue that I have run into as such - it's that my application repeated search on strings inside a loop - and depending upon situation, there could be billions of computationally generated strings. I was checking that sure that the Pos function that gets called repeatedly is efficient.

You should profile your program to find out where the bottleneck is. Human intuition is usually wrong in such matters. 

  • Like 3

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×