Jonas Maebe schrieb:
ppudump probably does not depend on cpubase in trunk. cpubase is part
of the code generator, and therefore the ppu loading should in fact
not depend on it (directly nor indirectly).
Apart from that (minor) issue, can you review my work? It would be
helpful to learn what's
Jonas Maebe schrieb:
ppudump probably does not depend on cpubase in trunk. cpubase is part
of the code generator, and therefore the ppu loading should in fact
not depend on it (directly nor indirectly).
That looks like the right explanation.
Consequently the code generation has to be separate
On 31 Aug 2010, at 21:00, Hans-Peter Diettrich wrote:
> D:/repos/fpc-2.5.trunk/compiler/ppc386.exe -Ur -Xs -O2 -n -Fu..
> -FuD:/repos/fpc-2.5.trunk/rtl/units/i386-win32 -FE. -FUunits/i386-win32
> -di386 -dRELEASE ppudump.pp -Fu../i386 -Fi..
>
> I cannot see any -Fu../x86 here, so how can x86/c
Jonas Maebe schrieb:
The -FU (note the capital U) parameter specifies where the compiled
units are stored (-FUx86_64/units/x86_64-win64). If you have .o and .ppu
files in the x86 directory, you put them there yourself somehow (either
on the command line or by modifying the default Lazarus proj
On 31 Aug 2010, at 00:45, Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
D:/repos/NoGlobals/compiler/ppc2.exe -Fux86_64 -Fusystems -Fu../
rtl/units/x86_64-win64 -Fix86_64 -FE. -FUx86_64/units/x86_64-
win64 -dx86_64 -dGDB -dBROWSERLOG -Fux86 pp.pas
in contrast too a later
D:/repos/NoGlo
Jonas Maebe schrieb:
D:/repos/NoGlobals/compiler/ppc2.exe -Fux86_64 -Fusystems
-Fu../rtl/units/x86_64-win64 -Fix86_64 -FE.
-FUx86_64/units/x86_64-win64 -dx86_64 -dGDB -dBROWSERLOG -Fux86 pp.pas
in contrast too a later
D:/repos/NoGlobals/compiler/ppcx64.exe -Fu..
-Fu../../rtl/units/x86_64-w
On 20 Aug 2010, at 12:20, Hans-Peter Diettrich wrote:
D:/repos/NoGlobals/compiler/ppc2.exe -Fux86_64 -Fusystems -Fu../rtl/
units/x86_64-win64 -Fix86_64 -FE. -FUx86_64/units/x86_64-win64 -
dx86_64 -dGDB -dBROWSERLOG -Fux86 pp.pas
in contrast too a later
D:/repos/NoGlobals/compiler/ppcx64.ex
Michael Schnell schrieb:
On 08/20/2010 12:39 PM, Hans-Peter Diettrich wrote:
The many conditional parts, which are not even properly chained by
{$ELSEIF ...}, make the maintance and refactoring a mess :-(
While moving to OO paradigms could make the code slightly slower, I
suppose that support
On 08/20/2010 12:39 PM, Hans-Peter Diettrich wrote:
The many conditional parts, which are not even properly chained by
{$ELSEIF ...}, make the maintance and refactoring a mess :-(
While moving to OO paradigms could make the code slightly slower, I
suppose that supporting multiple CPUs with a s
Am 20.08.2010 20:29, schrieb Hans-Peter Diettrich:
> Florian Klaempfl schrieb:
>
>>> Currently the introduction of a new target CPU requires to update many
>>> parts of the existing general compiler units,
>>
>> E.g.?
>>
>> I just greped for ifdef sparc in the general compiler directory:
>> 11 hi
Florian Klaempfl schrieb:
Currently the introduction of a new target CPU requires to update many
parts of the existing general compiler units,
E.g.?
I just greped for ifdef sparc in the general compiler directory:
11 hits:
Try the same with i386, and get hits somewhere else :-(
The prob
Am 20.08.2010 12:39, schrieb Hans-Peter Diettrich:
> Jonas Maebe schrieb:
>
>>> Such complications can be eliminated by a refactoring of the
>>> targets, into dedicated classes. This can be done in the same
>>> branch, because the existing units (in the target directories) have
>>> conflicting nam
Jonas Maebe schrieb:
Such complications can be eliminated by a refactoring of the
targets, into dedicated classes. This can be done in the same
branch, because the existing units (in the target directories) have
conflicting names, and consequently must be replaced by new unit
trees - something s
Jonas Maebe schrieb:
Run the following command in the compiler directory:
make fullcycle
There seems to exist a problem with the compiler configuration. This
call looks good and works as expected:
D:/repos/NoGlobals/compiler/ppc2.exe -Fux86_64 -Fusystems
-Fu../rtl/units/x86_64-win64 -Fix8
On 19 Aug 2010, at 22:33, Hans-Peter Diettrich wrote:
> Such complications can be eliminated by a refactoring of the targets, into
> dedicated classes. This can be done in the same branch, because the existing
> units (in the target directories) have conflicting names, and consequently
> must
Am 19.08.2010 21:39, schrieb Jonas Maebe:
>
> On 19 Aug 2010, at 22:33, Hans-Peter Diettrich wrote:
>
>> Even if the code generation has not been touched, other targets still may
>> deserve minor updates, related to the changed types of some previously
>> global variables (pointers instead of d
On 19 Aug 2010, at 22:33, Hans-Peter Diettrich wrote:
> Even if the code generation has not been touched, other targets still may
> deserve minor updates, related to the changed types of some previously global
> variables (pointers instead of direct references). I don't know how to test
> that
Jonas Maebe schrieb:
Please polish and finish one self-contained part, get that reviewed and
merged into trunk, and then continue (or use different branches,
although then you will have to merge things and resolve conflicts). In
particular, do not concurrently change different things in one br
Jonas Maebe schrieb:
In contrast to the preceding OO approach, a bunch of ordinary
procedures still waits for becoming methods, with faster access to
frequently used class members. Should I try to convert the procedures
to methods now, or should I wait until everything else has settled down?
On 18 Aug 2010, at 12:34, Hans-Peter Diettrich wrote:
In contrast to the preceding OO approach, a bunch of ordinary
procedures still waits for becoming methods, with faster access to
frequently used class members. Should I try to convert the
procedures to methods now, or should I wait unti
The removal of global variables is almost finished now. I know that the
code currently doesn't look nice, and that performance can be improved,
but these are minor details compared to the attempts to not break the
compiler itself.
In the last round a GlobalModule has been added, that plays the
Florian Klaempfl schrieb:
The observed problem is not the counting itself, but the exact point in
the workflow, when the compiler should go back into level one (or zero)
state, indicating "generate final binary for the main module". This is
not clear from the given code, and led to strange error
Am 12.08.2010 07:42, schrieb Hans-Peter Diettrich:
> Marco van de Voort schrieb:
>> In our previous episode, Hans-Peter Diettrich said:
>>> How would you count an level, when multiple concurrent parser threads
>>> create further threads concurrently?
>>
>> Hmm, I think a producer/consumer system wi
Am 12.08.2010 00:28, schrieb Hans-Peter Diettrich:
> Florian Klaempfl schrieb:
>
>>> It is not yet clear, however, whether the
>>> parser or entire modules can be destroyed before the end of compilation
>>> - if memory requirements are of interest at all.
>>
>> I don't think that a parser and a sc
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
How would you count an level, when multiple concurrent parser threads
create further threads concurrently?
Hmm, I think a producer/consumer system with a queue for modules that can be
compiled and N worker threads
Hans-Peter Diettrich schrieb:
Florian Klaempfl schrieb:
I also found an simple workaround for the TImplementedInterfaces
problems (getcopy), that can be moved into the trunk immediately.
Which commit is it?
It's the only change in symdef.pas, so far.
DoDi
--- C:/Users/dodi/AppData/Local/T
In our previous episode, Hans-Peter Diettrich said:
> How would you count an level, when multiple concurrent parser threads
> create further threads concurrently?
Hmm, I think a producer/consumer system with a queue for modules that can be
compiled and N worker threads (specifiable by user)
So
Florian Klaempfl schrieb:
It is not yet clear, however, whether the
parser or entire modules can be destroyed before the end of compilation
- if memory requirements are of interest at all.
I don't think that a parser and a scanner instance will take much memory?
That depends mostly on the re
On 08/11/2010 03:33 PM, Florian Klaempfl wrote:
I don't think that threadvars really hurt if it resolves the cyclic
dependencies.
(Many) Threadvars are no performance problem at all unless they are
_evaluated_ very often. If (e.g.) the "execute" of the thread creates a
class, saves the instanc
Am 11.08.2010 16:09, schrieb Hans-Peter Diettrich:
> After the problems with the global variables, I started another branch
> for removing global variables and fixing compiler "states".
>
> In the NoGlobals branch I already could make the scanner/parser a child
> object, owned by the module.
Thi
After the problems with the global variables, I started another branch
for removing global variables and fixing compiler "states".
In the NoGlobals branch I already could make the scanner/parser a child
object, owned by the module. It is not yet clear, however, whether the
parser or entire mod
31 matches
Mail list logo
