Recent

Author Topic: New idea for FPC JVM  (Read 5129 times)

jiaxing2

  • Full Member
  • ***
  • Posts: 164
New idea for FPC JVM
« on: May 26, 2020, 07:15:06 am »
It currently compiles to jasmin asembly and utilize jasmin + apache bcel + javapp to done the job.

My research soonly showed that jasmin is no longer developed since 2015. Apache bcel is still maintained but the version used by FPC JVM is very old. Javapp is a broken software for me, I have never able to make it to work.

I don't know if the same stack is used on Android development but I saw the Android efforts are pretty much active.

My proposal is abandon jasmin and switch to asm instead: https://asm.ow2.io/

asm is currently active developed and being used for many projects, the most notable is Groovy.

Also have a look at oberonc: https://github.com/lboasso/oberonc

The guy done everything entirely himself, without relying on any third party library like asm. I know oberon is different in nature with object pascal which is more complicated but it worths to have a look at his work.

Another interesting project is gpcp - the component pascal compiler for .net and java: https://github.com/k-john-gough/gpcp

Unfortunately, the software is currently in maintainence mode. But it's the best Pascal family language compiler targets JVM. It relies on asm to done the job. But the most notable thing we could learn from it is the j2cps utility - creating binding for Java library to use with component pascal. You could download the JVM distribution and go to symfiles, check the html documents here, you could start with index.html and you could see they provides complete Java runtime library binding. New binding for other java library could be created easily with j2cps.

I have never able to make our javapp to work. May be we could learn something from this project. As we already admitted on the Wiki, javapp's source code is ugly. So I think a complete rewrite might be feasible, isn't it?

Our current FPC JVM runtime library is too bare metal and having many problems interfacing with Java code. I suggest to break compatibily with the object pascal dialect used by other other frontend (objfpc) completely and create a separate dialect to deal with the JVM and Java interop exclusively.

Final words: it's all depends on the people who actually done the job and all of my proposals are just... proposals. But I'm realy interested on the FPC JVM backend and I hope you - the developer, would have a look at this thread. Thanks.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: New idea for FPC JVM
« Reply #1 on: May 26, 2020, 09:23:29 am »
Final words: it's all depends on the people who actually done the job and all of my proposals are just... proposals. But I'm realy interested on the FPC JVM backend and I hope you - the developer, would have a look at this thread. Thanks.

Feel free to contribute alternative assembler backends.


marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: New idea for FPC JVM
« Reply #3 on: May 26, 2020, 11:24:13 am »
Our current FPC JVM runtime library is too bare metal and having many problems interfacing with Java code. I suggest to break compatibily with the object pascal dialect used by other other frontend (objfpc) completely and create a separate dialect to deal with the JVM and Java interop exclusively.

If you use a non standard backend (jvm) and you want a different frontend (not even discussing how feasible that would be), but what would be the advantage of doing this inside the FPC project at all?

The JVM backend exists as a way to recycle the frontend.
 

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 1058
Re: New idea for FPC JVM
« Reply #4 on: May 26, 2020, 08:27:24 pm »
My research soonly showed that jasmin is no longer developed since 2015. Apache bcel is still maintained but the version used by FPC JVM is very old. Javapp is a broken software for me, I have never able to make it to work.

I don't know if the same stack is used on Android development but I saw the Android efforts are pretty much active.

My proposal is abandon jasmin and switch to asm instead: https://asm.ow2.io/
What issues have you encountered with jasmin that switching to asm would solve?

Quote
Our current FPC JVM runtime library is too bare metal and having many problems interfacing with Java code.
The FPC JVM RTL is indeed bare metal, but what problems are there with interfacing with Java code? That is mostly the easy part. It's supporting all the low level Pascal code that is hard.

jiaxing2

  • Full Member
  • ***
  • Posts: 164

jiaxing2

  • Full Member
  • ***
  • Posts: 164
Re: New idea for FPC JVM
« Reply #6 on: May 30, 2020, 12:41:50 pm »
The JVM backend exists as a way to recycle the frontend.

This cleared any of the ambiguity.
= Don't expect much. This is just a poor man's hack to bring Lazarus/Free Pascal to Android development. As it targets Android - a Java based platform, why don't recycle it for the standard JVM, too? And if it worked, everything is fine. If it didn't work, don't expect anything further. The End.

jiaxing2

  • Full Member
  • ***
  • Posts: 164
Re: New idea for FPC JVM
« Reply #7 on: May 30, 2020, 12:46:02 pm »

What issues have you encountered with jasmin that switching to asm would solve?

It's supporting all the low level Pascal code that is hard.

ASM supports newer Java version. e.g: Java 11. We currently stuck with Java 5. The most important is, ASM is active developed, Jasmin is not.

Not hard. The oberonc guy hacked to make pointers work on the JVM! And he didn't use anything (external assembler like Jasmin, ASM...) other than his own code. Let's be ashamed!

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: New idea for FPC JVM
« Reply #8 on: May 30, 2020, 01:47:46 pm »
The JVM backend exists as a way to recycle the frontend.

This cleared any of the ambiguity.
= Don't expect much. This is just a poor man's hack to bring Lazarus/Free Pascal to Android development. As it targets Android - a Java based platform, why don't recycle it for the standard JVM, too? And if it worked, everything is fine. If it didn't work, don't expect anything further. The End.

The JVM target started out with JVM support. Android support was added later on.


What issues have you encountered with jasmin that switching to asm would solve?

It's supporting all the low level Pascal code that is hard.

ASM supports newer Java version. e.g: Java 11. We currently stuck with Java 5. The most important is, ASM is active developed, Jasmin is not.

So what? FPC does not use newer functionality. So even if we'd use asm, that wouldn't change anything as FPC wouldn't be able to make use of any new functionality.

Not hard. The oberonc guy hacked to make pointers work on the JVM! And he didn't use anything (external assembler like Jasmin, ASM...) other than his own code. Let's be ashamed!

First of it's questionable whether it is a good idea to make Pointers work on a platform that's not supposed to use pointers. Just because it works does not mean it's good.

Second the Oberon guy might have had more time that he could dedicate to his project not to mention that his project only supports the JVM. FPC is a much bigger project and supports multiple different CPU targets with the JVM just being a single one and that alone meant huge restructuring of the compiler (especially the introduction of the High Level Code Generator which now benefits the LLVM and WebAssembly backends as well). Using an existing tool to generate binary files is totally legitimate and nothing to be ashamed of. It's how FPC is structured. The Windows target at first used GNU as and ld as well. The internal assembler and linker were only developed later on.

So if it bugs you so much that FPC relies on Jasmin, then provide an internal assembler backend for class files, please.

 

TinyPortal © 2005-2018