Hello,

What's wrong with it? Why it don't wants to use virtual memory?

3900 1263/10496 Kb Free
100 3113/10496 Kb Free
Compiling d:\pp\libs\consolegeneral.pp
Compiling d:\pp\libs\baseexceptcatch.pp
Linking cmlcd.exe
D:\PP\LIBS\GFXCAN~1.O: could not read symbols: Memory exhausted

And after that, when I try compiling for the second time, it reports following:

Free Pascal Compiler version 1.1 [2001/04/02] for i386 Copyright (c) 1993-2000 by Florian Klaempfl
Target OS: GO32 V2 DOS extender
Compiling cmlcd.pp
Compiling d:\pp\libs\rscfilebank.pp
561 Kb Free
Panic : Internal compiler error, exiting.
rscfilebank.pp(51,25) Fatal: Internal error 9999
rscfilebank.pp(1,9) Error: Forward class definition not resolved "TFileBank"

(It compiled for the first time).

Best regards,
Aleksey

What's wrong with it? Why it don't wants to use virtual memory?

Do you use a .PIF file that limits the memory per dosbox somehow?

Note that the linker is a separate process from the compiler. You may want to use he -Cn option, this will omit the linking stage and generate a ppas.bat file which you can call manually afterwards.

To enable virtual memory usage, you first have to configure cwsdpmi to do so (specify the max virtual memory size and where to create the swap file). I don't think the configuration app comes with FPC, but you can get it by downloading the official cwsdpmi package from a DJGPP mirror (see here for a list: <http://www.delorie.com/djgpp/getting.html>) from the directory 2misc (you'll want the file csdpmi5b.zip).

And after that, when I try compiling for the second time, it reports following:

[cut]

Panic : Internal compiler error, exiting. rscfilebank.pp(51,25) Fatal: Internal error 9999 rscfilebank.pp(1,9) Error: Forward class definition not resolved "TFileBank"

That's a bug in the compiler. We've already fixed a lot of such bugs (crashes when reompiling a program without first deleting the results of the previous compilation), but new ones always seem to pop up.I this regard, 1.0.4/1.0.5 is much more stable.

Jonas

option, this will omit the linking stage and generate a ppas.bat file which you can call manually afterwards.

To enable virtual memory usage, you first have to configure cwsdpmi to do so (specify

the
max virtual memory size and where to create the swap file). I don't think the configuration app comes with FPC, but you can get it by downloading the official cwsdpmi package from a DJGPP mirror (see here for a list:
<http://www.delorie.com/djgpp/getting.html>) from the directory 2misc (you'll want the file csdpmi5b.zip).

reompiling a program without first deleting the results of the previous compilation), but new ones always seem to pop up.I this regard, 1.0.4/1.0.5 is much more stable.

Maybe you can try again with a new 1.1, yesterday evening i applied a big patch to the compiler that should it make it more stable with type redefinitions in separate units.

If you won't work yet for your source, i.e. it still crashes. Can you then send me the source so i can debug the compiler.

A last hint, if you compile the compiler yourself, please compile it with:

make cycle OPT='-gl -dNOCATCH'

this will make a compiler that will give a backtrace with line numbers when a crash occures

Hello,

> What's wrong with it? Why it don't wants to use virtual memory? Do you use a .PIF file that limits the memory per dosbox somehow?

Yes, seems to be it did so. I've set DPMI memory limit to 16MB and it worked... But that "panic" error message still appears even after a correct compilation...

BTW, it is good you've changed try-block memory allocation from heap to a stack in v1.1. This gave some speed improvement (at least in my program) - it gave at least 22% speed improvement on one of the tasks. Not that much really (I expected more than 50%), but this is still better than nothing. :)

Best regards,
Aleksey

Hello,

I think there's some other type of problem... When I compile some "main" module compiler tends to recompile other dependent modules even after the first correct compilation. Dunno why this is necessary. And the final EXE tends to grow after such second-time passes.

