Forum > General

[SOLVED] Any cross-platform problems to be aware of while using ASM?

(1/2) > >>

Eugene Loza:
Once upon a time I've had great fun writing games in Turbo Pascal, in the end ending up in >50% of the code written in Assembly. But all of those were targeting my specific computer. Now thinking about reviving some bottleneck optimizations on lower level (e.g. 2D/3D raycasting and pathfinding is my first guess), I wonder how reliable are these things in cross-platform context (especially talking about mobile target, i.e. Android).

First of all FreePascal compiler is by far superior than Turbo Pascal's - so, while back in late 90s I'd get +18% performance just by rewriting "the same thing" in Assembly, now the performance gain is barely noticeable (managed to get +4% on random number generator, and only thanks to reusing registry content, which is definitely not worth the effort and reduction in code readability). In other word, the whole idea of writing Assembly is by far less important now.

But but for me the bigger issue is how well does Assembly snippets in FPC play in cross-platform context? I understand maybe that's a very basic and dumb question :D I mean, apparently there is a difference between 32 and 64 bits. But is there something I have to know on top of that? Or can different targets (AMD/Intel/ARM, etc) have significant differences in Assembly code forcing to have several separate implementations? (In this case I'm not even considering using Assembly, don't have the capacity for that) Or are those only minor things, like "checking if CPU supports the specific function if you use it", e.g. through Cpu unit or compiler directives?

Laksen:
I would not bother with it unless you discover a hotpath by profiling that you can identify clearly could be done better

What you are asking about is both the bit-ness, but also ABI and architecture. They will vary from slightly different (i386 fastcall vs x86_64 win64/sysv psabi) to completely different (x86 vs ARM)

Thaddy:
ARM requires completely different assembler code. Usually you must assume assembler code is not portable, even between the very similar x86_64-win64 and x86_64-Linux64 generated assembler code. On the latter two, you sometimes can get away with very very simple and clear snippets, but if you are not familiar with the different ABI's let it to the compiler to generate the assembly code.
Contrary to popular belief the compiler often generates far better code, that is, unless you are an absolute complete and utter assembler Guru for that particular assembler and the different ABI requirements.
IOW Nowadays, for 99.9% of the programmers, including very good ones, do not attempt assembler. It bites you.

What I mostly do is have the code in pure pascal, compile in -al mode, examine the assembler output and if I see obvious optimizations I can do that by hand. Not often worth the trouble.

marcov:
Yes. For instance the win64 and linux 64-bit calling conventions are also different, so even within the same architecture it might not be the same.

I do use assembler in my work, but very sparingly, and only in large enough blocks (the code contains loops that run many times), typically processing a whole image, or in the case of very complicated transformations a single line of an image.

I never found much use for the typical very short peephole-like fragments of old compilers like TP and old Delphi. They mostly only frustrate the compiler

Usually if it wasn't written to perform well in say Sandy Bridge (2nd generation core) or better, it probably needs a rewrite.

Eugene Loza:
Thank you all! Yeah, that pretty much answers my questions perfectly - too much hassle (including upgrading my Assembly knowledge from late 90s) for my usecase :)

Navigation

[0] Message Index

[#] Next page

Go to full version