What is the current state of Windows Phone 8 for FPC?

Also, would anyone have interest in support Flash as a FPC target? It is possible to compile C++ to .swf, so having the same capacity for FPC would be great!
There is a open source project called FlashPascal that does exactly this, I've contacted the developers but sadly they abandoned it, and that compiler only supports a small subset of object pascal.

In theory adding Windows Phone should be simple no? It is a ARMv7 target, we already support this.
In the other hand Flash would be a completly new arch, that could take a year or more, and I'm guess there is not really that much interest in such target.

If not, anyone interested in trying to add support for any of those two platforms?
I'm willing to pay for someone to add either those targets to the compiler, as I really want to port my existing games for both Windows Phones and for the web via Flash.

Or if anyone is willing to take me as a FPC apprentice I can try to do it myself.
I'm am a experienced programmer, just don't know much about FPC internals. Sadly there is not enough documentation for an outsider to be able to do such thing without spendings months just studying the compiler source.

Isn't it easier to convert pascal code to ActionScript and then feed it to the SWF compiler?

http://en.wikipedia.org/wiki/SWFTools

thanks,
Dmitry.

Adding a new target OS for a known CPU is definitely simpler (in this case Windows Phone) than adding a completely new backend (in this case SWF). So if I were you I'd start with adding a Windows Phone target, though to be honest I'd first start with a i386-winrt or x86_64-winrt target. WinRT (aka Metro) might not be exactly the same as Windows Phone, but they share many traits and the hard ground work (namely the absolute core APIs that are available) are the same and developing on the PC should be simpler than developing for the phone...

There is a rather rough (and slightly outdated) article on the wiki ( http://wiki.freepascal.org/Porting_Free_Pascal ) which explains how to add a new operating system as a target. That would at least give you a starting point. You'll still need to dig a bit through the compiler's source though...

Regards,
Sven

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.

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 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).

Dmitry, indeed converting Pascal to Actionscript is an alternative solution. I talked about supporting Flash directly with FPC because I've seen that efforts were made into supporting JVM, which is also a VM similar to Flash (albeit JVM is probably more complex).

Adobe added some features to the Flash VM in order to support C++ compilation via their Alchemy compiler, mainly stuff to support pointers and dynamic allocation/deallocation. This stuff is also necessary for Pascal if we want to support the full language instead of just a subset. And I'm not sure if all of those features are exposed in Actionscript, I'lll look into it, right now I'm avaliating the best way to target this platform using Pascal.

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.

Sadly...

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.

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

Thanks Sven, really useful info, the kind of stuff that was missing in the wiki.
I've investigate this throughfully, and decided to go with another aproach, make a translator from Pascal to other languages (C# for now, possibly ActionScript later).
It is like Dmitry said before, this is a better approach. While it would be more interesting to have FPC directly support those targets, having to mess with a compiler that I don't know the internals and also having to debug very low level stuff would be difficult compared to just generate and validate C# code.

I will not start this from scratch, I already have a half done project that I started some months ago, hopefully if I finish this I will announce it somewhere, in case someone also has any use for it.

Sergio,

Not sure if it helps you.There's a project of converting pascal to JavaScript.
The thread about it came up just recently:
http://lists.freepascal.org/pipermail/fpc-devel/2014-April/033689.html

I'm sure you'd find it helpful for Pascal to ActionScript conversion. Besides, you might want to consider html5 canvas a target too, instead of doing Flash.

A strategic question. If you're looking for more system targets for games (I'm guessing you're).
Why Phone 8 and Flash, rather than console platforms? like XBox, Wii or PS?

thanks,
Dmitry

Thanks Dmitry, I will look into this.
However for the moment, html5 would have some problems for me, because as far as I know there is still no proper socket support in Javascript (besides Websockets), and my game is would require this. But, I guess one could use some kind of server layer to connect both. I will try to contact this developer, to see what kind of progress he has done.

And yes, other platforms like next-gen consoles could be a possilibity, given that they are pushing for more indie developers right now. But this is why porting to C# is interesting, as it seems that this seems the language of choice for indie games in consoles (at least in Xbox and PSVita, I did not check the others yet).