In discussions between FPC developers the question if we should build a .NET back end for FPC pops up again. Now I want to know what our users think? Did you ever consider to use/switch to .NET? Would you be interessed in having a .NET back end for FPC?

.NET can be used completly without MS stuff, there is for example http://www.go-mono.com which builds a portable .NET environment.

Hi!

In discussions between FPC developers the question if we should build a .NET back end for FPC pops up again. Now I want to know what our users think? Did you ever consider to use/switch to .NET? Would you be interessed in having a .NET back end for FPC?

I personally do not like .NET. That possibly comes because I've read about it in the German Linux Magazin. .NET has a few very good ideas. OTOH there are points I really dislike.

IMHO the available capacities for programming and development of FPC should be used to have the compiler for more processors (ia64, ...) and to implement things like CORBA, Bonobo, C++ binding, ... There seems to be efford to get DOM working, which should be enhanced for CORBA, ...

Bye
Hansi

Hi!

One big advantage of FreePascal .NET applications would be the fact that you have to compile them once and you can use them on a wide range of operating systems, and at least on one that wasn't supported by fpc before, Mac OS.

An other thing is a common (perhaps native) toolkit freepascal lacks (and delphi has), the winforms. Using them you could easily create gui applications with freepascal. Perhaps they might be integrated to the lazarus project.

ciao,

Olaf

One big advantage of FreePascal .NET applications would be the fact that you have to compile them once and you can use them on a wide range of operating systems, and at least on one that wasn't supported by fpc before, Mac OS.

I think FPC will sooner support Mac OS than .NET will support Mac OS :-)

The "multi platform" possibilities of .NET still exist only on paper. There are some GPL projects in the works, but one still has to wait if they provide enough compability.

Well, I think you're right. For a realy wide range of platforms a java backend would be the best choice ;-)
I personally don't need .net and I think if the gcc guys create a .net backend we could use gpc as a .net-pascal compiler.
Perhaps you should create a gcc-frontend? But this is certainly more difficult than adding .net support to the compiler.

ciao,

olaf

I think a Java backend would lay even worse limitations on the language than .NET.

Perhaps you should create a gcc-frontend? But this is certainly more difficult than adding .net support to the compiler.

GPC took 13 years and are still in the beginning stages of Delphi compability. This is apparantly more work than actually creating all those front-ends yourself.

----- Original Message -----

Peter H.M. Brooks wrote

Why should either back end add limitations?

Because e.g. Java doesn't know the concept of pointers, so you can't compile anything that uses pointers.

If the big attraction is to have it working on a MAC, then surely it makes more sense to port fpc to a MAC?

It's Mac, not MAC (MAC = Media Access Control) :) And we are working on that. In fact, "hello world" for Linux/PPC (and hopefully, shortly thereafter also for Mac OS X) is nearing compilability!

Jonas

Sorry for the offtopic, this reminded me of something, how is the status of the possibility to link to C++ object files?
Never thought about it? Would never consider doing it? Yes, but long term? We are already working on it? It works right now? I just wanted to know, it might be a more interesting issue to be able to link to C++ first.

Along the same lines, I am not very acquainted with QT, but aren't QT C++? How is it possible to link FPC code with QT to create KDE-like apps?

Aitor

About QT specifically something came up. There is a tool to translate the (IIRC IDL) abstract prototypes to plain C.

This could be adapted to generate (Object or plain) Pascal headers too.

The tool is in Perl though, and all FPC developpers don't like to touch that, so no core-developper worked on that yet.

Hi,

Thanks for the info. Interesting...
Sorry to insist, but what about C++? (I just want information, I don't intend to accuse/pressure/whatever)

Aitor

----- Original Message -----

Indeed, but the backend that creates such code will have the limitation: it simply cannot generate byte code that does such things, so the frontend would also have to reject it in that case.

Jonas

That's not true :) I started this already and the headers already look like pascal. But other developers told me to do the FPC cg stuff instead of playing with perl ;) But if anybody else is interessted I can send him the work which is already done. Within a few hours of work it should be possible to get Qt3/KDE3 programs run with FPC.

That'll be for speed in 99% of the cases. So then you need a interface to compiled native code, not a Pascal compiler excrementing Java bytecode.

The Java language doesn't know the concept of pointers, but the java byte-code does. You can compile Pascal program for the JVM like you compile it for IA-32. You can treat the JVM like another CPU target. I think the .NET VM is identical on this point.

But I am to let Microsoft show is evil plan behind .Net before sign with the evil :-)

