The packages/ dir of FPC is splitted in packages/base and packages/extra. This can maybe influence some unitpath settings pointing to the source location.

For installed fpc versions nothing changes.

There's simply no support yet for an array-of-char parameter as destination for a str() operation, neither in 1.0.x nor in 1.1. I'll add a test for it so it doesn't get forgotten.

Jonas

Hello all,
I tried to recompile some BP7-oriented sources with FPC 1.1 (built 08 Jan 2002) and could not compile

str(x,s);

s was declared as array[0..10] of Char; , not as a string. Compiling was with -S2 switch.

For a class property, the default is always nil so you can drop the default in the above declaration. Since you cannot declare a constant class, you also cannot refer to it in a 'default' class, hence the error.

But for compatibility's sake, we should fix this.

Michael.

Hello,
When I tried compile my program, I got an error message (Error: Property can't have a default value) although the same source was compiled with Delphi 3.0 successfully.

Example:

  property CurrentRecord:tRecord read GetCurrentRecord write SetCurrentRecord default nil;

where tRecord is declared as a class.

Hello all,

Athough I don't introduce new features to FPC now (I hope, only temporarily: while I have some important work which is not FPC-related) an only sent two incompatibities reports (sorry, after changing of my E-Mail client I forgot to translate my name in it from cyrillic to latin ABC immediately) but in between times I accumulated some crazy ideas which, I hope, could be interestnig.

Idea (1): Possible full Unicode support.
Now in FPC exists objpas module which does redeclare some types and functions fir $objfpc and $delphi modes. But similarly a UniFpc module could be introduced which must:
1) redeclare char, pchar, string to wide;
2) owerwrite some RTL functions (write, str, val etc) to support Unicode by default;
I see some problems here, to be frankly:
1) UniFpc should be separate for every target because it must use OS-depended API;
2) Because FPC must be also cross-compiler, converting ANSI to unicode cannot use direct calling of OS API conversation functions because Unicode is different in different operating systems; compiler should use internal tables to recoding;
2) at least one additional complier directive should be used: {$charset unicode,nnnn|$charset ansi}

Idea (2): possible way to support public inline procedures/functions and some possible consequences

Here I would explain full way of my reflections.
If we will use inline procedure which is written in one unit, in other units, we cannot save it as compiled machine code (because otherwise then we need to disassemble it before use). Then I make a conclusion: code of inline procedure must be stored into ppu file. But as what? At first look, storing it as a sequence of assember instructions seems to be a good idea. But really this way could cause some problems, mainly in optimization quality. For optimizer that could be not indifferent, is a parameter got by inline function a constant, a memory-stored or a register-stored variable. Therefore, maybe, that would be better, to save inline procedure in ppu-file as a sequence of TOKENS (may be, partially optimized).

But then for us some new possibities will be available, if we will store some parts of code not fully compiled (for releasing at including into "pseudo-caller" stage). Then become to be not meanless declarations like

procedure TheProc(type UserType, var x:inline; y:inline);inline;
 begin
  x:=x+UserType(y);
 end;
.....
TheProc(integer, AnIntegerVariable,'A');
TheProc(shortstring,AStringVariable,'B');

Furthermore, this way could help to make in FreePascal full support of class templates, like C++!

Sincerly, Pavel

There are widestr (UTF16) versions available in the 1.1 RTL. Only the conversion routines between widestr-ansistr are not implemented, the default is to only allow 7bit characters. There need to be some conversion routines for different charsets.

For the rest the widechar and widestr should be working

I think will be more complex than it looks. The compiler is build around shortstring for speed. Constant widestrings and long ansistrings are supported using helpers.

The solution is to implement the unicode handling only in the scanner part. The routines for reading char/identifier/comments from a filebuffer should all support the unicode (utf-8,utf-16?). This can be added by overriding these routines in a new class. But be carefull because most routines are called a lot and are therefor speed critical. For parsing constant string/char check for 7bit values. If all chars in the string then return a normale ascii string and all other are widestrings.

You don't need to know all compiler internals to implement this part. Only understanding how the scanner part works is enough.

