Hello,

For the compilers project from my graduation my group managed to get a very simple pascal compiler developed with Free Pascal and generating Java assembler, which is assembled by Jasmin.

When I started it I was thinking about phones which only run Java, and also other phones in general. The only Pascal compiler for J2ME that I know of is MIDLetPascal which seams abandoned. Out of simplicity to test I generated software for J2SE, and the software generated operate in a command line to make testing easier, but from what I've read J2ME is very similar. It should be the same, except for the fact that a different library is used.

My experience was very positive. The Jasmin assembler is excelent, and very easy to use, or at least much easier then any assembler I ever used. One drawback of Jasmin is that it doesn't generate very meaningfull error messages. The JVM is stack based and not register based. I managed to create integer and string type variables, comunicate with terminal, do some basic I/O.

Unfortunatelly I suspect that code sharing with desktop PCs would be very hard, because it's impossible to have pointers. This gives to some doubts about if FPC could be ported to generate Java bytecode.

The files are here:

http://p-tools.svn.sourceforge.net/viewvc/p-tools/fpjava/

All reports and comments are in portuguese. But it should be easy to figure out what every part does.

The existing compiler there should be regarded as anything nearly ready for production, just a very initial prototype. Also note that our professor didn't allow us to use compiler creation tools, like plex and pyacc, so the code is larger then necessary.

I don't have a real need at the moment to expand the project into something for production, but I thougth it would be interresting to comment nevertheless.

bye,

It would be great to be able to compile Pascal source code into Java byte code that can be downloaded and by and a browser. Do you think this is possible ?

If yes, an example that we can have a look at would be great !

Did you use the FPC parser code in your project ?

If yes, it would be great to add "Java Byte Code" as an architecture for FPC. This makes a lot more sense than a stand-alone project.

You speak of problems when using pointers. Is the compiler able to work with classes (which are pointers in FPC) ? Does it use Java classes for this ?

-Michael

Yes, this is possible and even proven to be possible. I have a fieldtest delphi bytecode compiler from borland inprise times. Never made it to market, but it works.
Ask Codegear of they are willing to give you a specimen of this oldy. I can ask this if you like: very good contacts.

Thaddy

I can ask this if you like: very good contacts.

Could you ask them, please?

I will email Nick and David if they would be willing to (put it in the museum).

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.10/1815 - Release Date: 27-11-2008 9:02

I will email Nick and David if they would be willing to (put it in the museum).

thanks

Dear Sirs ,

Since many months , I was thinking to make a suggestion for generation of Java bytecode by Free Pascal from a Pascal source when a compiler switch is set . It seems that ( with respect to my limited knowledge about FPC Team structure ) compiler programming mostly managed by Florian and he is in his PhD studies which he has very difficult days for his PhD studies because PhD programs are not trivial subjects ( means that it is necessary to make a NEW contribution to existing science ) .

Since a thread started with this subject I could find encouragement to participate into it .

Having an ability to generate Java byte code by the Free Pascal compiler will make it a much more powerful cross compiler because generated Java byte code may be executed in any system having a Java Virtual Machine .

This will also make easy to transport Free Pascal compiler into such new environments because Free Pascal is able to compile itself : Compile Free Pascal to Java bytecode .
Bring it to new environment .
Compile Java byte code to machine code of the new environment ( after adjusting code generator of Free Pascal for the new environment ) .

With this facility developers will be able to transport their programs into new environments where there is no available Free Pascal compiler .

In short , I think , generation of Java byte code by the Free Pascal compiler is one of the most important improvements .

Thank you very much .

Mehmet Erol Sanliturk

I remember that the Delphi to java bytecode compiler isn't feature complete. I can't be: it will not be possible to compile any old delphi program into java byte code for several reasons. But it is possible to create Java bytecode with a - safe - subset of pascal syntax. It is also possible to use the same intermediate compiler to compile to .net/mono, though. It isn't possible to adapt Freepascal to write once compile anywhere with Java OR .Net. Both these assume restrictions that are simply not there in native code compilers, so you would have to work with one lame leg. I hope you realize that.

In our previous episode, Thaddy said:

Besides the pure language problem, there is also the library problem. Java and .NET are more than just a bytecode specification, there are also vast standard libraries, and the VCL-alike standard libraries of FPC (classes unit etc) are not designed to work on top of Java or .NET classes.

