Is there a list of people anywhere showing what processors are being worked upon and by whom?

In no particular order:

Florian Klaempfl -> x86-64 (I think?)
Mazen Neifer -> SPARC
Jonas Maebe, Olle Raab -> PowerPC 32-bit
Carl Eric Codere (me) -> 680x0, Virtual machine, and after that another one,
don't know which one yet (probably arm which is the easiest to implement)

(Hope i did not do any spelling mistakes in the names!)

I'm interested in Arm myself. Not to mention the juicy prospect of one

day

seeing code generators for things like the GameCube or Playstation 2.

(I

suspect it'll be Playstation 3 before someone gets around to it though).

I think we need to make sure that the compiler is portable, and this is not
entirely done yet (i mean in the code generator part) before implementing

several CPUs at once, currently none of the non-x86 code generators work

correctly, once one is fully ported (i mean in main branch, the 680x0 cg in
fixes branch works quite ok) the rest should follow easily (except for PowerPC, which in my view has a barbaric ABI - but i think this is already solved)....

Carl, can You explain some issues:

>Is there a list of people anywhere showing what processors are being

worked upon and by whom?

In no particular order: Florian Klaempfl -> x86-64 (I think?)

Which type of CPU (which are in shops) have this arch?

Carl Eric Codere (me) -> 680x0, Virtual machine, and after that another

one,

don't know which one yet (probably arm which is the easiest to implement)

Virtual machine -- is this a .NET virtaul machine, JAVE virtual machine or which one?

Thanks in advance,
Sergey Korshunoff

PS: as I think, today there is no DLL support for FPC under LINUX (link FPC produced *.so with FPC main module). Why? I suggested solution a one year before (november 2001). If my solution was wrong where is rigth solution?

Non yet, but it will be propably an important architecture soon.

Sergey Korshunoff wrote

PS: as I think, today there is no DLL support for FPC under LINUX (link FPC produced *.so with FPC main module). Why?

Because this requires PIC support. And PIC support requires an extra register to hold the pointer to the GOT table. And the current register allocator will die with a lot of internalerror(10)'s if it loses a register to work with. So first we need a new register allocator and then it should be fairly easy to implement.

Jonas

- PS: as I think, today there is no DLL support for FPC under LINUX
- (link FPC produced *.so with FPC main module). Why?

In Linux DLL (*.so) can be made without PIC. In most cases this is even more preferable -- this DLL use less RAM. PIC may be needed only for glibc.so -- a wide used by _different_ programs DLL, in which case PIC give us a RAM saving. Reason: DLL in PIC format is bigger. If it not wide used (plugin for the only _one_ program ) -- we lost RAM and time
if we use PIC format.

Conclusion: there is a big need in DLL support even without PIC. Why not implement generation of DLL and use of it with FPC made main program under Linux without PIC?

Regarsds,
Sergey Korshunoff

PS: I have a patches for FPC 1.1 (june 2002 snapsnots), but after this time changes for 1.1-line start go to fast to support this patches separately

Isn't PIC also necessary to support versioning? If you don't use PIC and you change a library, don't all programs that use that library have to be recompiled?

Conclusion: there is a big need in DLL support even without PIC. Why not implement generation of DLL and use of it with FPC made main program under Linux without PIC?

If you use the "library" keyword, we already generate a .so file without PIC code, so I'm not sure what the problem is (I haven't tested such libraries rigorously, but simple ones seem to work).

Jonas

Hello, Jonas!
You wrote to on Tue, 3 Dec 2002 10:24:58
+0100:

SK> In Linux DLL (*.so) can be made without PIC. In most cases this is SK> even more preferable -- this DLL use less RAM. PIC may be needed SK> only for glibc.so -- a wide used by _different_ programs DLL, in which SK> case PIC give us a RAM saving. Reason: DLL in PIC format is bigger. If SK> it not wide used (plugin for the only _one_ program ) -- we lost RAM SK> and time if we use PIC format.

JM> Isn't PIC also necessary to support versioning? If you don't use PIC JM> and you change a library, don't all programs that use that library have JM> to be recompiled?

If we change a library (but not the interface of exported functions). then we do not need to recompile any program. Versioning in Linux (glibc) is supported by special option to linker: a list of function names which are exported
in each version of library

SK> Conclusion: there is a big need in DLL support even without PIC. SK> Why not implement generation of DLL and use of it with SK> FPC made main program under Linux without PIC?

JM> If you use the "library" keyword, we already generate a .so file JM> without PIC code, so I'm not sure what the problem is (I haven't tested JM> such libraries rigorously, but simple ones seem to work). JM> Jonas

Thry to link FPC-produced main program with FPC-produced *.so library. In such case we can get a trap because insteed of calling init code in library (if we have initialization section for some library unit)
we call main code initialization again.

With best regards, Sergey Korshunoff