Rob Koopman wrote:
We are investigating to port about 400.000 lines of DEC Vax Pascal (started as VMS application later ported to OSF1 UNIX).
One of our concerns is the maturity of the GPC environment. During our initial tests we encountered some compiler problems (segfault, internal error).
An obvious question is did someone else try this before. ( DEC Pascal has funny extentions)
We've ported quite a lot of DEC Pascal to GPC without major problems. Certainly GPC2.1 hasn't given us problems with segfaults or internal errors on both i386 or Alpha platforms. We have had to do quite a lot of manual code conversions though. Areas which spring to mind that needed changing in our code was:
GPC doesn't read enumerated types from files; GPC doesn't support the :=ZERO assignment; GPC doesn't use file i/o and read qualifiers, especially ERROR:= CONTINUE; VARYING [] OF CHAR must be replaced by STRING(); REAL is best defined as SINGLE; VMS runtime library functions aren't available (obviously!). I can't do key detection as I do under VMS INHERIT and ENVIRONMENT become INTERFACE/IMPLEMENTATION and USES Remove [GLOBAL] and [EXTERNAL] [STATIC] becomes static No D+0 etc. for double precision exponents The only compiler bug - global string definitions in modules don't always work yet (I don't think?)
I have code examples of how I've worked around the enumerated type reading and ZERO issues if you wish.
Regards
David Wood QinetiQ Farnborough
The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.
At 1:52 PM +0000 6/2/03, Wood David wrote:
Rob Koopman wrote:
[snip]
We've ported quite a lot of DEC Pascal to GPC without major problems. Certainly GPC2.1 hasn't given us problems with segfaults or internal errors on both i386 or Alpha platforms. We have had to do quite a lot of manual code conversions though. Areas which spring to mind that needed changing in our code was:
GPC doesn't read enumerated types from files; GPC doesn't support the :=ZERO assignment; GPC doesn't use file i/o and read qualifiers, especially ERROR:= CONTINUE; VARYING [] OF CHAR must be replaced by STRING(); REAL is best defined as SINGLE; VMS runtime library functions aren't available (obviously!). I can't do key detection as I do under VMS INHERIT and ENVIRONMENT become INTERFACE/IMPLEMENTATION and USES Remove [GLOBAL] and [EXTERNAL] [STATIC] becomes static No D+0 etc. for double precision exponents The only compiler bug - global string definitions in modules don't always work yet (I don't think?)
I have code examples of how I've worked around the enumerated type reading and ZERO issues if you wish.
I'd like to this is if you're willing. I'm trying to port my old Ph.D. project (for old times sake I suspect!)
Wood David wrote:
We've ported quite a lot of DEC Pascal to GPC without major problems. Certainly GPC2.1 hasn't given us problems with segfaults or internal errors on both i386 or Alpha platforms. We have had to do quite a lot of manual code conversions though. Areas which spring to mind that needed changing in our code was:
GPC doesn't read enumerated types from files;
This was once discussed, but hasn't been pursued further yet, since there seemed to be little interest. If there's now, it should be possible to do with moderate effort ...
GPC doesn't support the :=ZERO assignment; GPC doesn't use file i/o and read qualifiers, especially ERROR:= CONTINUE; VARYING [] OF CHAR must be replaced by STRING(); VMS runtime library functions aren't available (obviously!). I can't do key detection as I do under VMS INHERIT and ENVIRONMENT become INTERFACE/IMPLEMENTATION and USES Remove [GLOBAL] and [EXTERNAL] [STATIC] becomes static No D+0 etc. for double precision exponents
Some of these extensions I don't know at all, and some ... well, quite honestly, I don't like the syntax, e.g. `[EXTERNAL]'!? In this case I admit I find Borland's way more reasonable to make it a directive `external', syntactically like `forward' ...
The only compiler bug - global string definitions in modules don't always work yet (I don't think?)
That's right. I hope I can fix this sometime ...
Frank