So then you get a problem, what do you do? Keep it compatible with native, but a bit alien to the Java or .NET world, or re-spin the libraries in a more Java/.NET compatible way, building on top of the base libs. Also for this a lot of language extensions must be implemented that might not be elegantly back-portable to native, since their philosophies are not the same.

But if you do such step, you introduce such a big barrier to actually switching between native and bytecode worlds (and probably between .NET and Java too) that one must ask what the benefit of long term keeping it in the same project really is. Since the native and bytecode targets basically then only share the base parser and semantic analysis.

This friction probably lead to the demise of VCL.NET and shared source on the Borland side.

As soon as you get the pure language part working, the users will fragment over mostly native and mostly bytecode oriented, and the common ground is gone.

Forking a project is a big deal, but IMHO warranted in this case. If even Borland can't pull it off.....

I wrote this from the perspective of a compiler, not from the perspectiev of a framework.
So, I fully agree with your response. It is a more elaborate version - with corrections - of what I ment.

But it IS possible to use the compiler itself with the frameworks that are native to the bytecode platforms. That in itself isn't rocket science. That was the ratio behind Borland experiments with a java bytecode compiler: and it never reached maturity because the library issue was the mayor hurdle.
Net succeeded somewhat first, because of a common architect ;)

Thaddy wrote

Yes, this is possible and even proven to be possible. I have a fieldtest delphi bytecode compiler from borland inprise times.

This is Pascal byte code not Java byte code. Any bowser can run Java byte code (via the Java Virtual Machine that is installed on any PC), but it can't run Pascal Byte code.

-Michael

You make a mistake : I am talking about JAVA VM bytecode. (and I am right, just as I am about that space ;) )

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.10/1815 - Release Date: 27-11-2008 9:02

Michael Schnell wrote

It would be great to be able to compile Pascal source code into Java byte code that can be downloaded and by and a browser. Do you think this is possible ?

I only researched about desktop and mobile Java. Not browser Java.

Did you use the FPC parser code in your project ?

No, I wrote my own.

You speak of problems when using pointers. Is the compiler able to work with classes (which are pointers in FPC) ? Does it use Java classes for this ?

My compiler is for procedural Pascal, but no, I don't think that classes are a problem with pointers. They are internally a pointer, but in a hidden way. Direct use of pointers is a problem, and pointer aritmetic too.

Mehmet Erol Sanliturk wrote

In short , I think , generation of Java byte code by the Free Pascal compiler is one of the most important improvements .

Open source projects (like Free Pascal) and driver by contributions.

It's not reasonable to expect that existing developers will stop the work they are currently interrested at to work on something you find very important. Each user will have his own idea of what is important, so it would be like expecting developers to go in 1000 different ways at once. In short, your priority isn't everyone elses priority.

If you consider some feature important to have in Free Pascal I would like to encourage you to take the adequate steps to have it done (tipically you can either write the code yourself or hire someone to do it).

Well, I think that the compiler could be shared between a native code and bytecode machine. Jonas implemented something like it, so this part is possible.

But:
- The RTL and class libraries would be totally different, since, as you correctly point out, the Java/.Net world have different philosphies. (no pointers, etc.)

This is the main problem, as it requires a large effort.

- One should not attempt to implement Java or C# language constructs in Pascal.

Michael.

Marco van de Voort wrote

Forking a project is a big deal, but IMHO warranted in this case. If even Borland can't pull it off.....

I am somewhat divided about what would be better, but inclined to agree that a new project would be better to target java mobiles.

Marco van de Voort wrote

Besides the pure language problem, there is also the library problem. Java and .NET are more than just a bytecode specification, there are also vast standard libraries, and the VCL-alike standard libraries of FPC (classes unit etc) are not designed to work on top of Java or .NET classes.

My initial experience was that this is no problem. The Java libraries are just an API just like any other. Just call the appropriate routines and you can build your implementation for anything in the FPC library.

I managed to write a simple ReadLn using base Java routines. It turns out they don't have one ready (horrible!), so I just got a routine that reads byte per byte and read until a new line comes. Parsed the ASCII into a number, processed the signal, etc.