Hi All,

Perhaps it might be worth looking at the GPLed Java compiler called "Jasmin"; It provides some sort of JVM Assembly language format, which could probably become one of the FPC's output formats, pretty much like it already does using the GAS. You could just treat it like any other cpu.

In my opinion targeting Java instead of .NET would mean far greater portability, since already there are JVMs for many systems. Besides that it would be very fun to write Java Applets in Free Pascal ;-) And eventually you could support .NET when it becomes widely available.

You can find "Jasmin" pages at http://cat.nyu.edu/meyer/jasmin

Cheers,
Milos

it

would be very fun to write Java Applets in Free Pascal ;-) And eventually you could support .NET when it becomes widely available.

Greetings,
Ok i want to clear the java bytecode format polemic once and for all : we thought about doing an output of java bytecode, and i even read a thesis on implementing a pascal compiler with output of java bytecode...

The conclusion is : It is impossible to keep all the features of Pascal with java bytecode, we would have to limit ourselves significantly :

- java bytecode does not support indirect calls, therefore all procedural variables would be impossible -: we'd have to redesign the system unit because of that.
- java bytecode does not support pointers, so anything related to pointers would have to be removed, it supports references to objects only.
- var parameters would be very difficult to implement, as java bytecode passes parameters by value, you would have to create a horrible hack to use var parameters.

The CLI / CLR of Microsoft (.net) supports two modes of virtual machine, one is managed mode, where untyped pointers are not allowed, and because of that it would limit the pascal syntax, but there is also another mode (non-secured) which permits using unmanaged pointers, this does not exist at all in java byte code ...

So either we support .net, our own virtual machine (that i am currently designing and implementing), or we keep FPC as it is now.

Carl.

you wrote

So either we support .net, our own virtual machine (that i am currently designing and implementing), or we keep FPC as it is now.

I'm in agreement that Java bytecode is not an option, but I also think that .Net wouldn't be a very good choice either. .Net is essentially Microsoft-only, and since FreePascal is cross-platform I think it would be better to support Mono.

Regards,
Brian

For FPC, there would be no difference if Mono or .NET SDK is used because Mone will be a .NET clone.

Hi,

In discussions between FPC developers the question if we should build a .NET back end for FPC pops up again. Now I want to know what our users think? Did you ever consider to use/switch to .NET? Would you be interessed in having a .NET back end for FPC?

I think a .NET back end for FPC would add to the compiler. The more it supports the best, even if I do not see .NET on my future. :-)

..NET can be used completly without MS stuff, there is for example http://www.go-mono.com which builds a portable .NET environment.

This thing actualy works for real applications, or is it like Wine?

[]s, Fernando Lozano

Hi,

An other thing is a common (perhaps native) toolkit freepascal lacks (and delphi has), the winforms. Using them you could easily create gui applications with freepascal. Perhaps they might be integrated to the lazarus project.

I guess improving GTK+ and LibGlade support (even Glade itself) or working harder on Lazarus would do more to FPC GUI apps and multiplataform compatibility than the .NET framework. Real multiplataform apps like Mozilla and Gimp were build on GTK+ and develop for it is faily easy.

Using GTK+ on Windows does add a lot of DLLs but provides native plataform performance and if you wish you can use also native Windows APIs alongside GTK+.

[]s, Fernando Lozano

Hi,

A FPC compiler that generates java bytecodes would be great. I played a litthe with Jython (a Python interpreter/compiler written itself in Java and that generates Java bytecodes) and PHP-Java and it's very interesting. Think about Pascal Servlets, Pascal Server Pages, or Pascal Remote Objects. :-) But I don't think this would be an easy project.

[]s, Fernando Lozano

Hi

> ..NET can be used completly without MS stuff, there is for example > http://www.go-mono.com which builds a portable .NET environment. This thing actualy works for real applications, or is it like Wine?

It works for real applications - BUT as long as the class library isn't complete enough there won't be any "big" applications that run on it. And I think there is also a lot of work on winforms left - gtk# should work so far.

Ciao,

Olaf