Hello! I'm in the Lazarus list, but I'm new to this one.

Are there FPC versions for these virtual machines?

Java
Flash 8 (actionscript 2)
Flash 9 (actionscript 3)

If the answer is no, I'd love to create compilers for those virtual platforms. I want to see Pascal applications running on them. :D

-Marco

The answer is no.

I'd love to create compilers for those virtual platforms.

Java will be hard, because it doesn't support plain pointers. I don't known ActionScript. Anyway, you're welcome to try :)

Jonas

Flash is a virtual machine. Flash 9 is a complete re-write. There are Flash assemblers available. Flash doesn't use "ActionScript"* at run tme, the code is compiled to bytecode, just like Java.

As a proof of concept (and interesting aside) see: http://community.netikatech.com/faq/ - it's a C# compiler targeting Flash (well, and Silverlight..)

* I believe is *is* possible to dynamically compile Action Script, and the older Flash runtimes were tied to Action Script more than Flash 9. Dunno, I just dabbled with Goa (as a pretty much full time C# programmer) and have used Flex 2 and Flex Builder (which is actually a really cool platform.)

M

Whether or not it's a virtual machine, and whether or not an assembler is available is not that important. What usually matters most is whether you can map all FPC concepts (or at least the ones you want to support) on the target (virtual or not) architecture.

Jonas

Thanks for your replies. I'll do an Object Pascal specialiced translator and take advantage of the open-source and SDK's compilers for those virtual machines. I'll make it as compatible with FPC's RTL and the LCL as possible.

-Marco

2008/2/7, Jonas Maebe :

Jonas Maebe wrote

Whether or not it's a virtual machine, and whether or not an assembler is available is not that important. What usually matters most is whether you can map all FPC concepts (or at least the ones you want to support) on the target (virtual or not) architecture.

Well, no, there are two approaches. (1) Replicate pascal syntax and follow basic concepts, (2) Replicate system verbatim. If the choice is (1) or nothing, I'd take (1) every time. This is why Goa works. It is not 100% compatible with standard C# (MS nor Mono), but I can take a project and convert it to something that does work. The basic concepts are there, and enough of the support library to make it fairly painless. If I was still as obsessed with Object Pascal as I was in 1998 - 2004, I'd far rather have a compiler that enabled me to re-use my skills - albeit with caveats and differences, than learn a completely new language from scratch. This is why I was initially excited about Chrome. However, as always, YMMV.

I have always followed the belief that, whilst FPC does what it does very well, sometimes simplification isn't a bad thing. Portability across platforms - with caveats, obviously, would be a nice addition.

Matt Emson wrote

I have always followed the belief that, whilst FPC does what it does very well, sometimes simplification isn't a bad thing. Portability across platforms - with caveats, obviously, would be a nice addition.

At this time, the compiler cannot supporting systems which lack certain architectural features (e.g., several internal transformations introduce address/pointer expressions in code which does not contain any pointers whatsoever at the Pascal level). While it is possible to override these, it would be much more difficult then just disabling a couple of things in the parser for certain targets.

Jonas

Okay, this is becoming off topic - sorry. To support Flash, I would assume a cross compiler would be used. Does that still have the same issues? I don't think a natively (as in Flash VM) compiled compiler would really do anything useful. All the Flash/Flex stuff Adobe/Macromedia produced is in Java pretty much. Others have used C or Java too. All tools target, but don't run on, the VM.

Not really, although fpc-devel might be more appropriate.

To support Flash, I would assume a cross compiler would be used. Does that still have the same issues?

Yes, I was only talking about the generated code, not about the compiler sources themselves. A simple example is in case you use

writeln(textpara,inta,intb);

Internally, this is replaced by

;
fpc_write_text_sint(tempptr^,a);
fpc_write_text_sint(tempptr^,b);
fpc_writeln_end(tempptr^);

The reason is that textpara could be a function call, and in that case it must be called only once rather than thrice (and yes, internally the compiler can take the address of function call results, and no, as a programmer you are not allowed to do that :)

Jonas