Op Thu, 27 Nov 2008, schreef Felipe Monteiro de Carvalho:

One time, during a programming contest, the jury had written their solution to a problem in Java. A 10MB output file had to be written. Their implementation took about 15 minutes and took about 60 MB of memory.

During the contest, I was the first one to solve the problem and my program, of course coded with FPC, took something like 0,15s while using 200k of memory. When the contest was over, the jury expressed their surprise, and when I talked to them afterwards, they told there was a complete amazement in the jury room when my submission came in and was correct in every sense of the word.

We analyzed this, and it was nothing smart on my side, it was a simple Pascal text I/O versus Java text I/O issue. Not only is Java's text I/O terribly hard to use, it is also terribly inefficient. Our text I/O, on the other hand, is very well optimized.

Daniël

In our previous episode, Felipe Monteiro de Carvalho said:

It's like with the bytecode. If you start cutting pieces off, a workaround here. (insert "hammer" analogy here)

The point is if people will accept it, and if the synergy is enough for both sides of the projects (native and bytecode). And if code practically can't be shared, you don't even get to first base.

IMHO if it can't compile something like fpdoc (when cleaned a bit for pointer use), there is no point....

And then there is second base, keeping the interests of both platforms aligned long term and resist bringing heaps of .NETisms/Javaisms into the melt. Multiple versions of the framework (ME/SE/EE, compact framework etc), and the other way around, implementing new native features that are hard to add to the bytecode targets.

That's the lesson of Delphi.NET. _Sure_ it can be done. But only halfway practical (all existing code must be at least partially reengineered), and after an initial migration period hardly anybody is interested anymore in sharing the source, since it is simply not easy for large, non trivial codebases, and limiting to both sides.

In summary, it is about making the cooperation worthwhile in practice, and keep it that way beyond the catchy phrase "but you can target all these platforms ...", and avoid the situation most progress are compromises neither side are happy about long term (like VCL.NET when the honeymoon was over).

So, I would narrow the project really down, like limiting yourself to (a subset of) J2ME, and really keep the focus on mobile devices, and avoid the generalization of "all of Java".

Maybe that the fork can also be partially (e.g. only a native compiler generating bytecode to not complicate the compiler, and a totally separate RTL tree )

In our previous episode, Dani�l Mantione said:

We analyzed this, and it was nothing smart on my side, it was a simple Pascal text I/O versus Java text I/O issue. Not only is Java's text I/O terribly hard to use, it is also terribly inefficient. Our text I/O, on the other hand, is very well optimized.

To stay in I/O territory:

It will be interesting how

var f : text;
begin
  ttextrec(f).openfunc:=myopenfunc;

is implemented.

You make a mistake : I am talking about JAVA VM bytecode.

