What about making freepascal virtual machine (FPVM)?

[MikeNovator]

Benefits:
- Compile once, run everywhere. Crossplatform programming experience should tell you the idea of "compile everywhere (for every architecture)" doesn't really work. It never worked and will never work.
- JIT optimizations can potentially allow even higher performance levels (extremely CPU-specific commands can be used, no need to compile for "most common architecture")
- No tracing garbage collection, and therefore no penalties of stupid heuristical memory management.

why are JVM or .NET targets bad:
- you're forced either to use their type systems or hide behind wrappers, no alternatives at all
- you're forced to make language garbage collected even it has different nature
- proprietary VM, "source code" is still bound to non-free basement. License terms can change any day and you can be forced to pay, for ex., for tools you use or even worse - to distribute your product.

Potential bonus:
- moving from pascal language to something more progressive (adding other languages on the same platform as JVM does, for ex.) without need to throw pascal development itself or making it deprecated and legacy.

Do you interested in such feature, thought about something like that or you consider fpc&lazarus complete tool with frozen ideology?

[irfanbagus]

disadvantage :
- your application now become bigger. you must distribute it with fpvm. update only your application or only fpvm might give you problem with incompatibility.
- do you ever heard "write once, debug everywhere" ? every cross-platform programming suffer from that problem, vm or non-vm (native binary).
- your job now become harder. your application now must be tested (and debug) for multiple platform(os/cpu) and multiple version of fpvm.

[MikeNovator]

you must distribute it with fpvm

- yes, redist requirement is probably an issue... for tiny apps. but for large projects it is debatable. ok.

write once, debug everywhere ... vm or non-vm (native binary).

- but native compiling languages (a bit?) more suffer from abstraction leaks. Not because of leaks itself but because of different side effects on different platforms, so one standartized VM platform resolves this by stabilization, you can be sure you know how it works everywhere.

your job now become harder. your application now must be tested (and debug) for multiple platform(os/cpu) and multiple version of fpvm.

- a question of (FPVM) code quality. Standartized ABI + bugs free VM should make job easier, else it will become just impossible.

Anyway, we should pay for convenience. Such disadvantages are the fee.

Well, i feel skepticism about the idea =)

[marcov]

Benefits:
- Compile once, run everywhere. Crossplatform programming experience should tell you the idea of "compile everywhere (for every architecture)" doesn't really work. It never worked and will never work.

This might go for Java and .NET, systems that have at least a chance that the VM is already deployed in the correct version.

If you have to deploy the VM everywhere yourself, it is still a binary drop per target, so it only complicates.

- JIT optimizations can potentially allow even higher performance levels (extremely CPU-specific commands can be used, no need to compile for "most common architecture")

While theoretically true, except a few micro benchmarks there are few proven trackrecords of this aspect.

why are JVM or .NET targets bad:
- you're forced either to use their type systems or hide behind wrappers, no alternatives at all
- you're forced to make language garbage collected even it has different nature
- proprietary VM, "source code" is still bound to non-free basement. License terms can change any day and you can be forced to pay, for ex., for tools you use or even worse - to distribute your product

There are open versions. But versioning of the VM and licensing will happen with any foreign VM. See e.g. GNU projects changing to GPLv3 and not developing the old licensed version further.

- moving from pascal language to something more progressive (adding other languages on the same platform as JVM does, for ex.) without need to throw pascal development itself or making it deprecated and legacy.

I don't like the all-out OOP approach of JVM. I like mixed paradigm languages like Delphi/FPC and C++ more.

Do you interested in such feature, thought about something like that or you consider fpc&lazarus complete tool with frozen ideology?

Both are not true IMHO.  Most lapses in the FPC projects are due to manpower constraints, not ideology.  Being constantly compared to projects with fulltime, paid labour is simply unfair, and trying to make similar changes unrealistic.

Starting a massive reengineering effort won't lighten the manpower problems, but worsen it.

Personally I think the most major problem in FPC's Pascal is container type and generics related. Both FPC and (the most current) Delphi simply do not have equivalents for what is possible in C++.

