Re: [fpc-devel] FPC and Z80

[Florian Klaempfl]

Am 27.04.2020 um 17:52 schrieb Karoly Balogh (Charlie/SGR):

Hi,

On Mon, 27 Apr 2020, Sven Barth via fpc-devel wrote:


Well, I'm surprised and impressed you got it to work at all...
Quite an achievement.


Considering that we already support AVR as well I was rather confident
here. :D Maybe in the future we can also add GameBoy support which uses
some Z80/8080 hybrid? ^^'


I have no idea, but quickly read through some docs, and it seems the
GameBoy CPU doesn't have IX/IY registers, which seems to be very useful to
implement some of the more complex references handling, according to what
Nikolay wrote earlier. 


Yes. IX and IY are the key for the FPC Z80 port. Without them it's 
getting really difficult. And I suspect we need to work without a normal 
stack but allocate local variables globally, so basically no recursion 
will be possible.



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

Re: [fpc-devel] FPC and Z80

[Florian Klaempfl]

Am 27.04.2020 um 15:37 schrieb nickysn--- via fpc-devel:

On Mon, 2020-04-20 at 17:07 +0300, nick...@gmail.com wrote:

On Thu, 2020-04-16 at 11:04 +0200, Guillermo wrote:

Thanks Swen.

I see last commit was 2 days ago so it is active.  I would like to
know
who is responsible to speak to him. May be I can help with the MSX
target, but I need gidance about the internals of the compiler (I
tried
but it is beyond my comprehension right now).



The current state of the Z80 port is that it's partially working, but
it's not complete enough in order to be able to compile a full RTL.
However, simple stuff like this is working on the ZX Spectrum:

program hello;
var
   i: byte;
begin
   PrintChar('F');
   PrintChar('P');
   PrintChar('C');
   for b := 0 to 255 do
 PrintHexByte(b);
end.


Last night, I got the full system unit to compile, including console
output, so now you can use standard write/writeln. Unfortunately if you
include both read/readln and write/writeln in your program, the program
becomes too big to fit in the memory of the 48k ZX Spectrum, so there's
lots of optimizations left to do... :) 


Maybe you look in the rtl for the CPUAVR defines. Reducing e.g. the size 
of textrec helps a lot, also exception handling for io (not sure if it 
is activated) causes a big share of code being pulled in.

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

Re: [fpc-devel] New feature announcement: constant parameters for generics

[Florian Klaempfl]

Am 26.04.2020 um 11:02 schrieb Michael Van Canneyt:



On Sun, 26 Apr 2020, Ryan Joseph via fpc-devel wrote:




On Apr 26, 2020, at 2:38 PM, Michael Van Canneyt 
 wrote:


As the original author, can you say something about the intended use 
of this feature ?


It was meant for a pretty narrow use of array types. If I knew how 
much work it would be to implement I probably would have not done it. 
:P I personally wanted it for static array lists that had methods like 
Add/Delete.


Fixed-length arrays are the only practical use I can think of.

The record with constants example is too convoluted to my taste.
As a reader, I find such code hard to understand.

Thanks for the examples !


Another example might be headers for embedded systems.

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

Re: [fpc-devel] What is the best match for for -mfpu=fpv4-sp-d16 on fpc-arm?

[Florian Klaempfl]

Am 11.04.2020 um 21:03 schrieb Michael Ring via fpc-devel:
I have now set up new target freertos-arm and want to start playing 
arround with freertos.


I have compiled freertos with STM32CubeIDE, only 'problem' is that I 
need to compile with floting point enabled, with Soft-Float the build 
fails.


For STM32F401RE Chip the C-compiler selects

-mfpu=fpv4-sp-d16 -mfloat-abi=hard

but Freepascal doex not seem to support exactly this abi, I see:
NONE
SOFT
LIBGCC
FPA
FPA10
FPA11
VFPV2
VFPV3
NEON_VFPV3
VFPV3_D16
FPV4_S16
VFPV4
NEON_VFPV4

Which setting should I use? VFPV3_D16 or something else?


Let's just add it. What properties does it have? Do you have know some 
reference by heard?



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

Re: [fpc-devel] Recent changes to x86-64 peephole optimisation

[Florian Klaempfl]

Am 08.03.2020 um 15:54 schrieb J. Gareth Moreton:

Hi everyone,

I've been away for a few days so I haven't
been paying too much attention to the trunk,
but I've noticed some new changes to the x86-
64 peephole optimized that look interesting.
Can someone fill me in on what they're meant
to do and the motivation behind the
additions? This is just so I fully understand
what everything is doing and don't
accidentally overwrite something.



Which ones do you mean? Normally, I try to a add a reasonable commit 
message.


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

Re: [fpc-devel] Question about NOP instructions

[Florian Klaempfl]

Am 02.11.2019 um 15:08 schrieb J. Gareth Moreton:
> Hi everyone,
> 
> During my optimisation travels, I frequently stumble across lone NOP
> instructions in the compiled assembly language.  Normally I leave these
> alone, but occasionally I stumble across things like this:
> 
>     ...
>     movq    $0,24(%rbx)
> .Lj1859:
>     nop
> .Lj1858:
>     movq    %rbp,%rcx
>     ...
> 

Can you please post the complete code? Without it, it's hard to say

> And there are jumps elsewhere that go to one label or the other. Is
> there any reason why a jump should lead to the NOP, or can they all be
> redirected to after the NOP instruction?

Some are the result of exception handling on x86_64-win64, see
compiler/x86_64/nx64flw.pas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Guidance for code generation for shift operations for AVR target

[Florian Klaempfl]

Am 19.08.2019 um 22:20 schrieb Christo Crause:
> I'm interested in trying to improve the code generated for shift
> operations (in particular involving a compile time constant shift) for
> the AVR target.  The AVR processor doesn't have a barrel shifter,
> instead it can only shift a single bit position per clock cycle.
> Currently the compiler by default generates a bit shift loop where the
> loop is executed n times to push a value by n bits.  The only
> optimization I noticed for the case of shifting a value by a compile
> time constant is in Tcg.a_op_const_reg_reg where an 8 bit shift of a 16
> bit value is converted to copying the low byte of the left operand into
> the high byte of the result, and setting the low byte of the result to 0.
> 
> I would like to extend this type of optimization to cover more cases -
> the obvious extension is to convert all shifts by 8 bit multiples by
> corresponding byte moves. A more general approach (which I've got
> working for shl as concept) is to at least convert all 8 bit multiples
> as byte moves, then just do the last few bit shifts (if any) either as
> an unrolled loop (e.g. as implemented in tcgavr.a_op_const_reg_internal)
> or by generating the conventional shift loop (as implemented in
> tcgavr.a_op_reg_reg_internal). At the moment I've implemented the this
> logic in tcgavr.a_op_const_reg_reg.  I first check if I can generate
> smaller code compared to a shift loop and if not, the code calls the
> inherited method  a_op_const_reg_reg which basically follows the
> existing path (see also attached patch)
> 
> The code generator is complex to follow for me, since the functionality
> is kind of normalized and distributed across generic and CPU specific
> parts, and code flow jumps around up and down the inheritance chain. 

Yes, nice OOP ;)

> I
> therefore have some questions around this proposed modification and
> implementation in the code generator for which I would like some
> guidance on:
> * Is tcgavr.a_op_const_reg_reg the correct place for this type of
> functionality?
> * Am I messing up something else by effectively moving most of the code
> generation for this case higher up the call chain?
> * Am I missing some other path which could also benefit from this
> optimization?
> * Should I try and generate different code depending on whether -Os is
> specified or not (e.g. perform more loop unrolling if -Os is not specified)?
> * Any comments on the patch, which is a work in progress?

For me the idea looks good, actually, I planned once to do the same, but
got stuck for time reasons with the beginnings you discovered.

If such a patch really works, can normaly only checked by testing.
Besides simple benchmarking I often do another thing: I build without
the patch with -al, copy all .s files to a tmp dir, then I do a build
with the patch with -al, copy all resulting .s files to another temp.
dir and then I look at the differences with WinMerge. It becomes pretty
fast obvious if such a patch works good.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Florian Klaempfl]

Am 06.07.2019 um 17:38 schrieb Sven Barth via fpc-devel:
>> I tried to follow the thread, but one think I miss is: what are the
>> rules for indention? Does the lines string contain
>> spaces at the beginning of every line or not? Are they removed? How
>> many are removed? What about tabs? Actually, this is
>> my main concern with such multiline strings: spaces/tabs at the
>> beginning of a line cannot be handled in an intuitive way.
> I've also complained about that point here:
> https://lists.freepascal.org/pipermail/fpc-devel/2019-July/041453.html
> 

Sorry, I missed this one ;(

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

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

[Florian Klaempfl]

Am 28.06.2019 um 11:24 schrieb George Bakhtadze:

This assumption is *not* incorrect. Only on the LLVM based Delphi
NewGen and FPC's LLVM backend the assumption is incorrect which can
be seen by them having added "volatile" mechanisms. 

I believe this assumption incorrect because it's not stated in 
documentation as correct.


It is not true, if possible, FPC puts global variables into registers.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

[Florian Klaempfl]

Am 25.10.2018 um 09:06 schrieb Sven Barth via fpc-devel:
Simon Kissel > schrieb am Do., 25. Okt. 2018, 
08:54:


- Complete the LLVM branch of FPC. It looks like Jonas has stopped
   working on it two years ago, which is a pity.


I personally don't think that LLVM is the way to go. It's essentially a 
moving target and adds an unnecessary dependency to the compiler.


Me neither :)



- Rewrite the code generator, for example in a SSA-IR way


Didn't Florian work on that already? I wonder how far he is by now 樂


Got distracted by other stuff but also because I do not believe that it 
matters much for a lot real world programs (small benchmarks are another 
story).

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

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

[Florian Klaempfl]