Thanks for pointing that out.
I did not ever hear about this, but I did learn about Pascal byte code ages ago, so I was mistaken :(.

The Java byte code thingy looks really interesting, though, It would be great if it really could happen.

-Michael

- One should not attempt to implement Java or C# language constructs in Pascal.

Oxygene / Delphi Prism seems to do this very successfully. But of course the compatibility to the existing code base is limited.

-Michael

I have send out the emails as promised. Let's hope you can toy around a little too.
Pascal byte code as in UCSD Pascal? (I used that at university on apple IIe's back in the '80's ;)

Well, the first remark is indeed questionable. As you remark: Prism is rather successful doing just that. The problem is the confusion between frameworks (essentially libraries), a language and a compiler. There's no reason at all that current objectpascal implementations like Delphi or FPC cannot implement Java or C# constructs. Although it might need a different memorymanager and a separate framework for native code: f.e. the Boehm memory manager, which does a good job, and/or extensive use of interfaces. For IL code this is covered by the VM (both Java VM and .Net) by the way, so there's no problem there too. The main problem lies in the frameworks. That's what makes it difficult. Another problem lies in multipass versus single pass compilation. As some here explained, there's more to it. But not impossible and it probably needs branching. The Delphi Java bytecode compiler comes without any framework by the way,although classes are supported. You rely on the Java framework.

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.11/1816 - Release Date: 27-11-2008 19:53

Well, I think that the compiler could be shared between a native code and bytecode machine.

I think the frontend (parsing the language into a tree structure) can certainly be shared, i'm not sure about the further back stages. Bytecode environments are certainly very different from native code in the sense that you can't just treat variables as variable sized lumps of bytes.

- One should not attempt to implement Java or C# language constructs in Pascal.

I think to produce a viable compiler you have to. Bytecode environments don't let you access memory directly so you don't have much choice but to use the class/interface structure provided by the bytecode environment. Furthermore all the standard libraries for the language rely on them as an interface so not being interoperable with them would be a huge pain.

Lukilly other than the garbage collection issue delphi style object pascal and java/.net actually have pretty similar object models so it shouldn't be too hard to map them.

I have a related story -- the jury of the famous ACM ICPC (http://icpc.baylor.edu/)
has disallowed Delphi language a few years ago (only C/C++ and Java remain). The rumored reason was that Delphi gives "unfair advantage" to teams (mostly Russian ones) using it.

Op Tue, 2 Dec 2008, schreef Alexander Klenin:

The requirement to offer a Pascal programming environment has been removed. Individual ACM contests are free to offer a Pascal programming environment and if you are affected by this decision I recommend you to point this out to the organisers of your ICPC contest.

The issue of unfair advantage is bogus, because the VCL is mostly useless except perhaps for Tlist, while the C++ STL can be definately of use in an ICPC contest.

Daniël

I am the organizer of local ICPC contest, and we do offer a wide range of languages
to local teams -- including Delphi, Free Pascal, Perl and even Basic ;-) (See http://imcs.dvgu.ru/cats/main.pl?f=compilers;cid=500001;display_rows=15;visible=1 warning: the site is in Russian)

Still, top players use C++, since Pascal is "pushed out" of higher-level contests,
so using it is counterproductive for advancing teams (See e.g. http://neerc.ifmo.ru/information/contest-rules.html, look for "Contest environment").

This saddens me, since I believe that Pascal is a better language both for teaching
and for actual programming.

The issue of unfair advantage is bogus, because the VCL is mostly useless except perhaps for Tlist, while the C++ STL can be definately of use in an ICPC contest.

Well, of course VCL is useless -- ICPC does not require visual real problem is Free Pascal's RTL, that is also useless compared to STL.

But Pascal still had the advantage in contests despite RTL weakness. I believe this comes primarily from the fact that simpler and cleaner syntax of Pascal
leads to fewer mistakes, and the cost of mistake is very even outweighs the necessity to implement some algorithms and data structures by hand.

Better I/O implementation in Delphi/FPC is an issue as well (especially compared to Visual C++ and java, GCC is mostly ok).

What does STL offer that the FPC RTL/FCL doesn't?

I think it should be easy for someone who needs more classes or routines to implement whatever is missing. We even have generics now.

Felipe Monteiro de Carvalho wrote

What does STL offer that the FPC RTL/FCL doesn't?

Primarily a well-developed collection of algorithms and data structures suitable for natural and efficient integration into application programs. The last part is especially important -- it is easy to write yet another quick sort
or balanced tree. It is hard to design it in such a way that, to application programmers,
using standard implementation is preferable to rolling their own.

Note that STL has its shortcomings too. For example, I believe that Pascal's implementations dynamic arrays and strings are easier to use than std::vector and std::string. (But, unfortunately, unfinished, which leads to ugliness such as TList and friends).

I think it should be easy for someone who needs more classes or routines to implement whatever is missing.

Yes, implementation is indeed easy. The design is the hard part. I have some thoughts on the design -- but it needs much work.

We even have generics now.

Yes, and it seems there was even an attempt to use it in RTL. Generics are still "unofficial", underdocumented and only partially implemented, so I believe current functionality is not enough yet to create anything competitive with the STL.

partially implemented, so I believe current functionality is not enough yet to create anything competitive with the STL.

Did you ever try to debug STL based programs even with a in this regard good debugger?

I did, and it was not very pleasant, but Lazarus+gdb is not (yet?) any better even
_without_ generics, so, unfortunately, there is no win for FPC there.

Indeed, but with the STL it's a fundamental problem while things like good dyn. arrays debugging would require only a debugger implementing dwarf fully.

Add: Not to mention the poor readability of STL code. I write a lot of STL code and often I've trouble to read my own code.