Re: [fpc-devel] Pascal to Java compiler

2008-12-02 Thread Felipe Monteiro de Carvalho
On Tue, Dec 2, 2008 at 8:57 AM, Alexander Klenin [EMAIL PROTECTED] wrote:
 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 high at ICPC.
 It even outweighs the necessity to implement some algorithms and data
 structures by hand.

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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-12-02 Thread Alexander Klenin
On Tue, Dec 2, 2008 at 21:04, Felipe Monteiro de Carvalho
[EMAIL PROTECTED] 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.

-- 
Alexander S. Klenin
Insight Experts Ltd.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-12-02 Thread Florian Klaempfl
Alexander Klenin schrieb:
 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?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-12-02 Thread Alexander Klenin
On Tue, Dec 2, 2008 at 22:15, Florian Klaempfl [EMAIL PROTECTED] wrote:
 Alexander Klenin schrieb:
 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.


-- 
Alexander S. Klenin
Insight Experts Ltd.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-12-02 Thread Florian Klaempfl
Alexander Klenin schrieb:
 On Tue, Dec 2, 2008 at 22:15, Florian Klaempfl [EMAIL PROTECTED] wrote:
 Alexander Klenin schrieb:
 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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-12-02 Thread Florian Klaempfl
Florian Klaempfl schrieb:
 Alexander Klenin schrieb:
 On Tue, Dec 2, 2008 at 22:15, Florian Klaempfl [EMAIL PROTECTED] wrote:
 Alexander Klenin schrieb:
 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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-12-01 Thread Alexander Klenin
On Fri, Nov 28, 2008 at 07:59, Daniël Mantione
[EMAIL PROTECTED] wrote:
 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.

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.

-- 
Alexander S. Klenin
Insight Experts Ltd.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-12-01 Thread Daniël Mantione



Op Tue, 2 Dec 2008, schreef Alexander Klenin:


On Fri, Nov 28, 2008 at 07:59, Daniël Mantione
[EMAIL PROTECTED] wrote:

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.


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.


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___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-28 Thread Michael Schnell



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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-28 Thread Michael Schnell



- 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-28 Thread Thaddy

Michael Schnell wrote:



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 :(.
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 ;)


smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-28 Thread Thaddy

Michael Schnell wrote:



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


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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-28 Thread peter green

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.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel] Pascal to Java compiler

2008-11-27 Thread Felipe Monteiro de Carvalho
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,
-- 
Felipe Monteiro de Carvalho
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Michael Schnell
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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Thaddy
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

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  ?


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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel



No virus found in this incoming 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


  




smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread dmitry boyarintsev
 I can ask this if you like: very good contacts.

Could you ask them, please?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Thaddy

dmitry boyarintsev wrote:

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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread dmitry boyarintsev
 I will email Nick and David if they would be willing to (put it in the
 museum).

thanks
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel] Pascal to Java compiler

2008-11-27 Thread Mehmet Erol Sanliturk


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



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Thaddy
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.





smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Marco van de Voort
In our previous episode, Thaddy said:
 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.

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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Thaddy
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.


Marco van de Voort wrote:

In our previous episode, Thaddy said:
  
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.



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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel



No virus found in this incoming 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


  




smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Thaddy
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 ;)


smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Michael Schnell

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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Thaddy

Michael Schnell wrote:

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.


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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Felipe Monteiro de Carvalho
On Thu, Nov 27, 2008 at 12:44 PM, Mehmet Erol Sanliturk
[EMAIL PROTECTED] 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).

-- 
Felipe Monteiro de Carvalho
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Michael Van Canneyt


On Thu, 27 Nov 2008, Marco van de Voort wrote:

 In our previous episode, Thaddy said:
  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.
 
 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.

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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Felipe Monteiro de Carvalho
On Thu, Nov 27, 2008 at 1:17 PM, Marco van de Voort [EMAIL PROTECTED] 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.

-- 
Felipe Monteiro de Carvalho
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Felipe Monteiro de Carvalho
On Thu, Nov 27, 2008 at 1:17 PM, Marco van de Voort [EMAIL PROTECTED] 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.

-- 
Felipe Monteiro de Carvalho
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Daniël Mantione



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


On Thu, Nov 27, 2008 at 1:17 PM, Marco van de Voort [EMAIL PROTECTED] 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.


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___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Marco van de Voort
In our previous episode, Felipe Monteiro de Carvalho said:
 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.

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 )

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Pascal to Java compiler

2008-11-27 Thread Marco van de Voort
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. 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel