[fpc-devel] New targets for FPC - Windows Phone 8 and Flash

[Sven Barth]

On 05.07.2014 14:25, Sergio Flores wrote:
> Sven, I know about this wiki page, and in theory this would be what I
> needed.
> But if you read it, you'll see that once you reach the interesting
> parts, you only find TODO...
> Basically the person who wrote this only wrote a intro to it and sadly
> never finished the rest.

Sadly...

> One thing that is missing is very important is talking about generation
> of code to be passed to the target assembler. I don't know about FPC so
> I don't know if this is something separated into various phases, and if
> there is some kind of intermediate language involved like in LLVM or
> something.

The compiler lowers the node trees into linear assembler lists which are 
either assembled directly by an internal assembler or are written to a 
file on which the real assembler is then called. These assemblers are 
all child classes of TAssembler or more specifically either 
TInternalAssembler for the former and TExternalAssembler for the latter 
(all declared in assemble.pas). For most targets there is a 
TGNUAssembler class (declared in aggas.pas) which inherits 
TExternalAssembler and which is again subclassed by each CPU specific 
assembler.

You can take a look at the patches I had done for adding support for the 
NativeNT target which - like Windows Phone - is a PE target and thus is 
able to leverage much of the compiler infrastructure that is already 
available for Win32/64/CE. You can find them for the compiler here: 
http://bugs.freepascal.org/view.php?id=14886 and for the RTL (on which 
you'll need to work as well) here: 
http://bugs.freepascal.org/view.php?id=14887

> The Flash VM arch is not a general cpu, as it contains some higher level
> opcodes, like opcodes to supporting class inheritance (essential to
> inherit from builtin Flash classes).

It would nevertheless need a completely new backend and thus it's a much 
bigger task.

> Regarding Windows Phone 8, it is not exactly necessary to test it with a
> real phone, as emulators do exist. I investigated more into this,
> Microsoft does supply a arm assembler that generates .obj files, so I'll
> try to see if arm assembler generated by FPC can be directly passed to
> this assembler.
> I do not know yet if it is possible to make a WP8 app entirely in assembler.

I'm aware that emulators for Windows Phone 8 exist, but I meant that in 
a different way. For Windows RT aka Metro the compiler infrastructure is 
basically already there, as we have an internal assembler for i386 and 
x86_64 and an internal linker (ok, that one can be used for WP8 as 
well...). Additionally you'll need to implement a completely new RTL 
anyway as some of the functions the Windows RTL relies on are simply not 
allowed on a WinRT or WP system. And *that* is easier to debug on a PC 
system and if it works sufficiently there you can go for arm-winrt first 
and arm-wp then second (or maybe the differences won't be that big that 
we'd need a new target for WP and can just use the WinRT one...).
For WinRT on ARM or WP you'd need to have the compiler generated ARM 
Thumb code exclusively as we generate Thumb only when we need to and 
then you should be able to use the GNU assembler (for which an output 
generator already exists) or you'd need to write a new one for the 
Microsoft assembler (or maybe reuse the MASM generator? I don't 
know...). You see why I said to start with i386/x86_64-winrt first? You 
have less places where you need to get involved in and thus the chance 
for frustration is lower as you can see results quicker. ;)

Regards,
Sven