Though I originally thought the Delphi generics (borrowed from C#) were cleaner, they are IMHO too limited long term.

(for the interested people:  design an ordered container type that can be specialized with either the real or integer type within current Delphi generics constraints. To my best knowledge Delphi can't, and while FPC can (due to the older own attempt at generics that was more C+ oriented), it is not very elegant yet)

[Leledumbo]

Crossplatform programming experience should tell you the idea of "compile everywhere (for every architecture)" doesn't really work. It never worked and will never work.

Quite the contrary, it works for all platforms (arch-os combination) I want to support. I only develop on x86_64-linux, but I can target i386-win32, i386-linux, x86_64-win64, x86_64-linux, arm-android, arm-wince and arm-linux. The only exceptions are i386-darwin because I don't have Mac, but my clients are usually kind enough to lend me their Mac and let me compile the app from source right on the Mac.

Now do you have any evidence of "It never worked and will never work"? No need to look too far actually, you can see FPC and Lazarus theirselves. They're bootstrapping products and you can see yourself where they could run at or generate binary for. Did they "never work and will never work"?

Do you interested in such feature, thought about something like that or you consider fpc&lazarus complete tool with frozen ideology?

Nope, I've worked with managed systems and have enough experience in deployment problem (with both JVM and .NET), not to mention the heavy development requirement and the SLOW execution. As Marco has pointed out, JIT can win in micro benchmarks, but never (to my knowledge) in macro benchmarks.

Furthermore, such a system tend to eat A HELL LOT MORE RAM than natively compiled one. RAM is not cheap (well, not as cheap as HDD, not even SSD) and I don't buy RAM to fit only 1-3 apps. Multitasking handles many more than that and that's what I want my RAM for.

[Paul Breneman]

A month and a half ago I brought up a similar idea:
http://forum.lazarus.freepascal.org/index.php/topic,26315.msg162607.html#msg162607

[marcov]

Leledumbo, Mike excluded garbage collection, so some of the troubles won't be there. Not all Java/.NET problems are due to bytecode/jit, some are due to the relative high level of languages (few native types use) and garbage collection.

But a JIT system will of course always eat more memory than natively compiled, since the JIT compiler itself needs memory too, and with anything new you will take years (if not a decade) to even get to the current native compilers level of performance, before even (IMHO largely theoretic) benefits pan out.

In practice, JIT mostly earns back performance (relative to native) that was thrown out of the window with earlier virtual machine types (the first, very interpretive JVMs)

[Leledumbo]

Leledumbo, Mike excluded garbage collection, so some of the troubles won't be there. Not all Java/.NET problems are due to bytecode/jit, some are due to the relative high level of languages (few native types use) and garbage collection.

OK, that strips down one of its disadvantages. Thanks for noting.

[argb32]

why are JVM or .NET targets bad:
- you're forced either to use their type systems or hide behind wrappers, no alternatives at all
- you're forced to make language garbage collected even it has different nature
- proprietary VM, "source code" is still bound to non-free basement. License terms can change any day and you can be forced to pay, for ex., for tools you use or even worse - to distribute your product.

There is also LLVM. What's wrong with it?

[Basile B.]

why are JVM or .NET targets bad:
- you're forced either to use their type systems or hide behind wrappers, no alternatives at all
- you're forced to make language garbage collected even it has different nature
- proprietary VM, "source code" is still bound to non-free basement. License terms can change any day and you can be forced to pay, for ex., for tools you use or even worse - to distribute your product.

There is also LLVM. What's wrong with it?

LLVM is not a VM, it's a backend / code generator.

[marcov]

There is also LLVM. What's wrong with it?

Mostly used as compiler backend. Did you use it as VM ? I know it exists, but not how mature it is.

[marcov]

LLVM is not a VM, it's a backend / code generator.

Afaik it has a JIT.  gcc is also working on a JIT (it is actually done, maybe already in release 5.0).

But anyway, their runtimes are not widely deployed yet, since their JIT usage is a sideshow, not the main use of the respective suites

[sam707]

exposing methods from classes, classes, and normal procedures or functions you wrote to a pascal script engine like PascalScript, TitanScripter, PaxCompiler INSIDE your application is, to my opinion, much more smarter and pretty efficient.

1st of all, you install the related package, it compiles and embed the script engine for runtime deployment in your app, so theres no overhead around distributing your app

then, you deploy a tiny documentation of the entry points to final users, enabling them to write scripts in pascal like language

finally, I tested it on win32 and linux32, it worked like a charm

that way, you can almost mimic a VM comportment with your own extensions. If time consuming is not a priority it sounds very good! nowadays machines with multi-core do not really care time consuming = you can "pre"compile scripts in a thread and just synchronize the execution at some points that you decided.

the script I used with PascalScript package was successfully many times reused/rerun after the 1st compilation pass. Fast enough for me  then (compiled one time -JIT-, ran many times inside my application)

so I agree with Leledumbo and Marcov on what they pointed out, and I do either not feel the need of a FPVM.

We have Lazarus (already crossplatform), and mixing it with one of the well known script engines can make the job!!! Extensions are FREE, upon ur imagination and programming skill

[argb32]

Mostly used as compiler backend. Did you use it as VM ? I know it exists, but not how mature it is.

I don't need a VM. But a good code generator would be nice.

[sam707]

pascalscript package "compiles" to PCode so its a PCode generator
If I remember, some components are TPersistent descendants so that it is also possible to write PCode streams and run such a "compiled" data sources on another platform without the need to compile (and distribute) original script on target

feel free to check

http://www.remobjects.com/ps.aspx

read the link above and just imagine your OWN VM

flexible, expandable... even has a debbuger