Hello,
Evidently, although Borland has ported Delphi to .Net, they have no plans to create a 64-bit native compiler. In fact, they have licensed the .Net compiler from MS. They seem to be getting out of the native compiler biz altogether.
So, I bet you can guess my next question (Ok, well it was in the msg title).
Does Gnu Pascal run on 64-bit Linux (SuSe or Redhat, etc.) or 64-bit Windows on either the Itanium 64 or AMD 64 chips?
Thanks!
-dennis
Dennis Landi wrote:
Evidently, although Borland has ported Delphi to .Net, they have no plans to create a 64-bit native compiler. In fact, they have licensed the .Net compiler from MS. They seem to be getting out of the native compiler biz altogether.
So, I bet you can guess my next question (Ok, well it was in the msg title).
Does Gnu Pascal run on 64-bit Linux (SuSe or Redhat, etc.) or 64-bit Windows on either the Itanium 64 or AMD 64 chips?
In short: currently gpc does not compile for AMD 64, Itanium 64 is experimental (I assume that you are interested in runing gpc compiled programs, gpc itself should have no problem running on 64 bit machines as a cross-compiler).
In detail: gpc shares code generator (about 80% of the compiler) with gcc. To make compiler for AMD 64 one has to apply a patch to gcc -- only then one can test if the compiler works. Debian has experimental version of gpc for Itanium 64 -- currently 9 gpc tests fails and 3577 works, so there are known problems. Also Itanium 64 version had probably very little (if any) real use, so new problems are very likely to show up.
--- Waldek Hebisch hebisch@math.uni.wroc.pl
Waldek Hebisch hebisch@math.uni.wroc.pl writes:
In detail: gpc shares code generator (about 80% of the compiler) with gcc. To make compiler for AMD 64 one has to apply a patch to gcc --
Which patch is this? Why is it non yet in GCC 3.3 or 3.4?
Andreas
Andreas Jaeger wrote:
Waldek Hebisch hebisch@math.uni.wroc.pl writes:
In detail: gpc shares code generator (about 80% of the compiler) with gcc. To make compiler for AMD 64 one has to apply a patch to gcc --
Which patch is this? Why is it non yet in GCC 3.3 or 3.4?
[ cc to Jan Hubicka ] We discussed the problem in June. Gpc runtime uses sets, and to build gpc the backend have to be able to pass sets as parameters. With the patch below cross compiler from i386 to x86_64 is able to build gpc runtime. I am not able to cross-build glibc (I used glibc headers, but I faked libc.a) so the resulting executables have no chance to run, and I have no acces to AMD 64 machine to test ... But the resulting assembly code looks reasonable, so I think that with true glibc the compiler should build OK.
The patch is one possible implementation of passing set arguments. I do not not what Jan Hubicka wants to have in the backend -- in June he did not answer when I sent him the code.
diff -ru gcc-3.3.1.orig/gcc/config/i386/i386.c gcc-3.3.1/gcc/config/i386/i386.c --- gcc-3.3.1.orig/gcc/config/i386/i386.c Tue Jul 8 21:16:44 2003 +++ gcc-3.3.1/gcc/config/i386/i386.c Thu Oct 16 00:25:52 2003 @@ -1853,6 +1853,31 @@ } } } + else if (TREE_CODE (type) == SET_TYPE) + { + if (bytes <= 4) + { + classes[0] = X86_64_INTEGERSI_CLASS; + return 1; + } + else if (bytes <= 8) + { + classes[0] = X86_64_INTEGER_CLASS; + return 1; + } + else if (bytes <= 12) + { + classes[0] = X86_64_INTEGER_CLASS; + classes[1] = X86_64_INTEGERSI_CLASS; + return 2; + } + else + { + classes[0] = X86_64_INTEGER_CLASS; + classes[1] = X86_64_INTEGER_CLASS; + return 2; + } + } else abort ();
Andreas Jaeger wrote:
Waldek Hebisch hebisch@math.uni.wroc.pl writes:
In detail: gpc shares code generator (about 80% of the compiler) with gcc. To make compiler for AMD 64 one has to apply a patch to gcc --
Which patch is this? Why is it non yet in GCC 3.3 or 3.4?
[ cc to Jan Hubicka ] We discussed the problem in June. Gpc runtime uses sets, and to build gpc the backend have to be able to pass sets as parameters. With the patch below cross compiler from i386 to x86_64 is able to build gpc runtime. I am not able to cross-build glibc (I used glibc headers, but I faked libc.a) so the resulting executables have no chance to run, and I have no acces to AMD 64 machine to test ... But the resulting assembly code looks reasonable, so I think that with true glibc the compiler should build OK.
The patch is one possible implementation of passing set arguments. I do not not what Jan Hubicka wants to have in the backend -- in June he did not answer when I sent him the code.
Sorry for the delay. I must have missed your mail twice. The patch is OK for mainline/3.3 branch.
Honza
diff -ru gcc-3.3.1.orig/gcc/config/i386/i386.c gcc-3.3.1/gcc/config/i386/i386.c --- gcc-3.3.1.orig/gcc/config/i386/i386.c Tue Jul 8 21:16:44 2003 +++ gcc-3.3.1/gcc/config/i386/i386.c Thu Oct 16 00:25:52 2003 @@ -1853,6 +1853,31 @@ } } }
else if (TREE_CODE (type) == SET_TYPE){if (bytes <= 4){classes[0] = X86_64_INTEGERSI_CLASS;return 1;}else if (bytes <= 8){classes[0] = X86_64_INTEGER_CLASS;return 1;}else if (bytes <= 12){classes[0] = X86_64_INTEGER_CLASS;classes[1] = X86_64_INTEGERSI_CLASS;return 2;}else{classes[0] = X86_64_INTEGER_CLASS;classes[1] = X86_64_INTEGER_CLASS;return 2;}- } else abort ();
-- Waldek Hebisch hebisch@math.uni.wroc.pl
Jan Hubicka jh@suse.cz writes:
Sorry for the delay. I must have missed your mail twice. The patch is OK for mainline/3.3 branch.
I'll test it locally and will then commit it to both branches,
Thanks, Andreas
2003-10-21 Waldek Hebisch hebisch@math.uni.wroc.pl
* config/i386/i386.c (classify_argument): Handle SET_TYPE.
Honza
diff -ru gcc-3.3.1.orig/gcc/config/i386/i386.c gcc-3.3.1/gcc/config/i386/i386.c --- gcc-3.3.1.orig/gcc/config/i386/i386.c Tue Jul 8 21:16:44 2003 +++ gcc-3.3.1/gcc/config/i386/i386.c Thu Oct 16 00:25:52 2003 @@ -1853,6 +1853,31 @@ } } }
else if (TREE_CODE (type) == SET_TYPE){if (bytes <= 4){classes[0] = X86_64_INTEGERSI_CLASS;return 1;}else if (bytes <= 8){classes[0] = X86_64_INTEGER_CLASS;return 1;}else if (bytes <= 12){classes[0] = X86_64_INTEGER_CLASS;classes[1] = X86_64_INTEGERSI_CLASS;return 2;}else{classes[0] = X86_64_INTEGER_CLASS;classes[1] = X86_64_INTEGER_CLASS;return 2;}- } else abort ();
-- Waldek Hebisch hebisch@math.uni.wroc.pl
Andreas
Jan Hubicka wrote:
Andreas Jaeger wrote:
... snip ...
We discussed the problem in June. Gpc runtime uses sets, and to build gpc the backend have to be able to pass sets as parameters. With the patch below cross compiler from i386 to x86_64 is able to build gpc runtime. I am not able to cross-build glibc (I used glibc headers, but I faked libc.a) so the resulting executables have no chance to run, and I have no acces to AMD 64 machine to test ... But the resulting assembly code looks reasonable, so I think that with true glibc the compiler should build OK.
The patch is one possible implementation of passing set arguments. I do not not what Jan Hubicka wants to have in the backend -- in June he did not answer when I sent him the code.
Sorry for the delay. I must have missed your mail twice. The patch is OK for mainline/3.3 branch.
Just a quick thought - Ada also has sets, AFAIK, and is integrated into gcc now. I would expect that their backend solutions would also work for Pascal.
Chuck F wrote:
Just a quick thought - Ada also has sets, AFAIK, and is integrated into gcc now. I would expect that their backend solutions would also work for Pascal.
1) AFAIK Ada do not have sets.
2) Ada front end is very different from GPC. At least one GPC bug would be very easy to fix if GPC worked the Gnat way (but GPC is much simpler then Gnat). If you want to know more about the difference look at: http://cobolforgcc.sourceforge.net/cobol_14.html Many details on this page are out of date, but it explains nicely differnce between GPC approach (direct coupling with the backend) and Ada approach.
Waldek Hebisch wrote:
- Ada front end is very different from GPC. At least one GPC bug would be very easy to fix if GPC worked the Gnat way (but GPC is much simpler then Gnat).
Which one exactly are you referring to?
I think we could improve a few things (in particular operations on string/set constants) by not converting things to backend trees so early. AFAIK, we'll have to do something like what Gnat does sometime anyway to support TreeSSA in a future GCC version, but I hope we can do it in a rather lightweight way. I think, using extended trees (only where necessary/useful) in the frontend and translate them to backend trees at the latest moment should be possible. The latter will require recursive traversal of expression trees, but this isn't such a big deal, we do it for schemata already.
Frank
Waldek Hebisch wrote:
- Ada front end is very different from GPC. At least one GPC bug would be very easy to fix if GPC worked the Gnat way (but GPC is much simpler then Gnat).
Which one exactly are you referring to?
The following program ilustrates the problem (AFAIR something similar is in the todo directory). In procedure k reference to x is illegal becouse k is in the scope of second declaratin, but before the defining point. It would be easy to catch such things by tree-walk, but otherwise housekeeping is quite messy.
program scope; var x : integer; procedure p; procedure k; begin x:= x+1; end; var x : boolean; begin end; begin writeln('failed') end .
I think we could improve a few things (in particular operations on string/set constants) by not converting things to backend trees so early. AFAIK, we'll have to do something like what Gnat does sometime anyway to support TreeSSA in a future GCC version, but I hope we can do it in a rather lightweight way. I think, using extended trees (only where necessary/useful) in the frontend and translate them to backend trees at the latest moment should be possible. The latter will require recursive traversal of expression trees, but this isn't such a big deal, we do it for schemata already.
Yes, if we had full expression tree we could infer types of set constants much more accurately.
Waldek Hebisch wrote:
Waldek Hebisch wrote:
- Ada front end is very different from GPC. At least one GPC bug would be very easy to fix if GPC worked the Gnat way (but GPC is much simpler then Gnat).
Which one exactly are you referring to?
The following program ilustrates the problem (AFAIR something similar is in the todo directory). In procedure k reference to x is illegal becouse k is in the scope of second declaratin, but before the defining point. It would be easy to catch such things by tree-walk, but otherwise housekeeping is quite messy.
program scope; var x : integer; procedure p; procedure k; begin x:= x+1; end; var x : boolean; begin end; begin writeln('failed') end .
But the declaration of x itself is illegal there. It belongs between the "procedure p;" and the "procedure k;" lines. Proper indentation makes it obvious (below) or am I missing something?
program scope; var x : integer; procedure p; var x : boolean; (* line belongs here *) procedure k; begin x:= x+1; (* error on boolean *) end; begin end; begin writeln('failed') end.
Chuck F wrote:
Waldek Hebisch wrote:
The following program ilustrates the problem (AFAIR something similar is in the todo directory). In procedure k reference to x is illegal becouse k is in the scope of second declaratin, but before the defining point. It would be easy to catch such things by tree-walk, but otherwise housekeeping is quite messy.
program scope; var x : integer; procedure p; procedure k; begin x:= x+1; end; var x : boolean; begin end; begin writeln('failed') end .
But the declaration of x itself is illegal there. It belongs between the "procedure p;" and the "procedure k;" lines. Proper indentation makes it obvious (below) or am I missing something?
Well, Extended Pascal allows mixing declarations of procedures and variables, so you can declare variables for a block just before statement part of that block. And gpc compiles the program and only warns about unused variables/procedures...
Hi Dennis,
Dennis Landi wrote:
Evidently, although Borland has ported Delphi to .Net, they have no plans to create a 64-bit native compiler. In fact, they have licensed the .Net compiler from MS. They seem to be getting out of the native compiler biz altogether.
I don't think the above statement is accurate.
Borland have licenced the C# .NET compiler for their C# Builder product as they did not want to reinvent the wheel, but they are writing a new compiler for the Delphi.NET product which generates .NET executables, which, I believe, should run on other .NET platforms ( WinCE - with the Compact Framework when M$ sorts it out, MacOS under FreeBSD and probably even Linux ).
The Delphi.NET compiler will support quite a few new language constructs so that it is compatible with languages like C#. Most, if not all of these constructs should also be available in Delphi 8 so that migration from .NET to Native Win32 applications can be facilitated.
So they currently are not getting out of the native compiler biz. At least not with their Pascal product.
Dominique http://www.DelphiGamer.com := go on, write a game instead;
Ok, then they are getting out of the NATIVE COMPILER BIZ.
Dominique, how do you feel about the fact that you will not be able to port your native Win32 code to Win64?
You ok with that? If you get into 32-bit .NET that calls 32-bit unmanaged pascal code, you will *NOT* be able to do that on 64-bit windows.
-dennis ----- Original Message ----- From: Dominique Louis To: Dennis Landi Cc: gpc@gnu.de Sent: Thursday, October 02, 2003 4:45 AM Subject: Re: Gnu Pascal running on 64-bit Linux or Windows?
Hi Dennis,
Dennis Landi wrote:
Evidently, although Borland has ported Delphi to .Net, they have no plans to create a 64-bit native compiler. In fact, they have licensed the .Net compiler from MS. They seem to be getting out of the native compiler biz altogether.
I don't think the above statement is accurate.
So they currently are not getting out of the native compiler biz. At least not with their Pascal product.
Hi Dennis, Why are you so sure they will not be porting the compiler to 64Bit.
I agree that Borland are not over overly quick to bring out enhancements to their Pascal compiler, but I have not seen any indication that it will be abandoned yet.
As I mentioned the D8 compiler will be Native compiler and it will not compile to an intermediate level language or generate interpretted code, AFAIK.
The whole point of .NET is for it to be platform independent. Assuming Borland's .NET compiler compiles proper .NET interpretted code, I can see not reason why a 64Bit .NET could not automagically recompile the interpreted code to 64Bit using a JIT. Hell that sort of thing has been possible on IBM AS400 machines since the 80's ( no source code required either ).
Anyway I am sure the GPC guys on this list, don't want to hear about Borland's future compiler. So if you would like to continue this dicussion privately, send me an email.
Dominique Louis.
Dennis Landi wrote:
Ok, then they are getting out of the NATIVE COMPILER BIZ.
Dominique, how do you feel about the fact that you will not be able to port your native Win32 code to Win64?
You ok with that? If you get into 32-bit .NET that calls 32-bit unmanaged pascal code, you will *NOT* be able to do that on 64-bit windows.
-dennis
----- Original Message ----- *From:* Dominique Louis <mailto:Dominique@SavageSoftware.com.au> *To:* Dennis Landi <mailto:dennis@dennislandi.com> *Cc:* gpc@gnu.de <mailto:gpc@gnu.de> *Sent:* Thursday, October 02, 2003 4:45 AM *Subject:* Re: Gnu Pascal running on 64-bit Linux or Windows? Hi Dennis, Dennis Landi wrote: > Evidently, although Borland has ported Delphi to .Net, they have no > plans to create a 64-bit native compiler. In fact, they have licensed > the .Net compiler from MS. They seem to be getting out of the native > compiler biz altogether. >>I don't think the above statement is accurate. >>So they currently are not getting out of the native compiler biz. At >>least not with their Pascal product.
<<Why are you so sure they will not be porting the compiler to 64Bit>>
You haven't been religously following my posts on the delphi.non-technical forum <g>
Just google for "64-Bit", my name and "Danny Thorpe"
<<Anyway I am sure the GPC guys on this list, don't want to hear about Borland's future compiler. So if you would like to continue this dicussion privately, send me an email.>>
Will do.
Dominique Louis wrote:
Hi Dennis,
Dennis Landi wrote:
Evidently, although Borland has ported Delphi to .Net, they have no plans to create a 64-bit native compiler. In fact, they have licensed the .Net compiler from MS. They seem to be getting out of the native compiler biz altogether.
I don't think the above statement is accurate.
Borland have licenced the C# .NET compiler for their C# Builder product as they did not want to reinvent the wheel, but they are writing a new compiler for the Delphi.NET product which generates .NET executables, which, I believe, should run on other .NET platforms ( WinCE - with the Compact Framework when M$ sorts it out, MacOS under FreeBSD and probably even Linux ).
The Delphi.NET compiler will support quite a few new language constructs so that it is compatible with languages like C#. Most, if not all of these constructs should also be available in Delphi 8 so that migration from .NET to Native Win32 applications can be facilitated.
So they currently are not getting out of the native compiler biz. At least not with their Pascal product.
Before diving blindly into .NET, I recommend careful reading of http://aaxnet.com/editor/edit029.html, which is by the way a fascinating analysis of the computer industry in general.
Regards,
Adriaan van Os
-
Adriaan van Os -
Andreas Jaeger -
CBFalconer -
Dennis Landi -
Dominique Louis -
Frank Heckenbach -
Jan Hubicka -
Waldek Hebisch