Hi there,

In an attempt to join in with the development of fpc for MacOS X, I installed fpc using SUSE 386 linux and VirtualPC. I started with fpc 1.0.10 and downloaded the sources for 1.1.

The problem and my analysis:

The problem is that when trying to compile 1.1 I get an error in objpas/math.pp around line 50 where the constants minextended and maxextended are set. Now, some time back I was trying the similar thing with version 1.0.6, but using win95 and win98 and VirtualPC and I got stuck at the same thing. I traced back the problem to the values of the constants. If I change them to values in the range of single precision, the compile goes through. At that time I thought that it is related to windows or the fpc port to windows. However, since the problem is the same under Linux, my guess is, that is has to do with VirtualPC, which otherwise does a fine job.

My questions:

Did anybody try to compile fpc using any system (Windows or unix or what so ever) under VirtualPC?
Did you experience the same problem with math.pp?

Can anybody try this with a VirtualPC/Windows setup?

Bet wishes -

Dr. Karl-Michael Schindler
FB Physik
Martin-Luther-Universität Halle-Wittenberg
D-06099 Halle (Saale)
Germany
Tel.: ++49 (0) 345 552-5563

It has to do with a difference between the PowerPC and 80x86 processors: the former only supports 64bit floating point precision, the latter 80 bit. Virtual PC does not emulate the full 80 bits, because this would slow down the emulation immensely.

Instead, it performs all floating point operations using the FPU of the PowerPC, but as such you lose 16bits of precision.

Did anybody try to compile fpc using any system (Windows or unix or what so ever) under VirtualPC?

A long time ago, I used the Dos version under VirtualPC.

Did you experience the same problem with math.pp?

I think there was no math.pp yet back then :) You can probably fix it by

a) in rtl/inc/system.inc, remove {$define SUPPORT_EXTENDED} b) in rtl/objpas/math.pp, change the {$define FPC_HAS_TYPE_EXTENDED} at the start to {$define FPC_HAS_TYPE_DOUBLE}
c) in compiler/options.pas, remove the statement
"def_symbol('FPC_HAS_TYPE_EXTENDED');" in the {$ifdef i386} section.

Jonas

Wow, Jonas

That was quick. I am impressed. Minor correction, though:

You said:

a) in rtl/inc/system.inc, remove {$define SUPPORT_EXTENDED}

but this line is in rtl/inc/systemh.inc

Furthermore, after doing all your patches, new errors show up in real2str.inc

I will look into it in more detail.

After

Dr. Karl-Michael Schindler
FB Physik
Martin-Luther-Universität Halle-Wittenberg
D-06099 Halle (Saale)
Germany
Tel.: ++49 (0) 345 552-5563

The above mentioned errors were due to a type mismatch. I had to change the type valreal from extended to double. This is in the file rtl/inc/systemh.inc. In addition I had to set MaxDouble and MinDouble in objpas/math.pp to other values. As a preliminary i just used the same values as MaxSingle and MinSingle.

Then make cycle with ppc386 1.0.10 goes through nearly through. However, finally it stucks and I have no is the last part of the log:

make ppc386
make[3]: Wechsel in das Verzeichnis Verzeichnis
»/usr/local/src/fpc/compiler«
/usr/local/src/fpc/compiler/ppc3 -di386 -dGDB -dBROWSERLOG -Fux86 -Fui386 -Fusystems -Fu../rtl/linux -Fii386 -FE. pp.pas Free Pascal Compiler version 1.1 [2003/10/23] for i386 Copyright (c) 1993-2002 by Florian Klaempfl
Target OS: Linux for i386
Compiling pp.pas
.
.
.
Compiling ./x86/aasmcpu.pas
Compiling ./x86/itx86att.pas
Panic : Internal compiler error, exiting.
i386tab.inc(6,15) Fatal: Internal error 9999
make[3]: *** [ppc386] Fehler 1
make[3]: Verlassen des Verzeichnisses Verzeichnis
»/usr/local/src/fpc/compiler«
make[2]: *** [next] Fehler 2
make[2]: Verlassen des Verzeichnisses Verzeichnis
»/usr/local/src/fpc/compiler«
make[1]: *** [remake3] Fehler 2
make[1]: Verlassen des Verzeichnisses Verzeichnis
»/usr/local/src/fpc/compiler«
make: *** [cycle] Fehler 2