I think this is all happening because of unit interdependencies... Maybe it is really necessary to implement something new in this field?

Best regards,
Aleksey

And there are still some left. Specially the one that is also bothering lazarus.

I think too, but IIRC it has to do with unit aliases?

Anyway, if your app is public, you can send me the problem source, and when I have time, I'll try to isolate it.

reompiling a

> program without first deleting the results of the previous compilation), but new ones

always

Also when using -Xs to strip the symbol tables?

The reason is that the registers used in a procedure are also stored in the ppu file. A second time that you recompile your project it could find that some units have change the usedregisters field and therefor want to recompile.

For interdependent units the 'problem' is that when parsing the interface declarations the usedregisters field is set to all registers are used. When an other unit is then compiled first, because the current unit dependents on it from the implementation and the other unit dependents on the current unit from the interface. Then the crc of the unit is calculated with the current value where all the procedures have set all registers used.

Hope that this makes it clear how complex the whole situation is. And if you're going to talk about a more clever method of dependency generation (from your other mail), you must also remember that Delphi is less stable with unit interdependencies than FPC. When you want to compare delphi then you must use the -m switch (make modified units) to be equal to FPC.

I think this is all happening because of unit interdependencies... Maybe it is really necessary to implement something new in this field?

Try compiling with -Ca, this will set all registers to used for each procedure.

Hello,

> I think this is all happening because of unit interdependencies... Maybe > it is really necessary to implement something new in this field? Try compiling with -Ca, this will set all registers to used for each procedure.

Yes, this helped. But that's strange compiler cannot catch all the changes after the first pass.

-Xs don't help because I think this is a default behaviour (or it was mentioned already in cfg file).

Best regards,
Aleksey

Because of the interdependency. Recompiling everything internal until it convergences will take to much time for a first compile. For the compiler itself it'll take 5-6 compiles before only pp.pas is compiled.

A small example with 2 units and 1 program:

unit A
from interface uses B

unit B
from implementation uses A

program C
uses A

Compiling program C will result:
- load units from C
- load interface units from A
- load unit B
- load interface units from B
- load implementation units from B
- unit A is already loaded, parse the interface of A
- compile unit B storing the checksum of the interface from unit A
- back in unit A, compile the unit and write checksum from B
- compile program C

A second compile of C will result in:

When there was a routine in unit A that didn't use all registers then unit B will recompile, because it can possible be optimized. This change can lead to unit A want to recompile the next time again when a third recompile is done.

Hope this example makes it a little bit clear how complex everything is. Also note that there are more things to take care of like memory leakes and open files!

PV> From: Peter Vreman

>> Try compiling with -Ca, this will set all registers to used for >> each procedure. Yes, this helped. But that's strange compiler >> cannot catch all the changes after the first pass.

PV> Because of the interdependency. Recompiling everything internal until PV> it convergences will take to much time for a first compile. For the PV> compiler itself it'll take 5-6 compiles before only pp.pas is PV> compiled.
PV> When there was a routine in unit A that didn't use all registers then PV> unit B will recompile, because it can possible be optimized. This ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PV> change can lead to unit A want to recompile the next time again when PV> a third recompile is done.

May be we need to set -Ca as default when _NO_ any optimization options given to FPC?

Regards,
Sergey Korshunoff

PS: There is no any word in english version of `FPC -h` output about -Ca, and some not clear comment `simple PPU compilation` in FPC source.

Hello,
Today I tried to compile last CVS compiler sources. The new-built compiler does not compile simplest hello program:

begin
 writeln('Hello, world!');
end.
Error message:
test.pas(1,1) Error: Type identifier expected

Pavel.

Hello, Today I tried to compile last CVS compiler sources. The new-built compiler does not

compile simplest

That is the risk of using CVS sources :)

The compiler is very unstable atm due large internal changes.

For the moment it's not recommended to be used until the snapshots building is working again. You can see that when the mails about a new linux snapshot start to appear again.

You need to cycle the compiler to rebuild the RTL and all other units