How and where can I write ARM Assembly codes in Embarcadero Delphi XE5 with Android?
That would be the best, if I can write it inline.
Delphi mobile compiler do not support the asm ... end blocks.
But the "old good way" is still available, since we are talking about a Native compiler.
What you can do is compile your own module with an external assembler (e.g. GNU AS), then link it to your Delphi XE* application.
For instance, System.RTTI uses low-level asm tricks via external statically linked files:
procedure RawInvoke(CodeAddress: Pointer; ParamBlock: PParamBlock);
external 'librtlhelper.a' name 'rtti_raw_invoke';
procedure RawIntercept;
external 'librtlhelper.a' name 'rtti_raw_intercept';
Take a look at this Japanese article - Google translate is your friend!
It is not possible.
Use Atomic Instrinsics Instead of Assembly Language.
Quote:
The Delphi mobile compilers do not support a built-in assembler.
The Delphi mobile compilers do not support inline assembler. The documentation makes this clear:
The inline assembler is available on:
DCC32.EXE, the Delphi Command Line Compiler
DCC64.EXE, the Delphi 64-bit Command Line Compiler
DCCOSX.EXE, the Delphi Cross Compiler for OS X
You'll need to find an assembler to create something that the Delphi mobile compiler can consume, for instance a shared library.
You can not.
LLVM - which is the engine behind Delphi Mobile - has its kind of an assembler language: http://llvm.org/docs/CommandGuide/llvm-as.html
But it would hardly be ARM kind or x86 kind, since LLVM tries to be CPU-agnostic.
Anyway Delphi officially has no support neither for CPU-native assembling language nor for LLVM kind of it.
http://docwiki.embarcadero.com/RADStudio/XE4/en/Migrating_Delphi_Code_to_iOS_from_Desktop#Use_Atomic_Instrinsics_Instead_of_Assembly_Language
http://docwiki.embarcadero.com/RADStudio/XE4/en/Using_Inline_Assembly_Code
Related
While working on a project we were having 4000+ warnings.
To remove some of those I found one compiler Directive as NEXTGEN.
After Using this directive I found that there is a much more minimize in the warnings to 257.
I want to know if we have any issues in using the compiler directive. Are there any drawback of this directive for my windows application.
I am using Delphi 10.
on Site of Embarcadero I found very less information.
Can anyone tell me something about the same?
Delphi's NEXTGEN conditional symbol marks the next-generation ARC compilers. The Windows and OSX compilers are not NEXTGEN compilers. The iOS and Android compilers are NEXTGEN. Initial release of Linux compiler in 10.2 Tokyo had NEXTGEN defined, but since 10.3 Rio it does not.
Any code compiled for Windows that is marked with NEXTGEN will be ignored in current compilers.
See Conditional symbols:
Defined for compilers (such as the Delphi mobile compilers) that use
"next-generation" language features, such as 0-based strings.
New in XE4/iOS
Update: 10.4 Sydney
NEXTGEN symbol has been removed from all compilers, along with AUTOREFCOUNT and WEAKINSTREF symbols.
The NEXTGEN conditional symbol is defined by the compiler. It is defined, for instance, for the mobile compilers that use ARC. It is not defined for the traditional Windows and Mac OS compilers.
You must not define it in your code. You are compiling your code with a traditional compiler, not a NEXTGEN compiler. Whatever is responsible for these compiler warnings, defining NEXTGEN is not the solution.
I am running Delphi XE8 and have the GetIt AsyncPro for VCL 1.0 installed. It works fine when I compile my application for 32 bit but fails for 64 bit.
The failure is:
[dcc64 Error] OoMisc.pas(2771): E2065 Unsatisfied forward or external declaration: 'Trim'
When I open OoMisc.pas is see:
{$IFNDEF Win32}
function Trim(const S : string) : string;
{$ENDIF}
The Trim function does not seem to be defined. The unit does have SysUtils in its uses clause.
AsyncPro supports only Win32 platform. It cannot be used as-is for Win64 bit.
It contains plenty of 32bit inline ASM code that would have to be replaced either by Pascal code or ported to 64bit ASM code. Besides that part there might be other incompatibilities with Win64 bit platform.
Converting 32-bit Delphi Applications to 64-bit Windows - Inline Assembly Code
If your application contains inline assembly (ASM) code, you need to
examine the ASM code and make the following changes: Mixing of
assembly statements with Pascal code is not supported in 64-bit
applications. Replace assembly statements with either Pascal code or
functions written completely in assembly.
Porting assembly code from IA-32 to Intel 64 cannot be done by simply
copying the code. Consider the architecture specifics, such as the
size of pointers and aligning. You may also want to consult the
processor manual for new instructions. If you want to compile the same
code for different architectures, use conditional defines. See Using
Conditional Defines for Cross-Platform Code in "Using Inline Assembly
Code."
RAD Studio supports Intel x86 through SSE4.2 and AMD 3dNow, and for
x64, Intel/AMD through SSE4.2.
Using Inline Assembly Code
Update:
There is Win64 port of AsyncPro provided by Johan Bontes:
I have a version for Win64 on my Github:
https://github.com/JBontes/AsyncPro
It compiles, but I have not been
able to test it comprehensivly. Feel free to file an issue if you get
stuck anywhere.
I bet that is a relic from Delphi 1 when Win32 was used to distinguish from Win16. You may safely remove those lines.
I converted AsyncPro to XE8 but it only supports Win32.
OoMisc.pas had a Trim function, that was removed from the implementation part. However somebody forgot to remove it from the interface part. That didn't hurt for x32 because it was inside of the $IFNDEF.
Win32 is not defined for x64, so the compiler will complain. The solution for this particular issue is to delete the following 3 lines that were intended for Delphi 1.0.
{$IFNDEF Win32}
function Trim(const S : string) : string;
{$ENDIF}
Of course that does not make AsyncPro compatible with x64 as there will be other issues.
I am working on a C++/Win32 project, and I have some Delphi code from some other (not mine) project that is relevant, and I want to convert it to C++ and integrate into my project.
Keep in mind I have no experience with Delphi.
What's a good and user-friendly Delphi complier? I don't mind about command line or GUI, as long as it's clear to use.
The only Delphi compiler is the Delphi compiler. It's not free. There is the Free Pascal Compiler, FPC. That is, as its name suggests, free. FPC can compile most Delphi code but be aware that many Delphi libraries, e.g. the VCL, are not available for FPC.
I do not know whether this would be too painful for you you to convert the source code in C++ manually.
But have you tried Lazarus? It is intended to be an open source equivalent of Delphi.
Hope it helped.
The previous responses here were all valid in 2012, but things have changed.
Nowadays there is a free (as in beer) Community Edition:
https://www.embarcadero.com/products/delphi/starter/free-download
My 32 bit Delphi 2010 application links to a number of C object files using the $LINK compiler directive. Can I do this in Delphi XE2 when targetting 64 bit?
I am currently compiling using bcc32 version 5.5, but I don't mind which compiler I use if it turns out that the Embarcadero C compiler does not yet output 64 bit objects.
Yes. You must compile the "C" objects files to COFF format. This usually means either the Intel and/or MSVC++ compilers. The same caveats apply to 64bit object file linking that apply to 32bit. You must ensure that all external references are properly resolved, either by providing another .obj which has that symbol, or from Delphi code. When building the "C" code, make sure you disable any stack checks or other run-time verification code generation. Many times such codegen relies on a specific version of the C/C++ RTL from the given tool.
Something else worth noting is that while Delphi 64bit can link to COFF object files (eventually it will also support ELF64), 32bit Delphi supports linking with C++Builder built OMF object files and, new to XE2, 32bit COFF object files which can be built with MSVC++. The same caveats apply.
Yes, you can link to OBJ files in 64-bit XE2 projects, but the OBJ files have to be 64-bit code.
Why isn't anyone developing QT bindings for Delphi.
In the past we had QT 2.x integrated as CLX in Delphi.
I really hate the CLX wrappers since they were buggy and hard to extend.
But why isn't anyone making an API list of external DLL calls to use (the same way JCL wraps the Windows API).
Is it so hard to code such API function mapping? Or maybe the QT classes cannot be exposed to non-C callers?
Any hint in this direction is welcome.
qtintf.dll seems to be the flat API DLL you're looking for and Qt.pas the corresponding import unit.
I recommend you wait for VCL+, that is the Qt binding coming with the next version of Delphi.
The problem is that Qt is heavily macro-based and C++ based. So the Qt "flat API" is quite verbose and big. I wonder how EMB will create its own VCL+ binding, but I'll definitively wait for their implementation for using Qt on any Delphi project.
If you can't wait, and really want cross-platform User Interface (with Mac O$ support), I recommend using http://www.twinforms.com/products/wxformsdelphi and not Qt. It relies on a separate DLL, but it's easier to develop, and well maintained/documented.
I managed to port the qt4.pas from
http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html.
It is originally written for Lazarus but I managed to port it to Delphi.
One must do the following
declare
type
PUInt = ^Integer;
PTRUINT = PUInt;
PtrInt = ^Integer;
PPtrInt = ^PtrInt;
comment out all calls with "qword" paramters since quad-words are not supported in Delphi
comment out "{$mode objfpc}{$H+}" since this is Lazarus stuff
replace all "cdecl; external" with "cdecl; overload; external"
Than the demos can be compiled and run just fine with Delphi.
From what I've heard, apparently the cross-platform component library for Delphi XE2 (version due out next year) will be QT based, sorta like CLX only it should actually work right.