This is still a TODO. We are gonna store the tnode tree in the ppu file. The use of tokens is not possible as the inlining takes place in the codegenerator part and not at the scanner level (there it will be macro's).

I never used it myself, but looking at the above example i don't like it. You can better use variants or use overloaded routines.

Peter

Hello All,

Today I tried to use FPC 1.1 (Win32 target) to compile my program which creates very many dynamic objects and also I compiled the same program with Delphi 6. Delphi-compiled program was much faster and, IMHO, that was because Delphi uses another heap manager (while running FPC-compiled version, an intensive swapping occurs, unlike Delphi-compiled version). Also I modified cmem.pp from Packages to test my program using C heap functions under Win32.

Benchs on K62-500 (W'NT 4):
FPC-compiled, native heap: from <1 ms to >2 min;
FPC-compiled, using slightly modified cmem.pp from Packages (heap manager

              from msvcrt40.dll): 2.5-9 s;

FPC-compiled, using slightly modified cmem.pp from Packages (heap manager

              from crtdll.dll): 1.5-9 s;

Delphi6: <1-10 ms(!)

I'm shocked after these results! IMHO, multi-platform FPC heap manager is not effective for win32 target. I can only hope that this my program is not correctly written.

I could send my unfortunate program (the day after tomorrow) but it is relatively big.

Try to recompile the compiler with Delphi and you'll see that the FPC heap manager is a lot faster than the Delphi heap manager.

I could send my unfortunate program (the day after tomorrow) but it is relatively big.

Can you send it to me

Peter Vreman wrote

> I could send my unfortunate program (the day after tomorrow) but it > is relatively big. Can you send it to me

I'm quite sure it uses a lot of reallocmem's and FPC's hepmanager is currently very bad at compacting the heap (so most of the time we have to allocate a new block when someone does a realloc mem and we end up with a lot of small, often even contiguous, blocks which are never concatenated).

Concatenating when allocating instead of when freeing would help here, but it would probably slow down the heap manager in cases where this wouldn't be necessary otherwise.

Jonas

On Thu, 28 Feb 2002, Jonas Maebe wrote:
}
}Concatenating when allocating instead of when freeing would help here, but }it would probably slow down the heap manager in cases where this wouldn't }be necessary otherwise.

I don't actually know how FPC's heap manager works but once when I wrote a library for similar purpose (a static memory pool) I chose to concatenate when allocating and it effectively added no overhead at all (one CPU cycle per memory block, to be precise). Of cource, I had to manage no more than 1 meg or so with few hundred blocks and thus I could use simple incremental search when allocating. If FPC uses a smarter way, it wouldn't help you much.

BTW, coulnd't you add a Defragment procedure into System unit? Slow or not, but it would be useful when program encounters hopeless heap fragmentation.

Ingmar

A defragmentation is not possible since a program can have pointers pointing to the heap that would also need to be updated.

On Thu, 28 Feb 2002, Peter Vreman wrote:

}
}A defragmentation is not possible since a program can have pointers pointing to the heap }that would also need to be updated.
}

Of course but concatenating free blocks would be possible, wouldn't it?

Ingmar

}A defragmentation is not possible since a program can have pointers pointing to the

heap

}that would also need to be updated. } Of course but concatenating free blocks would be possible, wouldn't it?

Concatenating is already done when a block is freed

But if the program is reallocating huge amounts of memory and in between allocates a smaller block the concatenating doesn't work

An other test can be to setup an initial heap (-Ch parameter) that is large enough

On Thu, 28 Feb 2002, Peter Vreman wrote:
}
}Concatenating is already done when a block is freed

Wow, didn't know it! I just like remember that it was mentioned about half a year ago in one of the lists that the heap manager _never_ merges blocks - when someone had problems with growing ansistrings. Seems like thing have changed. (c: Nevermind then.

Ingmar

The point is that you can't write a heap manager which is efficient for all cases and applications!

The FPC heap manager is optimized for the compiler and performs good in common cases. But under certain circumstances it allocates a lot of memory from the OS to fullfil it needs.

The 1.0.x compiler allocated expection handling blocks in the heap that could reduce the amount of growing of ansistrings. The 1.1 development compiler should be more efficient in those cases.

But merging is always dependent on other blocks that allocated in your program, those blocks can be allocated also implicitly by calling some rtl or other routines

Hola,

Today I tried to use FPC 1.1 (Win32 target) to compile my program which creates very many dynamic objects and also I compiled the same program with

If the problem is fragmentation, the solution should be a memory pool with fixed size blocks.

If when you say "objects" you mean classes derived from TObject, you could try overriding NewInstance to use such a memory pool, instead of taking the memory from the global heap.

The problem was that sizeof(<TClass>) returned a wrong value. Here at my PC it returned 1000000 so allocating 4 objects would already allocate 4Mb instead of only 16 bytes.

So there is no problem with the heap manager.

Peter

The FPC heap manager uses already pools for small memory blocks.

Hola,

>could try overriding NewInstance to use such a memory pool, instead of >taking the memory from the global heap. The problem was that sizeof(<TClass>) returned a wrong value. Here at my PC

Is not TObject.InstanceSize what should be used?.

SizeOf(SomeObject) should return SizeOf(Pointer), shouldn't it?.

That is now corrected

Peter

Hello,
Today I built 1.1 compiler from sources (with problems in nwm.pas but that's another story). Built complier seems to be not supporting ordinal-named labels, what breaks general Pascal compatibility:

label 1;
begin
 1:
 goto 1;
end.

Fixed

Peter