Am 25.10.2018 um 11:18 schrieb Sven Barth via fpc-devel:
Michael Van Canneyt > schrieb am Do., 25. Okt. 2018, 09:38:




On Sat, 20 Oct 2018, Simon Kissel wrote:

 > - Make Exception handling, TLS etc use the infrastructure that
 >  libpthread is providing

TLS is handled already by libpthread. I doubt you will gain much there.

However, Exception handling is a problem. There are 2 possible ways
ahead:
- DWARF exception handling as mentioned by Sven.
- Port SEH to be cross platform, this is the approach as taken by Kylix.
Kilyx has a small rtlunwind  library that mimics the needed run-time
functionality
offered by Windows.

Conceivably, it can be duplicated. wine probably has such a library
which
can be used as an inspiration.

The needed compiler infrastructure for SEH  already exists, so this
is most likely
the fastest way to proceed.


I'm against emulating SEH. Better implement DWARF exceptions. 


Yes.

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

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

[Florian Klaempfl]

Am 25.10.2018 um 17:38 schrieb Karoly Balogh (Charlie/SGR):

Hi,

On Thu, 25 Oct 2018, Michael Van Canneyt wrote:


- Make Exception handling, TLS etc use the infrastructure that
  libpthread is providing


TLS is handled already by libpthread. I doubt you will gain much there.



GCC has (depending on the platform) a faster implementation for "__thread"
variables. E.g. on x86 it uses the GS segment and the data is stored in ELF
sections. There were experiments in the past to support this in FPC as
well, so maybe we're on a good way there already.


That is good news.  The contours of a TODO list are becoming visible :)

But we may need also need a solution for other platforms, which means the
current system should remain in place for those platforms where such a
system is not present ?


FPC already has some code to support section threadvars via the GS segment
on i386 at least, but it doesn't seem to be enabled by default? (Couldn't
test it, but the tf_section_threadvars target flag, which enable this is
actually behind a define in i_linux.pas, which I couldn't find enabled
anywhere?). Also tf_section_threadvars flag has some code to support it
all over the compiler, including the x86 cg. I have some really vague
memories I actually enabled it in some experimental local version I had,
and it worked on first sight at least, but I could be completely off here.

I wonder why it was never enabled by default. 


The %gs based approach works only for object files linked statically to 
the executable. In general there are four TLS access models on linux and 
at least three of them need to be supported, if one wants to support 
dyn. libraries in a usefull manner. Of course, this comes with the 
requirement to over means to control the used model. The tls.pdf by U. 
Drepper decribes it very well.


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

Re: [fpc-devel] Pure function Wiki page

[Florian Klaempfl]

Am 09.07.2018 um 18:24 schrieb Max Nazhalov via fpc-devel:

Just one question: doesn't all this new stuff introduce another kind
of mess during cross-compiling?

E.g. some complex nested const.expr. "sin(cos(0.12345))" evaluated by
the compiler on x64 (double precision) is not the same as if it would
be evaluated by the compiled program itself running on some x32
(float80), or some future float128 alikes..

Either the compiler itself must eventually become fully softfloat-based??



Yes, preferable float128 based. However, nobody volunteered so far do so.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Maximum symbol length -- answer needed

[Florian Klaempfl]

Am 01.07.2018 um 20:49 schrieb Jonas Maebe:
> On 01/07/18 20:27, Florian Klaempfl wrote:
>> Am 23.06.2018 um 10:48 schrieb Jonas Maebe:
>>> I doubt this is a major contributor to that fact (especially since
>>> implicit exception frames are disabled for the compiler binary, so
>>> ansistrings don't result in extra exception frames).
>>
>> I tested on x86_64-linux and the increase is around 10 % for make cycle.
>> So it cannot be neglected imo.
> 
> Many compiler helpers still use "string" or "shortstring"
> parameters/results/local variables, so there are still quite a few type
> conversions going on from shortstring to ansistring.

Yes, but this needs to be profiled in detail.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Maximum symbol length -- answer needed

[Florian Klaempfl]

Am 23.06.2018 um 10:48 schrieb Jonas Maebe:
>> Personally, if I had any stake in this, I would be against it. I mean,
>> FPC is already slower than DCC.
> 
> I doubt this is a major contributor to that fact (especially since
> implicit exception frames are disabled for the compiler binary, so
> ansistrings don't result in extra exception frames).

I tested on x86_64-linux and the increase is around 10 % for make cycle.
So it cannot be neglected imo.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "ease of use" patches

[Florian Klaempfl]

Am 18.05.2018 um 02:01 schrieb J. Gareth Moreton:

Hi everyone,

I've just recently submitted a patch with some code that makes one of 
the compiler errors clearer for the user, and minimises a 'cascade' 
where more errors appear due to the presence of the first one.  
Translations aside, what's the general policy with these "ease of use" 
patches that don't really fix any bugs but simply intend to make Lazarus 
and Free Pascal easier to use for third-party developers?


Yes, they are fine, they are accepted like any other reasonable feature 
patch.

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

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

[Florian Klaempfl]

Am 28.04.2018 um 17:57 schrieb Thorsten Engler:
>> -Original Message-
>> From: fpc-devel  On Behalf
>> Of Florian Klämpfl
>> So something like
>>
>>   cmp   edx, $4330
>>   jge  @@zero
>>   cmp   edx, $3FE0
>>   .align   16
>>   jbe  @@skip
>>
>> might be much better.
> 
> That ended up making things worse in some cases.

Can you take a look at the generated machine code if delphi uses proper
multi byte nops. If  not, the align might make things indeed worse.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Multiple variable initialization

[Florian Klaempfl]

Am 24.03.2018 um 20:21 schrieb Ondrej Pokorny:
> 
> Anyway, my favorite example of non-pascalish syntax within FPC are the
> +=, -= etc. operators. I really don't understand how they made it into
> FPC if so many FPC developers are stubbornly against simple and helpful
> extensions :)

The were added in ~1996 when I maintained FPC by applying patches to a
source tree on my hd :) But to be honest, I am not sure if I accepted
the patch today :)

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

Re: [fpc-devel] Multiple variable initialization

[Florian Klaempfl]

Am 24.03.2018 um 11:46 schrieb Ondrej Pokorny:
> Is there a reason why multiple variable initialization is forbidden?
> 
> program Test;
> var
>   A: Integer = 0;    // allowed
>   B, C: Integer = 0; // not allowed
> begin
> end.
> 
> Will a patch be applied that allows it?

As the first one is supported, I see no logical reason the second
shouldn't be supported, of course assigning 0 to B and C.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] trunk broken

[Florian Klaempfl]

Am 02.09.2017 um 17:06 schrieb Karoly Balogh (Charlie/SGR):
> Hi,
> 
> On Sat, 2 Sep 2017, Marco van de Voort wrote:
> 
>> The expansion of texpropcode in r37108 (Mattias) breaks fppasjs because it
>> defines an array with texpropcode as range.
>>
>> This prohibits building of trunk.
> 
> Sven fixed it already in r37109.
> 
> (The quick-response advantage of receiving build notifications from
> Marcus' Jenkins... ;)
> 

Maybe we can create a new fpc mailing list fpc-notifications or
something like this so everybody can subscribe if needed?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Dangerous optimization in CASE..OF

[Florian Klaempfl]

Am 16.07.2017 um 21:08 schrieb Ondrej Pokorny:
> On 16.07.2017 20:42, Florian Klämpfl wrote:
>> "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)" = Invalid
>> opcode (memory dump written).
>> Why? Because it does not range check before entering the jump table.
> 
> OK, I confess I am not a C guy (I hated it in the university even more
> than fortran). But for me:

...

> 
> ondrej@ondrej-linux:~/ctest$ gcc test.c
> ondrej@ondrej-linux:~/ctest$ ./a.out
> defaultondrej@ondrej-linux:~/ctest$
> 
> No error if I remove the default statement.

Indeed. This proves the exactly point. Undefined behaviour. The code
behaves randomly dependent on the compiler used and even the optimizer
switches.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] UTF-8 string literals

[Florian Klaempfl]

Am 05.05.2017 um 13:53 schrieb Mattias Gaertner:
> Hi,
> 
> AFAIK FPC stores UTF-8 string literals (-Fcutf8) 

-Fc tells the compiler only the encoding of the source code page, it
says nothing how string constant shall be encoded.

> as widestrings
> instead of UTF8String. Please correct me if I'm wrong.
> 
> This has several side effects:
> 
> 1. When using a character outside BMP FPC stops with:
> Error: UTF-8 code greater than 65535 found
> For example:
> const Eyes = '';
> 
> 2. Assigning a UTF-8 literal to an UTF8String requires a
> widestringmanager.
> For example non ISO-8859-1 chars are mangled:
> var u: UTF8String = 'äöüالعَرَبِيَّة';
> 
> 3. PChar on a string literal does not work as expected. You get the
> bytes of a widestring instead.

Well, it depends on what you expect :)

> 
> 
> What would happen if FPC would be extended to store UTF-8
> literals as UTF8String? 
> What are the disadvantages?

1. Backward compatibility. Due to its windows origins and history, the
default unicode encoding in FPC is UTF-16, FPC uses also internally
UTF-16 everywhere.

2. What would happen then the other way around? When casting the string
constant to a PUnicodeChar (what probably a lot of delphi code does)?

3. Personally, I still think, UTF-16 is the "native" unicode type: all
important APIs use UTF-16, for me, UTF-8 is a hack.

What we could do of course is, that if a constant is assigned to a
string with explicit utf-8 encoding, that the compiler does the
conversion at run time. But it complicates things even more. This does
not solve the PChar problem, but I think, when somebody uses unicode
source files and PChar, he is on how own :)

I think, it would nice if Michael (v. C.) prepares some section for the
docs and we comment and help him to improve it.

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

Re: [fpc-devel] BacktraceStrFunc on linux x86_64?

[Florian Klaempfl]

Am 01.05.2017 um 11:36 schrieb Michael Van Canneyt:
> 
> 
> On Mon, 1 May 2017, Nikolai Zhubr wrote:
> 
>> 01.05.2017 11:46, Florian Klämpfl:
>> [...]
 And I'm still getting just an address anyway...
>>>
>>>
>>> 3.0.x is broken in this regard (stack back trace on x86-64 elf targets), 
>> see other threads on the
>>> fpc mailing lists regarding this. This is why we discussing a quick as 
>> possibile 3.0.4 release.
>>
>> Ah, ok. Couldn't find any mentions of the issue (bad googling or
>> whatever) but anyway I'll probably have to wait for 3.0.4 then.
> 
> You don't need to wait:
> 
> Only 3.0.2 linux for i386 CPU has the problem. 64-bit is OK. And 3.0.0
> is OK in this aspect for all platforms.
> 
> So you can continue to work.

OPs, sorry, then I was wrong. I thought x86-64 elf is affected ...

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

Re: [fpc-devel] Management operators AddRef and Copy vs Copy

[Florian Klaempfl]

Am 25.04.2016 um 16:47 schrieb Maciej Izak:
> Finally I've decided to use Clone and Copy (as proposed by Florian).

Glad to hear :) Another thing: I wonder if those really need to be
operators? In C++, "clone" is also only a special constructor.

> Should I adjust RTL inner functions to this? I mean renaming FPC_COPY to
> FPC_CLONE and FPC_ADDREF to FPC_COPY.

I wouldn't do this, it has been this way for years. Users who dig in
this code, understand it, the others are not effected.

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

Re: [fpc-devel] fpc iso mode

[Florian Klaempfl]

Am 03.02.2016 um 22:38 schrieb Sven Barth:
> On 03.02.2016 20:07, Tomas Hajny wrote:
>> On Wed, February 3, 2016 20:00, Sven Barth wrote:
>>> On 03.02.2016 16:58, Schindler Karl-Michael wrote:
>>  .
>>  .
 How about his suggestion about renaming the mode to iso7185? Too late?
>>>
>>> We could maybe add iso7185 as an alternative to iso and deprecate the
>>> latter...
>>>
 How about calling ExtendedPascal iso10206 instead of extpas?
>>>
>>> Since Extended Pascal supported is only in trunk that would be no
>>> problem...
>>
>> Not really important for me personally, but I wonder: Would all/most
>> potential users remember the ISO standard numbers when typing command line
>> parameters, or is it better to include the ISO number just in the help
>> pages and documentation, but keep the mode name as it is to simplify it
>> for users?
> 
> Yeah, that's a thought I had as well. 

This was one of the reasons why I have chosen the short names.

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

Re: [fpc-devel] Specific RTL for embedded target

[Florian Klaempfl]

Am 20.11.2015 um 23:57 schrieb Simon Ameis:
>>
> So will FPC provide the compiler (and maybe an FPC-embedded linker for
> ARM) only?
> Or would be a reasonable goal to publish "default" device drivers for
> embedded targets?
> 

As Marco said: if somebody contributes patches, they are probably
integrated. The best would be probably to create some additional package
which contains such units.

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

Re: [fpc-devel] FPC 3.0.0-rc2 release

[Florian Klaempfl]

Am 21.10.2015 um 14:48 schrieb Max Nazhalov:
> 
> I doubt it ever had been working.. (that glitch I've seen and
> forgotten in a hurry some years ago)
> 
> Example [i386-win32 target]:
> var
>   a, b: array [0..111] of byte; // some arbitrarily not-so-large entities
> begin
>   a := b;
> end.
> 
> Result:
> ...
> mov edi,offset U_$P$PROGRAM_$$_A
> mov esi,offset U_$P$PROGRAM_$$_B
> mov ecx,28
> rep rep ;  ???
> callfpc_do_exit
> ...
> 

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

Re: [fpc-devel] FPC 3.0.0-rc1 release

[Florian Klaempfl]

Am 26.08.2015 um 08:45 schrieb Marco van de Voort:
 In our previous episode, LacaK said:
 i386, x86_64, PowerPC or Sparc processor
 Win32:
  - MS Windows NT/2000/2003/XP/Vista/7 (Win95, 98 and ME are not supported
in FPC officially any longer).
 But here is Win95,98,Me explicitly excluded.
 I think, that at first place it should be also excluded.
 
 Yup, and remove w2k and NT(4) too. While they might work, they are no longer
 formally supported and tested afaik.

Question is: if the first is the target system and the latter the host
system?

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

Re: [fpc-devel] avr port, feedback to changes until 30549

[Florian Klaempfl]

Am 12.04.2015 um 01:50 schrieb Georg Hieber:
 Florian,
 
 presently the make cycle aborts when compiling the compiler. In
 cgcpu.pas there ist a comment (code not working yet), line 770, inside
 a comment which causes an error. 

Fixed in r30554.

 after fixing that, both the compiler
 and the rtl are built without problems. So, apparently, the changes you
 made to take pressure off the register allocator work.
 
 Question: where is EXCLUDE_COMPLEX_PROCS defined?

rtl/embedded/system.pp

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

Re: [fpc-devel] RTTI interface variant late binding issue (mORMot)

[Florian Klaempfl]

I'll create a branch and commit the supplied patches so far, we can use
this branch to bring things into a reasonable shape.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bug or Feature? Inline of code from Units does not work when types uses in code are defined in implementation

[Florian Klaempfl]

Am 06.04.2015 um 17:53 schrieb Michael Ring:
 Take the following unit, my goal is to have the code called in the unit
 inlined in the main code.
 
 This works fine when
 
 type
   pLongWord = ^LongWord;
 
 is defined in the interface of the unit.
 
 if this is defined in Implementation then Inlining of the code does not
 work.
 
 Is this correct behaviour? Or should both ways work?

Inline is only a recommendation to the compiler. Such a definition in
the implementation part prevents indeed inlining.

In this particular case I recommend that you just leave the definition
away so compiler uses that one of the system unit.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] What means -Oodfa ?

[Florian Klaempfl]

Am 22.03.2015 um 15:53 schrieb Juha Manninen:
 There are some false positive warnings.

Trunk or fixes?

 For example this construct can be found in Lazarus IDE code frequently.
 
  function IDEDirectiveNameToDirective(const DirectiveName: string):
 TIDEDirective;
  begin
for Result:=Low(TIDEDirective) to High(TIDEDirective) do
  if CompareText(IDEDirectiveNames[Result],DirectiveName)=0 then exit;
Result:=idedNone;
  end;
 
 Compiled with -Oodfa gives :
  buildfiledlg.pas(406,44) Warning: Function result variable does not
 seem to initialized
 which is wrong.
 
 There are also thousands of hints about variable $self that make no
 sense to me, like :
  initialsetupdlgs.pas(563,27) Hint: Variable $self does not seem to
 be initialized
 How does the compiler come to that conclusion?

This should be fixed in trunk.

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

Re: [fpc-devel] Future of FPCUP tool

[Florian Klaempfl]

Am 21.02.2015 11:17, schrieb Marco van de Voort:
 In our previous episode, Juha Manninen said:
 rare that new people are interested to improve a tool, it should not
 be ignored.

 Should it be under FPC sources? If there is a motivated maintainer
 from outside, can he get commit access for it?
 
 My suggestion was to put it in fpcbuild, iirc Florian hasn't reacted to
 that.

Hmmm, I thought I did. At least I think for now that we should keep it
separate and see how things evolve. fpcbuild is for now a too strong
commitment imo.

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

Re: [fpc-devel] CMem allocator memory alignment experiment

[Florian Klaempfl]

Am 19.11.2014 12:32, schrieb Karoly Balogh (Charlie/SGR):
 Hi,
 
 On Wed, 19 Nov 2014, Jonas Maebe wrote:
 
 Since the RTL's allocator is documented to align to 16 bytes

 Where?
 
 Ok, that's actually a very good question. :) I didn't find it anywhere,
 except some earlier ML/forum posts revealed by Google.
 
 However, in practice it still seems to align to 16 bytes, and I asked
 several people (compiler, RTL, Lazarus developers) during the FPC/Lazraus
 conference last weekend in the Netherlands and the consensus was, it's
 known the heap manager aligns to 16 bytes, it's designed to do that, and
 in general it's a feature, which should be documented if it's not.
 
 But yeah, everyone appended but better ask Jonas. :)

From heap.inc:

  { we need to align the user pointers to 8 byte at least for
mmx/sse and doubles on sparc, align to 16 bytes }

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

Re: [fpc-devel] Building of FPC trunk broken on Darwin

[Florian Klaempfl]

Am 23.11.2014 16:50, schrieb Jonas Maebe:
 On 23/11/14 16:31, Joao Morais wrote:
 Trunk is broken on Darwin i386 since rev 29085 with the following message:

 =
 /Applications/Xcode.app/Contents/Developer/usr/bin/make echotime
 Start now 13:25:24
 /usr/bin/diff ppc3 ppc386
 Binary files ppc3 and ppc386 differ
 make[2]: *** [cycle] Error 2
 make[1]: *** [compiler_cycle] Error 2
 make: *** [build-stamp.i386-darwin] Error 2
 =

 Using both 2.6.2 or 2.6.4 as the starting compiler. Rev 29084 is nice.
 
 When reporting problems, always mention all steps that you took and
 extra parameters you specified. In this case, the problem only occurs if
 you use a variant of the -g parameter (which I only know because someone
 else reported it before): http://bugs.freepascal.org/view.php?id=27051

What about a OVERRIDECOMPARECHECK parameter for the makefiles?

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

Re: [fpc-devel] Masm

[Florian Klaempfl]

Am 07.11.2014 10:35, schrieb Adriaan van Os:
 Anybody with hands-on experience compiling with FPC for MASM, including
 the RTL ? The FPC compiler option is there. 

NASM ist probably supported better and should be able to generate a lot
of different object file types.

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

Re: [fpc-devel] Build packages 2.6.4 on arm/linux failed

[Florian Klaempfl]

Am 28.03.2014 21:36, schrieb Marc Weustink:


Hi, I was playing with GNUroot/debian on my android pad and installed fpc 2.6.0 
since 2.6.4 was not available.
After that I tried to build 2.6.4 from svn. However make all stopped when 
building fastcgi:

/usr/bin/make -C fastcgi all
make[1]: Entering directory `/home/fpc-2.6.4/packages/fastcgi'
/usr/bin/ppcarm fpmake.pp -n -Fu../../rtl/units/arm-linux 
-Fu../../packages/hash/units/arm-linux 
-Fu../../packages/paszlib/units/arm-linux 
-Fu../../packages/fcl-process/units/arm-linux 
-Fu../../packages/fpmkunit/units/arm-linux
/usr/bin/ld: warning: link.res contains output sections; did you forget -T?
/home/fpc-2.6.4/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi':
(.text+0x88): undefined reference to `_fini'
/home/fpc-2.6.4/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi':
(.text+0x90): undefined reference to `_init'
fpmake.pp(30,38) Error: Error while linking
fpmake.pp(30,38) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
make[1]: *** [fpmake] Error 1
make[1]: Leaving directory `/home/fpc-2.6.4/packages/fastcgi'
make: *** [fastcgi_all] Error 2


2.6.x does not warn if it misses init files: debian recently changed the 
locations of the init files.


So fixes probably misses r22004, r22416 and r23892.

Please try to compiled with OPT=-Fl/usr/lib/arm-linux-gnueabi
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC and Windows Phone 8

[Florian Klaempfl]

Just a note: trunk supports now to generate hardfloat arithmetics with 
thumb enabled.

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

Re: [fpc-devel] FPC and Windows Phone 8

[Florian Klaempfl]

Am 19.03.2014 15:10, schrieb Vsevolod Alekseyev:

With -CpARMv7M, I presume? Thanks, I'll try.


Yes. What kind of thumb is generated depends on the -Cp switch.



On 3/19/2014 9:42 AM, Florian Klaempfl wrote:

Just a note: trunk supports now to generate hardfloat arithmetics with
thumb enabled.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



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



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

Re: [fpc-devel] Issue 0025028 (Florian)

[Florian Klaempfl]

Am 20.02.2014 02:58, schrieb Flávio Etrusco:


If Delphi indeed behaves like that then maybe it's valid RFE for Delphi mode.
OTOH automatically generating a GUID defeats a few features of having
a stable GUID. And even if fpc could avoid modifying the GUID on every
modification inside the unit by reading the PPU (which I don't believe
it does), deleting the PPU would modify it. And then there's the added
(little?) overhead, and the cases where you really don't want to allow
IS and AS, and probably other technical implications I'm not aware ;-)


Indeed, furthermore, there might be reasons where people want interfaces 
without GUIDs and pascal is a language which tries to prevent to do 
things implicitly.

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

[fpc-devel] Test, please ignore

[Florian Klaempfl]

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

Re: [fpc-devel] Optimizations

[Florian Klaempfl]

Am 24.01.2014 09:32, schrieb Sven Barth:

Am 24.01.2014 02:03, schrieb Martin Frb:

There is a bigger example, where exactly that was done, because FPCs
optimization was not sufficient enough for what the author wanted.
http://bugs.freepascal.org/view.php?id=10275

In that context... @Florian: how is your SSA support coming along? :)


Still WIP :) But a lot of my commits from the last weeks are spin-offs
of the SSA work.

Together with all other improvements this results in significant better
code:

fpc -l -O3 sha256.pp -S2
Free Pascal Compiler version 2.6.2 [2013/02/12] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling sha256.pp
Linking sha256.exe
74 lines compiled, 0.1 sec , 26016 bytes code, 2220 bytes data

fptime sha256
Expected: 3994057095, got 3994057095
483.000 ms


pp -n @c:\fpc\bin\fpc.cfg -l -O4 sha256.pp -S2
Free Pascal Compiler version 2.7.1 [2014/01/25] for i386
Copyright (c) 1993-2013 by Florian Klaempfl and others

fptime sha256
Expected: 3994057095, got 3994057095
367.000 ms
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Test, please ignore

[Florian Klaempfl]

Am 25.01.2014 17:06, schrieb Florian Klaempfl:

Sorry, I forgot to setup up cleaning up backups so the mailing list 
server ran out of disk space. So it stopped working, it should be back 
again.

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

Re: [fpc-devel] More peephole

[Florian Klaempfl]

Am 23.01.2014 21:15, schrieb Martin Frb:

On 23/01/2014 20:04, Florian Klämpfl wrote:

Am 23.01.2014 20:52, schrieb Martin Frb:

On 23/01/2014 19:35, Florian Klämpfl wrote:


I think this is hard to achive as well.


Why?

I consider it as complicated and it covers only cases one can forsee.
Some statistical analysis of benchmark timings and procedure sizes is
imo much more general.



Ok, so we were talking about 2 different targets.

You were talking (if I understand correct) about a general test for any
and all forms of regressions (with regards to speed or size / not with
regards to function) in code generation.


Yes.


This is indeed hard to test.
Size may be do able by comparing to a known size that was once archived
/ size may increase or decrease, but then tests need to be fixed
(decrease must be fixed, so that increase from the new optimum will then
be detected.)
Speed is indeed very hard. Since even a benchmark may vary.


Yes, but having n=5 and doing daily benchmarking should one enable to 
identify trends.





I was talking about checking for specific/known code snippets that are
known to be inefficient (so anything that the peephole generator
can/could detect). This is only a small subset of the possible
speed/size regressions, but it is at least something.


Yes and no. It is extra code and extra code is always bad ;) and it 
requires a separate compiler run. I wouldn't waste effort in it.

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

Re: [fpc-devel] Little feature teaser

[Florian Klaempfl]

Am 03.08.2013 23:31, schrieb Sven Barth:

On 03.08.2013 22:50, Florian Klämpfl wrote:

Am 03.08.2013 17:19, schrieb Sven Barth:

On 03.08.2013 13:12, Florian Klämpfl wrote:



First, FPC does not loop unrolling by default, you need -Ooloopunroll,
second, the loop is relatively long, so let the compiler assume a long
pipeline with - Cppentium4



-Oopentium4 it is.


Are you sure that you don't mean -Oppentium4? The compiler complains
with —Oopentium4. And it doesn't change anything (also with
-Ooloopunroll) :(


There was indeed a mistake in optunroll.pas, -Oppentium4 -Ooloopunroll
should work now.


Jupp, it indeed works now. Now the compiler would just need to detect
that the for loop is basically only using constants and evaluate that at
compile time... but that's a wish for another day ;)


I think item 635365 of my todo list, the autovectorizer would solve it ;)

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

Re: [fpc-devel] Bug: Alignment issue with dwarf debug_info on mipsel(-embedded)?? code

[Florian Klaempfl]

Can anybody help with a fix?

Do I understand it correctly, that it is sufficient so replace .long by
.4byte and .short by .2byte at all locations? Does it apply to all targets?


Please tell me if r25054 helps.

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

Re: [fpc-devel] FPC SoftFPU implementation

[Florian Klaempfl]

Am 12.06.2013 15:45, schrieb Max Nazhalov:

Wednesday, June 12, 2013, 4:00:52 AM, Florian wrote:

FK Am 09.06.2013 18:22, schrieb Max Nazhalov:


Could this patch be reviewed and accepted/adapted/rejected?


FK Thanks, I applied it and fixed a few more things.

Thanks a lot! Just two addition notes:

1. Catched another 4 missing exits


Thanks, applied.


2. r24872 seems to revert r24864 by Pierre Muller (see above in mail list) --
was this intended?..



This was a mistake, I fixed it.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

[Florian Klaempfl]

Am 06.03.2013 14:16, schrieb Martin Schreiber:

On Sunday 03 March 2013 18:35:53 Martin Schreiber wrote:

On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On
Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3


A last one, simple MSEgui demo, one form, a fancy tlabel, one
button: http://mseide-msegui.sourceforge.net/pics/kylix3.png

Program size Kylix 3: -rwxr-xr-x 1 mse users 1038420 Mar  6 13:28
kylixdemo

FPC 2.6.2, commandline: ppc386 -okylixdemo
-Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/linux/
-Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/
-Fi/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/
-Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/*/ -B -O2
-CX -XX -Xs kylixdemo.pas Program size: -rwxr-xr-x 1 mse users
1252204 Mar  6 14:10 kylixdemo


Without the used sources it is of very little use.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] [patch] Mantis issue 9961

[Florian Klaempfl]

Am 10.03.2013 18:53, schrieb Aleksa Todorovic:

Hi, FPC developers!

I've commited patch to issue 9961 few days ago, and I'd like to ask if
someone could take a look at it? I'm currently analyzing several other
unit-loading issues (10551, 18294) with similar situations (relative
paths, different unit loading order when compiling and loading ppu),
but I'd like to get opinion on solution for issue 9961, if it's
possible :)


It looked good to me, thanks! I committed it as you might have noticed.

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Florian Klaempfl]

Am 06.03.2013 11:12, schrieb Michael Schnell:

So (as with all x86 variants) no library
or system call is necessary.


Wrong. This is not true in the general case, please read the appropriate 
api documents.




With Cortex, this has changed to the use of the CP15 Register (freeing
A9 to allow for better optimization). Now, CP15 is in fact not very
suitable for this purpose, as it can only be accessed with privileged
instructions and thus not in user mode (where the TLS in fact is
invented for).Thus a system call (or trap) is needed to get the address
of a threadvar.


Wrong. On linux this can be done by a jump to a certain adress.


Conclusion:

With FPC, the optimization of threadvar access is not necessary. Instead
it is highly recommended to always use thread specific instances of the
classes that do the threaded work. TThread of course provides this out
of the box.



And how does one the current TThread?

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

Re: [fpc-devel] Delphi anonymous methods

[Florian Klaempfl]

Am 05.03.2013 11:10, schrieb Paul Ishenin:

05.03.13, 17:55, Sven Barth wrote:


@Paul: see? :)


I see you, Graeme, Michael and probably some more 5-6 developers.


Even if those are the only ones, from the beginning, FPC tried to 
support all niches. And if someone maintaines a certain niche, the niche 
will be continued to be support. Actually, I think FPC lives from niches 
and developers working on niches.


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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Florian Klaempfl]

Am 02.03.2013 13:24, schrieb Marco van de Voort:

In our previous episode, Florian Kl?mpfl said:

(for example renaming all files to .pp takes off +/- 1 second here)

Nevertheless, I'd be interested in seeing the strace.


Better parallize the building using some build units. Then it will be
probably compiled in less than 10 sec on a modern CPU.


Better paralellize the compiler :-)


In theory yes but I still fear that the threadvars and synchronization 
eats much of the advantage in this case.


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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Florian Klaempfl]

Am 02.03.2013 15:15, schrieb Craig Peterson:



On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt
mich...@freepascal.org wrote:


If you hire 2 painters to paint the whole of your house, and one
doesn't paint the inside, because you don't see it from the
outside, of course he will be finished faster; he didn't perform
the same work.


Delphi is generating enough information that you can debug using it.
The fact that its debugger is built in and FPC requires an external
debugger that can't read the .ppus is an implementation detail.  A
more apt comparison would be that we hired the painters to paint the
outside of the house and one of them did the inside too because his
tools require him to paint both sides of the walls.



While the other one can paint only in one color and only buildings with 
one floor ;)

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Florian Klaempfl]

Am 02.03.2013 16:23, schrieb Marco van de Voort:

In our previous episode, Florian Klaempfl said:

Better parallize the building using some build units. Then it will be
probably compiled in less than 10 sec on a modern CPU.


Better paralellize the compiler :-)


In theory yes but I still fear that the threadvars and synchronization
eats much of the advantage in this case.


I don't see why there would be more synchronization overhead than make?


In a parallelized compiler symtables etc. might be shared and this might 
require a lot of synchronization to prevent data corruption.
With make, the different units can be seperated much better by a human 
than the compiler can do.


Not to mention the huge effort it would be to get the compiler 
parallelized internally.


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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Florian Klaempfl]

Am 02.03.2013 17:24, schrieb Marco van de Voort:

In our previous episode, Florian Klaempfl said:

I don't see why there would be more synchronization overhead than make?


In a parallelized compiler symtables etc. might be shared and this might
require a lot of synchronization to prevent data corruption.
With make, the different units can be seperated much better by a human
than the compiler can do.


Only if you want to avoid multiply used units to be only once in memory.
IMHO if you are afraid of that, then don't do that :-)


Forking compilers on a by unit level instead of some meta level is 
typically slower because reading ppus takes a lot of time.





Not to mention the huge effort it would be to get the compiler
parallelized internally.


As said the first step can be relatively simple. Get rid of globals some
more, and then only the parts before compile() needs to be changed.


In theory, yes. In practice this is a huge effort. Just one example: 
inlining requires that the node tree of a procedure is copied. However, 
during copying the tree is annotated for proper copying. Bottom line: 
even if the compiler finished to compile a unit, the generated info is 
not read only.


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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Florian Klaempfl]

Am 02.03.2013 16:49, schrieb Michael Van Canneyt:

All this said: You will not hear me claiming that there is no room for
improvement in FPC.
I'm sure there is. However, I do not think we'll be able to match
Delphi's speed without sacrificing the main goal of FPC: to support as
much platforms as possible.


Well, not to mention the goal of maintainability.

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

Re: [fpc-devel] Refr Bruhl

[Florian Klaempfl]

Am 22.02.2013 15:36, schrieb Refr Bruhl:

http://wwwp2t


Please do not click the link in this mail, it is probably malware/spam. 
I have set the moderation flag for Refr Bruhl. Sorry for any 
inconvenience caused by this.


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

Re: [fpc-devel] Summer of code collaboration

[Florian Klaempfl]

Am 10.02.2013 15:23, schrieb Vittorio Giovara:

Indeed, a fpc-js code generator would have a rather limited use. A
LLVM backend instead could be use on many more levels, and for example
could improve (or replace) the compilation process on iOS.


Improve in which regard? Experience showed that the more tools involved 
the less comfortable the use of FPC is. Within a few minutes you can 
build on any platform a win32 cross compiler (if the CPU is fast enough) 
because no external tools are involved. Compare this with cross 
compiling to linux (no to talk about darwin): takes usually 1-2 hours to 
setup: first, download, configure and build binutils, then sort out the 
libraries and copy them to host system, and then with some luck (if 
binutils are not broken), building fpc might work.

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

Re: [fpc-devel] Summer of code collaboration

[Florian Klaempfl]

Am 10.02.2013 15:23, schrieb Vittorio Giovara:

Indeed, a fpc-js code generator would have a rather limited use. A
LLVM backend instead could be use on many more levels, and for example


Not to mention that I estimate that full llvm support with debugging and 
extending llvm to support everything required by fpc might be more 
something like 1-2 years of full time work than a few summer months of 
work of a student.


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

Re: [fpc-devel] Forwarded message about FPC status

[Florian Klaempfl]

Am 25.12.2012 12:38, schrieb Michael Van Canneyt:



On Tue, 25 Dec 2012, Martin Schreiber wrote:


On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote:


Everybody is aware of the speed difference between Delphi and FPC.

The compiling itself (parsing/producing assembler code) is not slow.


From what I remember, the problems you (and everyone else) experience


with smartlinking and so on are largely due to the GNU linker being
slow and memory hungry.


AFAIK there are significant differences in parsing and code producing
too.


I suggest that Florian answers this, he has more exact numbers.



I see no way to speed up the 2.x FPC significantly only by stripping 
something down or whatever. The whole 2.x design is geared towards 
portability and maintainability, speed is only 2nd level goal (and being 
honest, self compilation in ~10 sec even on my 5 year old Core 2 Duo is 
not that bad ;)).


The only approach I see to speed it up is to kick the whole back end and 
generate directly some close to i386 intermediate code directly in the 
parser.


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

Re: [fpc-devel] Forwarded message about FPC statusy

[Florian Klaempfl]

Am 25.12.2012 13:39, schrieb Yury Sidorov:

It is possible to seed-up compilation by allocating memory for nodes
from some zero pre-filled memory pool to avoid costly calls to heap
manager and avoid zero filling of small memory chunks. A base class for
various FPC nodes should be modified to handle aloocation from the pool...


The heap manager itself does already pooling so I don't see much gain in 
doing so ...


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

Re: [fpc-devel] Forwarded message about FPC statusy

[Florian Klaempfl]

Am 25.12.2012 14:53, schrieb Jy V:


Although FPC heap manager is good, but custom pool memory allocation
will be much faster, since it will be very simple:

  Result:=CurPoolPtr;
  Inc(CurPoolPtr, BlockSize);
  if CurPoolPtr  MaxPoolPtr then AllocNewZeroFilledPool();

It is not needed to handle memory releases during object
destruction. Since all nodes are available during whole compiling
phase (parsing, code generation, etc) and released only at the end
of a phase, it is possible just to release whole pool blocks at the
end of a phase.

Such pooled base class for compiler nodes should inrease performanse
a lot.


I do agree,
you should consider his position.


The total time FPC spend in memory manangement is 20% iirc. So I don't 
see much optimization potential here.


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

Re: [fpc-devel] Forwarded message about FPC status

[Florian Klaempfl]

Am 25.12.2012 14:44, schrieb Jy V:


The only approach I see to speed it up is to kick the whole back end
and generate directly some close to i386 intermediate code directly
in the parser.


Is this close i386 intermediate code similar to IR LLVM generation ?


No. It must be much closer to i386 else there is no speed advantage over 
the current approach.



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

Re: [fpc-devel] Forwarded message about FPC status

[Florian Klaempfl]

Am 25.12.2012 15:04, schrieb Sven Barth:

On 25.12.2012 14:15, Florian Klaempfl wrote:

The only approach I see to speed it up is to kick the whole back end and
generate directly some close to i386 intermediate code directly in the
parser.


Ewww... please not...


No, we would be back in pre 1.0 times :) Not to mention the fact that 
writing such a backend probably takes one year of work.


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

Re: [fpc-devel] Forwarded message about FPC statusy

[Florian Klaempfl]

Am 25.12.2012 14:59, schrieb Yury Sidorov:

From: Yury Sidorov j...@cp-lab.com

From: Florian Klaempfl flor...@freepascal.org


Am 25.12.2012 13:39, schrieb Yury Sidorov:

It is possible to seed-up compilation by allocating memory for nodes
from some zero pre-filled memory pool to avoid costly calls to heap
manager and avoid zero filling of small memory chunks. A base class for
various FPC nodes should be modified to handle aloocation from the
pool...


The heap manager itself does already pooling so I don't see much gain
in doing so ...


Still zero-filling a million of small memory chunks is very time
consuming. It is better to pre-zerofill big pool blocks first and then
assueme that memory already zero fillled in custom object init code.

Although FPC heap manager is good, but custom pool memory allocation
will be much faster, since it will be very simple:

 Result:=CurPoolPtr;
 Inc(CurPoolPtr, BlockSize);
 if CurPoolPtr  MaxPoolPtr then AllocNewZeroFilledPool();

It is not needed to handle memory releases during object destruction.
Since all nodes are available during whole compiling phase (parsing,
code generation, etc) and released only at the end of a phase, it is
possible just to release whole pool blocks at the end of a phase.

Such pooled base class for compiler nodes should inrease performanse a
lot.


Hmm, Seems to be a false alarm :(

I've made some tests just now with memory allocation and found that such
pooling will not speed up the compiler too much. Only minor improvement
such as 10-20% :(


Ops, messages crossed :) I'd expect no more. One thing might be to 
rewrite the whole unit handling so that symtables etc. can be 
read/written as one block to PPUs but doing so might be also pretty time 
consuming and I doubt the maintainability of such an approach.


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

Re: [fpc-devel] Forwarded message about FPC statusy

[Florian Klaempfl]

Am 25.12.2012 15:11, schrieb Paul Ishenin:

25.12.12, 21:59, Yury Sidorov пишет:


Hmm, Seems to be a false alarm :(

I've made some tests just now with memory allocation and found that such
pooling will not speed up the compiler too much. Only minor improvement
such as 10-20% :(


10-20% is still much better than nothing.


Yes, but you might also pay with a higher memory footprint which might 
even eat this speed advantage under certain circumstances.


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

Re: [fpc-devel] Forwarded message about FPC statusy

[Florian Klaempfl]

Am 25.12.2012 15:17, schrieb Yury Sidorov:

From: Paul Ishenin paul.ishe...@gmail.com


25.12.12, 21:59, Yury Sidorov пишет:


Hmm, Seems to be a false alarm :(

I've made some tests just now with memory allocation and found that such
pooling will not speed up the compiler too much. Only minor improvement
such as 10-20% :(


10-20% is still much better than nothing.


Sure, but I would be happy to expect at least 2X increase :) In such
case I would start coding the fix right now :)


Believe me, if it was so easy, I would have it done for years ;)

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

Re: [fpc-devel] Forwarded message about FPC statusy

[Florian Klaempfl]

Am 25.12.2012 15:28, schrieb Mattias Gaertner:

On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:


[...]
The numbers Martin names (up till 10 times slower, even without linking) are
the numbers I have in mind too. IMHO denial without tests is unfair.


Maybe the parallelization could be improved?


Yes, this might be a good solution for the future but last time this 
topic came up, Martin still wanted to run FPC on some almost 10 years 
old machine so parallelization does not help. Another thing would be an 
fpc compiler daemon which stays in memory between compilations and keeps 
also ppus loaded.



This would allow to keep
the many features of fpc.



I had a setup where I compiled zeos with FPC and Delphi (which doesn't
link), and iirc the results were also 7-10times, with delphi XE.

When I'm home after Christmas I'll play a bit and see if I can duplicate the
experiments with Delphi XE3.



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



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

Re: [fpc-devel] Forwarded message about FPC status

[Florian Klaempfl]

Am 25.12.2012 19:30, schrieb Dimitri Smits:

I'm guessing that is NOT on a Windows platform? Every full build (it
has been a while) I've ever done of the compiler on windows was at
least a few minutes.


It is windows: self compilation. No rtl building or whatever.




The only approach I see to speed it up is to kick the whole back
end and generate directly some close to i386 intermediate code
directly in the parser.


lovely, but isn't that what Embarcadero is doing for their future
compiler?


No. It is exactly the counterpart. llvm intermediate language is for 
sure as much as possible platform independent and not close to i386 as 
I wrote. If one wants to accelarate FPC by one magnitude one cannot 
fiddle with some abstract intermediate layer but output already from the 
parser something as close as possible to i386 machine code, do register 
allocations and optimizations on it and write the machine code to disk.



Using the llvm toolchain, they will provide a front
compiler to an intermediate language or interpreted code. Then they
have a few optimisations for the middle layer and use the back-ends
that are already available to make stuff architecturally compile to
whatever back-end (ARM v?, intel x86, powerpc, motorola 68k, jvm,
dalvik, .net il, compiled php, ... or any community or custom
backend)


... and this costs time. And it is similiar to FPC's approach.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Forwarded message about FPC statusy

[Florian Klaempfl]

Am 25.12.2012 19:39, schrieb Mattias Gaertner:

On Tue, 25 Dec 2012 18:01:50 +0100
Florian Klaempfl flor...@freepascal.org wrote:


Am 25.12.2012 15:28, schrieb Mattias Gaertner:

On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:


[...]
The numbers Martin names (up till 10 times slower, even without linking) are
the numbers I have in mind too. IMHO denial without tests is unfair.


Maybe the parallelization could be improved?


Yes, this might be a good solution for the future but last time this
topic came up, Martin still wanted to run FPC on some almost 10 years
old machine so parallelization does not help. Another thing would be an
fpc compiler daemon which stays in memory between compilations and keeps
also ppus loaded.


Do you mean as separate process?


Yes. ppcxyz would be only a front end to this daemon process/service.

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

Re: [fpc-devel] Re: FPC related fairy tale

[Florian Klaempfl]

Am 18.10.2012 22:16, schrieb Sven Barth:

On 18.10.2012 13:13, Sven Barth wrote:

Over the past weeks I've spent some time on getting something to work in
FPC and now I'm about to commit this either this evening or at least
this weekend (depending on the time I have).


I've now commited my changes, but currently the compiler for m68k can
only be build from within an IDE (e.g. Lazarus) as the makefile
immediately complains that ppcross68k is missing if I want to start a
make cycle CPU_TARGET=m68k (or a make all CPU_TARGET=m68k). It works
for other CPUs though... (besides the point that FPC currently can't
cycle on a i386-linux...)
Does anyone know what the problem could be for m68k?


Wrong naming somewhere in the makefile? Anyways, here it stops with
c:/fpc/svn/compiler/ppc.exe -Ur -Xs -O2 -n -Fum68k -Fusystems 
-Fuc:/fpc/svn/rtl/units/i386-win32 -Fi
m68k -FE. -FUm68k/units/i386-win32 -dRELEASE-dm68k -dGDB 
-dBROWSERLOG -dNOOPT -Sew pp.pas

cpupara.pas(52,90) Error: Identifier not found tcpuregisterset
cpupara.pas(52,20) Error: There is no method in an ancestor class to be 
overridden: procedure get_v

olatile_registers_int(tproccalloption):erroneous type;
cpupara.pas(59,3) Fatal: There were 2 errors compiling module, stopping

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

Re: [fpc-devel] stellaris launchpad

[Florian Klaempfl]

Am 16.09.2012 17:53, schrieb Daniël Mantione:



Op Sun, 16 Sep 2012, schreef Luca Olivetti:


but I don't know the outcome. Is it currently possible to develop
software
for that mcu with freepascal?


As far as I know the Cortex M series cannot run generic ARM code; it
only understands the Thumb2 instruction set.


FPC supports Thumb-2 code generation and arm-embedded supports also some 
stellaris types (LM3S* types) so it should be possible with little 
effort to compile programs with FPC for this device. But maybe Jeppe can 
say more.

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

Re: [fpc-devel] FPC compiler architecture documentation

[Florian Klaempfl]

Am 31.08.2012 09:32, schrieb Michael Schnell:

On 08/30/2012 10:20 PM, Florian Klaempfl wrote:

 I doubt that a good developer needs such a document to get into the
compiler...


Hmmm.

I once thought about trying to do an fpc compiler for a not yet
supported arch, and I still am interested in having (AKA contributing to
such an effort) an up to date fpc compiler for as well 68K as PIC32
(AFAIK identical to a certain version of MIPS32). I doubt that I would
even be able to start, unless an up-to-date documentation of the
appropriate parts of the docu is available.


The big picture which could be documented is the easy part. But such a 
document can never cover all details and the details are the hairy part. 
Like certain properties of the target architecture might be special and 
not yet covered by the compiler thus they cannot be documented. They are 
the challenging and time consuming part when adding a new architecture.

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

Re: [fpc-devel] FPC compiler architecture documentation

[Florian Klaempfl]

Am 30.08.2012 13:42, schrieb Marco van de Voort:

In our previous episode, Graeme Geldenhuys said:

I found this old PDF documenting the FPC compiler architecture. I
remember in recent years others attempted to do a similar thing. I don't
know how accurate this PDF still is, considering it is based on FPC
v1.x,


Not really I think.

I converted it from the original word document to latex/pdf. The source
is in fpcdocs/internal directory
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/internal/?root=docs

Still waiting for sb to actualize it.


While it still might an interesting reading for somebody not involved in 
the compiler development I doubt it's usefulness. It requires a lot of 
work of some of the compiler developers but I doubt that a good 
developer needs such a document to get into the compiler so updating the 
document is wasted time in the sense of bringing the compiler forward.

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

Re: [fpc-devel] Does FPC optimize unused parameters ?

[Florian Klaempfl]

Am 24.08.2012 13:48, schrieb Jonas Maebe:


Martin wrote on Fri, 24 Aug 2012:


On 24/08/2012 12:04, Jonas Maebe wrote:


Martin wrote on Fri, 24 Aug 2012:


The above takes the first of the overloaded.
All bodies are empty.

procedure DebugLn(const s: string = ''); inline; overload;


That looks like a very serious bug introduced in the handling of
parameters to inlined routines. Florian changed several things there
over the last couple of months, maybe he has an idea.


Yes, r21445 is guilty. para.left should be checked with 
might_have_sideeffects if refs=0 if it really could be removed.


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

Re: [fpc-devel] about freepascal for mips

[Florian Klaempfl]

Am 25.05.2012 21:04, schrieb Jeppe Græsdal Johansen:


I managed to remove the errors with the following patch, such that
everything compiled, but I haven't been able to test it:
http://j-software.dk/fpc-mipsel.patch


All fixes of the patch are committed, I solved some things differently 
though.


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

Re: [fpc-devel] about freepascal for mips

[Florian Klaempfl]

 
  And the whole code seems totally incompatible with standard mips abi,
 it use 6 registers to pass parameters, while o32 has 4.

cpupara needs a major overhaul. This is one of the next things I planned
to do.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.

[Florian Klaempfl]

Am 11.03.2012 12:01, schrieb peter green:
 It appears to me (i'm not  an expert on arm assembler and I can't seem
 to find any documentation on FPA) that FPC is generating FPA
 instructions even though the FPU is set to a VFP type. What i'm really
 struggling to work out is why the heck that is happening. From telling
 freepascal to include source lines as comments in the assembler it
 doesn't look like inline assembler is responsible.

Can you please post the full assembler listing of a procedure containing
such code?

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

Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.

[Florian Klaempfl]

Am 11.03.2012 13:22, schrieb Jonas Maebe:
 * I'm don't think that requiring yet another different ARM compiler
 binary for this is the proper way. There's already enough confusion
 as it is with ppcarm variants.

But isn't this caused by the fact that we have the same executable name
while it generates different code? I currently think that having even
arm/armeb/armel/armhf as cpu types is the way to go. This allows also to
have units for all four flavours on one system. Currently we simply
don't support the same target cpu but different abi in any way in the
build system.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.

[Florian Klaempfl]

Am 11.03.2012 15:37, schrieb Jonas Maebe:
 
 On 11 Mar 2012, at 15:14, Florian Klaempfl wrote:
 
 Am 11.03.2012 13:22, schrieb Jonas Maebe:
 * I'm don't think that requiring yet another different ARM
 compiler binary for this is the proper way. There's already
 enough confusion as it is with ppcarm variants.
 
 But isn't this caused by the fact that we have the same executable
 name while it generates different code?
 
 Yes.
 
 I currently think that having even arm/armeb/armel/armhf as cpu
 types is the way to go. This allows also to have units for all four
 flavours on one system. Currently we simply don't support the same
 target cpu but different abi in any way in the build system.
 
 We also don't support an RTL compiled with -Cp386, -Cppentium,
 -Cppentium2, -Cppentium2, -Cppentiumm, -Cfx86, -Cfsse2 and/or -Cfsse3
 on the same system. 

True, but they are not different abis, debian does not treat them
different either.

 For ARM hard float, you will also need different
 sets of units depending on the exact kind of VFP cpu you have (unless
 you always target the lowest common denominator -- if something like
 that even exists for all VFP variants, since ARM is not that big on
 backward compatibility and they have their own standard of encoding
 the entire ABI, target cpu and all other details into attributes
 inside every generated object file so that the linker can verify the
 compatibility).

But the abi stays on all hard float platforms the same? Indenpendent of
the instruction set.

 
 Whether it's ABI or minimally required target cpu, the part that
 causes the trouble is that you need a different set of units. I don't
 think that renaming the compiler binary just for this particular case
 is the right approach.

Since the same compiler executable cannot run on the other platforms, I
think naming them differently is reasonable.

In general, I'd take the debian architecture scheme as measure.


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

Re: [fpc-devel] Bounty for MIPS

[Florian Klaempfl]

Am 03.02.2012 01:37, schrieb Nikolai Zhubr:
 Hi,
 31.01.2012 0:08, Pierre Free Pascal:
 Anyhow, I just discovered that
 the /home directory is 99% full on that GCC compile farm machine,
 meaning that only  remote tests will be possible ☹

 It seems that lots of developers have the same issue about finding
 MIPS machines for testing ….

 Would you consider the NetGear WNDR3800 680Mhz, 128MB RAM with a USB
 Flash drive of 32GB to be good enough for the development of the FPC
 toolchain ?
 (in this case, I can purchase and ship such device to your place),

 or would you consider that only a qemu virtual MIPS machine which can
 handle more memory and more disk space to be suitable for the
 development ?

I just googled a bit and read that the
 USB flash drives are considered as having only a limited number of writes
 before that fail... (http://en.wikipedia.org/wiki/USB_flash_drive)
 So I wonder how long such a system like that would last (it probably
 also depends on
 the USB key quality itself?) if I run the testsuite each night
 on it...

   Would a small USB hard drive be better? But does the device
 have enough power to support such an external drive?
 Would the speed be significantly lower or is the USB 2.0
 speed the real limitation?
 
 Ok. Debian installer ran amazingly smooth and apparently debian is quite
 happy with openwrt's kernel. 

How did you install debian? Or is it a chroot'ed debian?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Pointer cache for fast class/pointer access.

[Florian Klaempfl]

Am 21.01.2012 14:25, schrieb Sven Barth:
 On 20.01.2012 11:18, Skybuck Flying wrote:
 Finally if you do believe prefetching is a good alternative to a pointer
 cache or simply want to try out the effect of prefetching class pointers
 then I challenge you to implement it in a experimental branch of the
 free pascal compiler, so the prefetch idea can be tried out and tested !
 
 Why don't you try yourself whether it has a positive effect? prefetch
 is already part of FPC's RTL since quite some time:
 http://www.freepascal.org/docs-html/rtl/system/prefetch.html

... and the compiler itself uses it already for several years.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Stack alignment on i386

[Florian Klaempfl]

Am 22.12.2011 17:56, schrieb Jonas Maebe:

 Keeping an aligned stack requires completely different code generation
 inside the calling routine, you can't implement that on a call-by-call
 basis.

Intel defined once how procedure entry/exit code should look like for
procedures doing 16 byte alignment by themself.

Of course, main problem is, this requires another register on i386.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] rounding precision error with integer and floating point division

[Florian Klaempfl]

Am 17.11.2011 20:51, schrieb Seth Grover:
 
 Although I can avoid the problem by casting the longword to a double

How should the compiler know that the division should be done using
double? Using always double slows down calculations. Because the range
of longword fits into a single as well as 24, fpc uses a single division.

 point before the division, this seems like it should be done
 automatically to make results across architectures consistent. 

This is not possible. Especially i386/x87 behaves really strange because
it does calculations always with extended.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] ARM native compilation (Toshiba AC100)

[Florian Klaempfl]

Am 22.09.2011 11:51, schrieb Henry Vermaak:
 On 22 September 2011 10:26, Mark Morgan Lloyd
 markmll.fpc-de...@telemetry.co.uk wrote:
 I got from there to 2.4 via (I think) 2.5 with Jonas's help, and since then
 have moved it between local machines as a binary. I can confirm that 2.4.4
 will build FPC trunk (2.7.1) on ARM, and that that can build Lazarus trunk.
 
 I got 2.4.4 here:
 
 ftp://ftp.freepascal.org/pub/fpc/dist/2.4.4/bootstrap/
 
 Maybe we should upload your 2.4.4 ppcarm if it compiles trunk without 
 problems.

Toshiba AC100 is armel (arm eabi) while fpc arm-linux (arm oabi)? While
this might work under certain circumstances, I wouldn't bet on it.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Issue 20124: Error with static direct field properties

[Florian Klaempfl]

Am 01.09.2011 17:48, schrieb Alexander Klenin:
 [Is there any method to either comment on or re-open resolved isses?
 It is very frustrating to be forced to switch comminication channel]
 
 I think this issue is resolved prematurely.
 First, I do not see a reason why normal property can not be
 implemented by static field.
 Second, even is such a reason is provided, compiler should error out
 instead of generating bogus code
 (Optimal solution would be to issue a warning or hint and generate
 correct code).
 Either way, no change required is IMHO wrong resolution.
 

Maybe you should reread Jonas' comment? Apparently something in trunk
has been changed regarding this already.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Const optimization is a serious bug

[Florian Klaempfl]

Am 07.07.2011 08:35, schrieb Alexander Klenin:
 As further support for #1, consider: With a class, you do not have to pass
 it to a procedure as var, but when you modify the instance, you modify the
 same instance as was passed to the procedure. That is how classes work.
 Having a variable point to the same object as another variable does in fact
 mean it's the same instance, the same object. That is Object Pascal's object
 model. But with strings, if you want to modify the string in a procedure and
 have that affect the argument initially passed to the procedure you *have*
 to use var. That alone should be convincing evidence that the programmer is
 always supposed to be able to assume that unique variables are unique
 instances for automatically managed strings and arrays.
 This is also a good argument which I omitted before in the interests of 
 brevity.
 
 Put in another words, current const string implementation honors the
 implicit contract of
 adding const in front of the string parameter cancels refcounting,
 at the cost of breaking the implicit contract of refcounted values
 are indistinguishable
 from simple values (except maybe in performance).

As I have shown before in this thread, non ref. counted values e.g.
shortstrings are affected by the same problem.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Const optimization is a serious bug

[Florian Klaempfl]

Am 04.07.2011 22:39, schrieb Chad Berchek:
 I've been reading over some of the recent discussion about reference
 counting problems with const string parameters. I've done some
 experiments and I believe that the so-called const optimization is a
 serious flaw, not just a corner case of questionable legitimacy. I have
 some sample code I will show which should be quite scary. Additionally,
 this is a security vulnerability. It is also a quiet bug, because it may
 go undetected for a long time but randomly result in unreproducible
 crashes.
 
 Consider:
 * It does not affect just global variables but also object fields. While
 global variables are used rarely, object fields are used constantly in OOP.
 * It does not affect just strings but also interfaces and dynamic arrays.

It affects more types, even shortstring suffers from it, the program
does not crash but might behave not as expected (similiar examples can
be created for normal arrays or records as well):

var
  s : shortstring;

procedure p(const s1 : shortstring);
  begin
s:='Ops';
writeln(s1);
  end;

begin
  s:='Hello world';
  p(s);
end.

I see it only as a either or all or none: either the const optimization
is done for no types or for all types where it's useful. Everything else
is even more dangerous (if you consider this behaviour as dangerous)
because the outcome is unpredictible. However, I doubt that people will
be happy, if huge data arrays, records or shortstrings are always copied
and no const optimization is carried out.

As written in some of the bug reports, I consider as a better solution:
- Pointer checking of constant parameters of types like ansistrings,
interfaces at procedure exit. Together with heaptrc and keep_released
enabled, this catches all cases of disposed const parameters and
probably a lot more pointer errors.
- Like the scrambling of local parameters with -gttt, some checksumming
for contant parameters could be implemented. This catches not only the
modified constant parameter but also aliasing problems.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] MIPS

[Florian Klaempfl]

Am 30.05.2011 10:58, schrieb Marco van de Voort:

 
 So one would really need a cut down RTL for this.

That's why we have the feature switches. Though I admit that it hard to
use for the outer rtl and packages because it would require a lot of
ifdef'ing thus polluting the sources.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.4.4 - Delphi 7

[Florian Klaempfl]

Am 30.05.2011 13:21, schrieb Mattias Gaertner:
 
  
 
 Do you know, how much is compiling and how much is linking? 

Linking time is little:

[10.205] Linking mseidefpc.exe
[10.767] 310695 lines compiled, 10.8 sec , 2277216 bytes code, 1703496
bytes data
[10.768] 148 warning(s) issued

So approx. 0.56 sec
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Macro Processing

[Florian Klaempfl]

Am 16.05.2011 02:30, schrieb Joerg Schuelke:
 Am Sun, 15 May 2011 13:26:03 +0200 (CEST)
 schrieb Daniël Mantione daniel.manti...@freepascal.org:
 
 Feel free to come up with examples and convince us. They need to be 
 examples of code that is much more awkward to write without macro's.
 
 We extend the small enumeration example:
 
 Think of it, as a server program with a lot of callback procedures and
 associated data
 
   procedure cb_proc1();begin ... end;
   procedure cb_proc2();begin ... end;
   procedure cb_proc3();begin ... end;
   procedure cb_proc4();begin ... end;
   procedure cb_proc5();begin ... end;
   procedure cb_proc6();begin ... end;
 
 type
   callenum=(
 proc1,
 proc2,
 proc3,
 proc4,
 proc5,
 proc6
   );
 
   callproc=procedure();
   inforec=record
 id:callenum;name:string[12];address:callproc
   end;
 
 const
   infoarr:array[callenum] of inforec={
 {id:proc1;name:'proc1';address:@cb_proc1},
 {id:proc2;name:'proc2';address:@cb_proc2},
 {id:proc3;name:'proc3';address:@cb_proc3},
 {id:proc4;name:'proc4';address:@cb_proc4},
 {id:proc5;name:'proc5';address:@cb_proc5},
 {id:proc6;name:'proc6';address:@cb_proc6}
   }
 
 What I possibly would do is:
 
 {$Makro entry(n):={id:proc %% %n%;  // concat with parameter
name:'proc' %% % %n%;// concat with str par
address:@cb_proc %% %n%  // concat with parameter
   }
 }
 
 used with the explicit syntax:
 
   infoarr:array[1..6] of inforec={
 {$Expand entry(1)},
 {$Expand entry(2)},
 {$Expand entry(3)},
 {$Expand entry(4)},
 {$Expand entry(5)},
 {$Expand entry(6)},
   }
 
 thats nice enough if you have 57 elements in your callenum. Would you
 say then, use an IDE instead of? Every time I change the inforec, which
 is possibly not that seldom, I only change the macro once. Is this not
 nice? Macros simply can help to keep the things together.

You still need to keep infoarr and callenum in sync so simple macros
are only half of a solution in this case.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Macro Processing

[Florian Klaempfl]

Am 14.05.2011 15:07, schrieb Joerg Schuelke:

Am Sat, 14 May 2011 12:14:52 +0200
schrieb Florian Klämpflflor...@freepascal.org:


Because a lot of code in the compiler is very old (remember, it was
started in 1993 using TP) and writestr for enums is new compare with
this time span. Nobody rewrote the code yet.


And it should not been rewritten this way, because this would force the
use of RTTI information inside the compiler , which is needless.


Since the compiler uses classes, it uses rtti already heavily so I miss 
the point.

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

Re: [fpc-devel] Macro Processing

[Florian Klaempfl]

I could live with something similiar you proposed, maybe with other
preprocessor keywords like $macro and $expand instead so that it's clear
it's something new. But I fear this is not what most people being pro
macro want: they want something like C and think this will solve all the
C header porting problems. But it doesn't because it doesn't fit into
the unit concept (a C like solution). Further, it adds another language
concept for which I see no need.

Writing debugging info isn't, this can be done by a function taking a
array of const. What's wrong with

procedure dp(const x : string;y : array of const);inline;
  begin
dbgstr(x,y);
  end;
?

Constants? Pascal has native constants, C hadn't. Poor man's templates?
Well, we have generics, if they lack something, we should improve them.
Repeated code? Pascal has nested functions, most of the time they are
enough and they can be marked as inlined.

I really thing we should first collect use cases and maybe improve
existing solutions if needed instead of opening another can. If the
faculty example doesn't generate good code, the inline folding should be
improved etc. like the possiblity to use inline functions in constant
expressions if the inline function can be evaluated at compile time etc.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Macro Processing

[Florian Klaempfl]

Am 13.05.2011 13:45, schrieb Joerg Schuelke:
 Am Fri, 13 May 2011 11:47:54 +0200
 schrieb Florian Klaempfl flor...@freepascal.org:
 
 procedure dp(const x : string;y : array of const);inline;
   begin
 dbgstr(x,y);
   end;
 
 Nothing is wrong with that. Except:
 - the code will never vanish from the object file. I like it, to have
   my debugging code all the time present in the sources with no need
   for commenting it out, if I think it is ready done.
   With some small macros with parameters you can do that job, having
   debugging messages, which completely vanish by doing one
   simple {$undefine MYDEBUG}.

Ifdef the dbgstr line and the code should vanish when it's inlined. If
not, this should be fixed.

 - if I try for example to use the %LINE% and %FILE% info inside the
   debugging output, which I think is their means, I can not use a
   procedure without writing the FILE and LINE thing every time I call
   it. With a macro this would be done inside the macro.
   macro dp(x,y)
   dbgstr(whatever,{$I %FILE%},{$I %LINE%},something else)
   The macro expansion than gives the LINE and FILE info without that I
   am forced to write it again and again:
   dp(x,y) in the code gives
   dbgstr(...,{$I %FILE%},{$I %LINE%},...);
   which outputs:
   MSG: test-003.pas[102] : My debugging Message.
   And not only the debugging message vanishes from my programm, the
   debugging code too, if I switch it of.
 
  But thats a special use.

Extending dump_stack is imo a much better approach, it even doesn't
duplicated information already available in debugging info.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Macro Processing

[Florian Klaempfl]

Am 13.05.2011 14:28, schrieb Joerg Schuelke:
 Am Fri, 13 May 2011 14:05:43 +0200
 schrieb Florian Klaempfl flor...@freepascal.org:
 
 Extending dump_stack is imo a much better approach, it even doesn't
 duplicated information already available in debugging info.
 
 Thats a unit? I`m a small man voting for a small solution. If some kind
 of macro support is integrated in the language this will never go away,
 using a unit from outside ... from time to time they all change their
 interface, or even go away completely.

dump_stack is a function of the fpc system unit.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Declare variables inside the code

[Florian Klaempfl]

Am 11.05.2011 14:52, schrieb Jonas Maebe:
 but I'm personally not
 missing anything as far as compiler development is concerned.
 

Me neither. And if I really need output during compilation, I add the
needed code manually like

printnode(self);

to get a node tree at a particular place. Having this in macros
everywhere makes imo no sense because one would gets an incredible
amount of data.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Default IntToStr operator for '+' symbol.

[Florian Klaempfl]

Am 29.04.2011 10:23, schrieb Felipe Monteiro de Carvalho:

The Pascal way to avoid using too much IntToStr is:

begin
   s := Format('%d %d', [X, Y]);
end;

Much shorter, no?


... or writestr(s,x,' ',y);
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] type pointer to record before record.

[Florian Klaempfl]

Am 29.04.2011 15:51, schrieb Flávio Etrusco:

type
  TMyRecord = record
  mPrev : ^TMyRecord; // not allowed.
  end;


Marco, only if you happen to know from the top of your head, would it
be possible and without consequences to allow this kind of
construction? (i.e. a pointer reference to itself)


No. Because TMyRecord could be already defined in another unit.


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

Re: [fpc-devel] {$I %LINE%} and friends

[Florian Klaempfl]

Am 29.04.2011 10:59, schrieb Hans-Peter Diettrich:

michael.vancann...@wisa.be schrieb:


But what is the cleaner way? To defer the expansion of {$I %xxx%}
inside macros, or to define c-like macros __LINE__ and __FILE__, maybe
with nicer names?


Defer expansion. The use of {$I } is mandatory, since __LINE__ and
friends are valid
pascal identifiers and this should not be changed by a macro.


What about %%LINE%%, or {%LINE%} or {{LINE}}?

I wonder why FPC broke Delphi compatibility by adding {$MODE}, instead
of choosing its own prefix for added compiler directives and macros.


I think an explicit {$ifdef FPC} is much more readable and everybody 
knows what's meant.

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

Re: [fpc-devel] fpc modifiers

[Florian Klaempfl]

Am 29.04.2011 00:02, schrieb Joerg Schuelke:

Am Thu, 28 Apr 2011 23:39:35 +0200
schrieb Hans-Peter Diettrichdrdiettri...@aol.com:


The bug resides in the dirty Delphi OPL definition.


Is it a bug or unspecified behavior? I think it is implemented in the
hope it works good enough.

If you consume amodifier  token asmodifier  oridentifier  in
respect of the right context of one token, you get rid of this strange
behavior and you will get a real superset of the former language.

So, why not doing it?


The FPC scanner is simply not designed for a look ahead  1. Especially 
macro and include file expansion as well as generics require probably a 
major rewrite of the scanner.

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