When looking through the manual, I got the impression that the set operation IN is not implemented.
Is this right? Comments?

Michael S.

Dr. Karl-Michael Schindler wrote

Compiling ./x86/aasmcpu.pas Compiling ./x86/itx86att.pas Panic : Internal compiler error, exiting. i386tab.inc(6,15) Fatal: Internal error 9999

This is a segmentation fault (e.g. null pointer dereference). Compile with

make cycle OPT="-gl -dnocatch"

to get a full backtrace with line numbers.

Jonas

Dr. Karl-Michael Schindler wrote

When looking through the manual, I got the impression that the set operation IN is not implemented. Is this right? Comments?

No, the IN operator is fully implemented.

Jonas

03-10-21 11.39, skrev Jonas Maebe följande:

I currently use MacOS 9.2 and VirtualPC 4.0.2 with Windows 2000 installed, to do development of FPC 1.1 for classic MacOS (on PowerPC).

FPC 1.0.10 and the IDE runs without problem, its also possible to debug :) I also use WinCVS.

I have broken up with my girlfriend, so I do not have access to a PC at home anymore.

However, far as I know, the sources are not stable at the moment, I have not been able to get it the whole way to any runnable app on MacOS, the last month. This is due to the work with a beta release first of november.

I instead use the sources as of 2003 09 15

Olle

Olle Raab wrote

However, far as I know, the sources are not stable at the moment, I have not been able to get it the whole way to any runnable app on MacOS, the last month. This is due to the work with a beta release first of november.

It will improve soon :)

Jonas Maebe wrote lately:

with

With the recent 1.1 sources (patched for the extended problem), the simple make cycle now stopped with ppc2 compiling objpas.pp:

Compiling ../objpas/objpas.pp
objpas.pp(291,14) Fatal: Internal error 200305061

Making with make cycle OPT="-gl -dnocatch":

ppc1 gets created, but when compiling system.pp with ppc1 is seems to be stuck in an endless loop. At least it did not finish within 12 hours. As a reference for the speed under VirtualPC: pp.pas took 680 sec, i.e, 12 minutes.

Any hints?

Michael

Hi there.

More on the endless loop problem with ppc1 and rtl/linux/system.pp

I ran the offensing command with and without the -gl option and logged verbose output (-va). Without -gl system.pp compiled in reasonable time. Here come more details, without any idea to fix them however:

real2str.inc(295,8) Handling switch "$ENDIF"
real2str.inc(295,8) ENDIF SUPPORT_SINGLE found
real2str.inc(295,8) Skipping until...
real2str.inc(296,8) Handling switch "$ENDIF"
real2str.inc(296,8) ENDIF SUPPORT_DOUBLE found
real2str.inc(296,8) Skipping until...
real2str.inc(297,8) Handling switch "$ENDIF"
real2str.inc(297,8) ENDIF SUPPORT_EXTENDED found
real2str.inc(297,8) Skipping until...
real2str.inc(298,8) Handling switch "$ENDIF"
real2str.inc(298,8) ENDIF ENDIAN_BIG found
300 383/2.304 Kb Free
real2str.inc(336,21) Hint: Type size mismatch, possible loss of data / range check error
real2str.inc(373,15) Hint: Type size mismatch, possible loss of data / range check error
real2str.inc(374,27) Hint: Type size mismatch, possible loss of data / range check error
400 348/2.304 Kb Free
real2str.inc(63,31) Note: Local variable "orgd" not used real2str.inc(79,3) Hint: Local const "minexp" is not used <--- This is the last line when compiling with -gl
real2str.inc(471) Back in sstrings.inc
sstrings.inc(377,127) IFDEF HASCOMPILERPROC found, accepted sstrings.inc(377,164) ENDIF HASCOMPILERPROC found sstrings.inc(378,1) procedure/function $fpc_shortstr_float(Double, Longint, Longint, Longint,var ShortString);CompilerProc

Michael