[fpc-devel] Some questions about compiler work on x86_64-win64

2017-03-17 Thread Bishop via fpc-devel

   

I have some questions about compiler work on x86_64-win64.

1) EXE-file contained .CRT section. As i understand it contained one
pointer to _FPC_Tls_Callback functions from RTL. Is it used only for
this?

2) Why INITFINAL table on both Windows and Linux puted to .data section? Is
we need to change it in time of app run? Or even possible it must be
evicted and replace just with call instructions? I mean autogeneration of
fpc_InitializeUnits and fpc_FinalizeUnits?

3) Why .fpc.n_version puted to .data section? Is we need change it on
runtime? Possible must be in .rdata? On linux it is entyre section for it,
does this is necessary?

4) Why referencing to global variable under Windows all time compiled like
RIP-related, even if no Generate-PIC enable (on Linux work fine)?

Example:
Program Test;

Var A: QWord;

Begin
 A := 25;
 Asm
  MOV RAX, 25
  MOV [A], RAX
 End ['RAX'];
End.  

Win64 code:
Test.lpr:6    A := 25;
000115AE 48c70557fa1900   mov   
QWORD PTR [rip+0xfa57],0x19    #
0x21010
Test.lpr:8    MOV RAX, 25
000115B9 48b81900 movabs
rax,0x19
Test.lpr:9    MOV [A], RAX
000115C3 48a310100200 movabs
ds:0x21010,rax

Linux with -Cg- (why in Lazarus PIC by default even when checkbox not
activated?):
project1.lpr:6    A := 25;
004001F9 48c7042510fd62001900 mov    QWORD PTR
ds:0x62fd10,0x19
project1.lpr:8    MOV RAX, 25
00400205 48b81900 movabs
rax,0x19
project1.lpr:9    MOV [A], RAX
0040020F 48a310fd6200 movabs
ds:0x62fd10,rax
  

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


[fpc-devel] Discussion about "Dynamic packages"

2017-04-12 Thread Bishop via fpc-devel

   

I had some fears concerning idea development of "Dynamic packages" in
FreePascal and possible performance penalties of programs from these
changes. This why i start this discussion and try wrote some of my ideas
or/and proposal that, as i think, can help make FreePascal better.

At first I would like to designate a circle of tasks which in principle can
effectively decide by means of system of dynamic packets. Lets remember for
what DLL`s and SO`s was be created. It was for memory saving (by sharing
code and static conts parts from many applications in memory). Now there is
so many memory even on phones, that this almoust have no sence (its still
work for things like LibC, ZLib and so.). But this kind of libraries better
make with C-style interface (or use COM/CORBA interfaces like in DirectX if
it`s realy needed). Yes, sometimes someone make libraries for C++ only, but
it because of a dominant position of this language. Pascal didn`t have it.
So, as i think, dynamic packages can be usefull only for something like
plugin system in editors like 3Ds Max, Photoshop and etc. But Sven Bart
wrote that "Package libraries can however only be used by a binary compiled
with the same compiler as they rely on quite a bit of compiler magic.", so
they be usefull only for projects that target to have plugins writed in
pascal only. I try to say, that there is not so many situations that we
realy need this system. I dont say that we dont need it at all, no. But
disadvantages from this system must no effect on all other projects. This
why i have some propositions.

Во время моего общения с Sven Barth он писал "With dynamic packages you can
share classes, strings, memory, etc. between the modules (the main binary
and the different package libraries)". Let's look at the most widespread
operating systems. This will be Windows and Unix-family. In Windows every
application starts from ntdll.dll and walk via kernel32.dll and only after
that go to "main"-function in EXE file. So kernel32.dll always loaded. And
its already have not bad memory manager (Process heap functions group). Why
dont use it? It allow share memory with C code too (and strings with pascal
code). Its already exist in application memory. In Linux if application use
shared libraries it use libdl.so witch need libc.so. So we already have
libc heap. As i know in FreeBSD and Solaris situation same.

And the second of my proposal it make dynamic packages like 2nd way in
compiler (like it maked in MSVS where we can select link CRT staticaly or
dunamicaly). Add some switch to compiler (and have 2 compiler variants of
RTL, now we have this in RTL source with {$IFDEF FPC_3_0_0} macro) that
will allow generate or not generate compiler magic for dynamic packages.
They need in not so many cases, but all this indirect memory accesses make
all applications slow (memory, first of all memory latency, in bottleneck
of all today computers).

Regards,
Roman



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


[fpc-devel] What status of the next FPC release?

2025-05-20 Thread Bishop via fpc-devel
Hi guys. There is long time pass since i seen last information about FPC 
development progress and it next release. The FPC website in no update too.


So i want ask:
1) What is next version of FPC planned to release? Is it 3.2.4?
2) When this release planed? (i understand there is no exact date, but 
at less some target date or plans)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel