Am 20.08.2012 10:26, schrieb Graeme Geldenhuys:
So the BIG question remains: When will the FPC team sit down and hash
out the details of implementing Unicode support? Please note, I'm not
saying implement it, just saying... agree on how it should be
implemented.
Fine with me: let's kick
Am 20.08.2012 16:25, schrieb Graeme Geldenhuys:
On 20 August 2012 15:11, Florian Klämpfl flor...@freepascal.org wrote:
And who implements it? The public votes as well?
Why are you complaining? You have your hobby projects (FPC etc.), and
I have mine (fpGUI, tiOPF, OnGuard, MPP etc). I have
Am 20.08.2012 18:05, schrieb Graeme Geldenhuys:
Hi,
On 20 August 2012 15:43, Florian Klämpfl flor...@freepascal.org wrote:
Besides the resourcestrings I'am not aware of any unicodestring issues
in the *compiler*. If there are, please report them to the issue tracker.
I have heard
Am 20.08.2012 20:27, schrieb Graeme Geldenhuys:
* UnicodeString is always UTF-16 (so everything but Windows takes a
conversion penalty)!
A decision has been made and you are not happy with it. Fine. But before
you called the fpc team being in a deadlock?
Many things by the FPC team get
Am 22.08.2012 21:41, schrieb Graeme Geldenhuys:
Also, how do I find out in SubVersion at what revision the 2.6.1 branch
started?
2.6.1 did not start yet? It will be build from fixes_2_6. According to
the TortoiseSVN revision graph, fixes_2_6 has been branched from r18073.
G.
On 22
Am 13.09.2012 02:26, schrieb Michel Catudal:
I would like to port fpc to the AVR32 uc3c devices. I need more details
on the functions that need to be implemented.
Take a look at one of the other architectures like arm, fpc/compiler/arm
contains the arm specific compiler files.
Am 13.09.2012 21:38, schrieb Jeppe Græsdal Johansen:
I have made a preliminary backend and RTL stub in
branches/laksen/avr32new/
Some of the large problems is that the load instructions allow
non-aligned loads in the ld.w forms.
This proves to introduce many
strange problems,
Why is this
Am 26.09.2012 13:27, schrieb Graeme Geldenhuys:
On 2012-09-26 11:40, Marco van de Voort wrote:
It means the interface will always be constref, and thus no ifdefing
in FPC
(if you don't support 2.6.0) will be necessary.
For fpGUI, I only support the latest stable release of FPC, so that
Am 04.10.2012 19:42, schrieb Den Jean:
On Thursday 04 October 2012 16:23:34 den.j...@telenet.be wrote:
After the crosszipinstall, compiler/ppcarm (not installed, but in the
source directory) is the native ARM compiler.
I looked there with `file pp* `
How could I have missed that ?
Well I
Am 18.10.2012 13:24, schrieb Pierre Free Pascal:
Are you resurrecting m68k port?
Just a guess, of course...
Too late, but it would have been my guess as well. The tale misses only
the very sad part about the two children who never made it to life ;(
Am 26.10.2012 12:29, schrieb Mark Morgan Lloyd:
(.text+0x68): undefined reference to `_fini'
gdbver.pp(95,33) Error: Error while linking
gdbver.pp(95,33) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
make[4]: *** [gdbver] Error 1
make[4]: Leaving directory
Am 26.10.2012 22:51, schrieb Thomas Schatzl:
Hi,
On Fri, 2012-10-26 at 22:35 +0200, Tomas Hajny wrote:
On 26 Oct 12, at 19:46, Mark Morgan Lloyd wrote:
I'm trying Thomas's suggestion first, pending Florian's comments.
.
.
I'd say that Thomas' suggestion points to the same direction as
Am 26.10.2012 23:28, schrieb Mark Morgan Lloyd:
Thomas Schatzl wrote:
Florian's suggestion is correct: debian is changing some paths beginning
with debian wheezy to improve multi-arch support.
While on sparc this may not matter and maybe not needed, it's probably
done on all platforms to
Am 02.12.2012 19:50, schrieb Alexander Klenin:
On Sun, Dec 2, 2012 at 9:47 PM, Tomas Hajny xhaj...@hajny.biz wrote:
On 2 Dec 12, at 16:45, Alexander Klenin wrote:
I am not sure which options do you mean,
I refer to the dll mentioned here: http://wiki.freepascal.org/gmp
I meant multiple 2.6.2
Am 06.12.2012 11:03, schrieb Alexander Klenin:
On Thu, Dec 6, 2012 at 8:29 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
If a major problem is really the lack of standard support for
arbitrary-precision arithmetic, does that not mean that C and C++ are no
longer serious options either?
Am 17.12.2012 10:36, schrieb Graeme Geldenhuys:
Hi,
Any FPC developer willing to comment on the status of some of these
issues (that have been years overdue)?
It narrows basically down to the fact that fpc lacks developers and
contributors, or do I miss something?
Original
Am 18.12.2012 19:17, schrieb Vincent Snijders:
2012/12/18 Florian Klämpfl flor...@freepascal.org:
Am 17.12.2012 10:36, schrieb Graeme Geldenhuys:
Hi,
Any FPC developer willing to comment on the status of some of these
issues (that have been years overdue)?
It narrows basically down
Am 21.12.2012 09:23, schrieb Martin Schreiber:
On Tuesday 18 December 2012 19:07:47 Florian Klämpfl wrote:
Am 17.12.2012 10:36, schrieb Graeme Geldenhuys:
Hi,
Any FPC developer willing to comment on the status of some of these
issues (that have been years overdue)?
It narrows basically
Am 21.12.2012 12:58, schrieb Graeme Geldenhuys:
On 21/12/12 10:15, Michael Van Canneyt wrote:
It would be good to keep those facts in mind before ranting.
I was simply bringing some of those questions (which I had too) to
light. Unicode has been under development for many years, and has
Am 22.12.2012 14:01, schrieb Graeme Geldenhuys:
On 21/12/12 17:16, Florian Klämpfl wrote:
The mission goal of FPC is: develop an open source pascal compiler
written in pascal in a community effort.
You forgot the last bit and be Delphi compatible!
IMO this is actually a consequence
Am 22.12.2012 11:23, schrieb Martin Schreiber:
I propose to extend and render more precisely the mission goals of FPC and to
concentrate the power on the defined goals.
And you think people will work on this defined goals instead of maybe
completely other projects? Or just fork FPC?
In
Am 23.12.2012 01:50, schrieb Graeme Geldenhuys:
On 22/12/12 16:43, Marco van de Voort wrote:
I think you have a wrong idea on what the core list contains.
LOL. And how is anybody supposed to know what goes on - it is a PRIVATE
mailing list.
I don't think direction on unicode (or even
Am 26.12.2012 06:07, schrieb Martin Schreiber:
Hi,
Does any body work on a LLVM backend for Free Pascal?
Thoughts?
The counterpart of what you want: tries to generate great code at any
cost while being maintainable and having a portable code generator.
Am 26.12.2012 05:42, schrieb Martin Schreiber:
On Tuesday 25 December 2012 18:01:50 Florian Klaempfl 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
Am 30.12.2012 17:34, schrieb Michael Ring:
UniqueString seems to be an Ansistring function and on fpc-pacal I found
a post about a similar problem (Thread name is 'fpc 2.7.1 for
arm-embedded'), the solution there was to add:
Thanks for the hint, I've fixed it in trunk.
Am 19.01.2013 12:18, schrieb Michael Ring:
Today I found some time to research since when excactly arm-embedded
does not compile anymore, I found that since revision 23325 compile does
not work anymore, can anybody help, it seems that the problem itself is
hidden somewhere else in code...
Am 24.01.2013 20:36, schrieb Alexander Klenin:
That's debatable.
As long as there is only some few line idea, there cannot debated much.
Just an example: what happens with i if I start to delete from s during
the for loop?
___
fpc-devel maillist -
Am 24.01.2013 21:35, schrieb Alexander Klenin:
On Fri, Jan 25, 2013 at 7:30 AM, Florian Klämpfl flor...@freepascal.org
wrote:
Am 24.01.2013 20:36, schrieb Alexander Klenin:
That's debatable.
As long as there is only some few line idea, there cannot debated much.
It is more: an idea
Am 24.01.2013 22:26, schrieb Alexander Klenin:
On Fri, Jan 25, 2013 at 7:56 AM, Florian Klämpfl flor...@freepascal.org
wrote:
Just an example: what happens with i if I start to delete from s during
the for loop?
Exactly the same thing as in the current for-in loop: either a range check
Am 24.01.2013 21:41, schrieb Alexander Klenin:
On Fri, Jan 25, 2013 at 7:34 AM, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Florian Kl?mpfl said:
As long as there is only some few line idea, there cannot debated much.
http://www.freepascal.org/faq.var#extensionselect
Am 25.01.2013 17:18, schrieb Alexander Klenin:
On Fri, Jan 25, 2013 at 7:07 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
WITH EACH ADDITIONAL FEATURE WE ARE BUTCHERING PASCAL MORE AND MORE.
Hm... Do not you think this is a bit of an overstatement?
There are plenty to choose from.
Am 25.01.2013 18:17, schrieb Alexander Klenin:
On Sat, Jan 26, 2013 at 3:30 AM, Florian Klämpfl flor...@freepascal.org
wrote:
for-in-index extension was actually planned by me as a prerequisite
for fcl-stl work.
Using indicies is against all principles of iterators.
I am not sure what
Am 25.01.2013 21:18, schrieb Alexander Klenin:
On Sat, Jan 26, 2013 at 6:59 AM, Sven Barth pascaldra...@googlemail.com
wrote:
What is concrete code? The code I provided only missed loop bodies.
I can provide that too, but I do not think it will add anything to the
discussion.
I believe he
Am 25.01.2013 22:44, schrieb Alexander Klenin:
On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl flor...@freepascal.org
wrote:
Where? Concrete code of a serious language! Not some oh, yes, this
language has it and that as well
On Sat, Jan 26, 2013 at 7:34 AM, Florian Klämpfl flor
Am 08.02.2013 16:02, schrieb Jonas Maebe:
On 07 Feb 2013, at 16:52, Ewald wrote:
Altough I still
don't see how you can make these calls atomic then (without the
barrier)?
On x86, it is impossible to perform an atomic access without a (partial)
memory barrier that affects all memory
Am 09.02.2013 03:13, schrieb Vittorio Giovara:
To do that we are using a tool
named 'emscripten' which takes LLVM bytecode and generates Javascript,
without affecting performance too much. Yes, we had to write a horribly
hacked converter that took the small subset of Pascal used by Hedgewars
Am 10.02.2013 20:12, schrieb Vittorio Giovara:
Well the existence of external tools is what has allowed technology
to foster and advance,
In a perfect world, with unlimited cpu resources, yes.
eg have some common grounds and entry
points... Your (limited) example is not exactly perfect,
Am 14.02.2013 23:44, schrieb Michael Ring:
I have seen a lot of work on mpis platform in svn over the last weeks.
Are there plans to create a mips-embedded target or is this strictly
mips-linux?
It shouldn't be too hard, hardest task is probably to create appropriate
controller specific units.
Am 21.02.2013 19:43, schrieb silvioprog:
Hello,
I generates some PPUs in a version of FPC. I try to use it in other
version of FPC, but it not compiles.
So, can I disable the PPU version checking to I use my PPUs in any
versions of FPC?
It won't help, we don't change the ppu version for
Am 25.02.2013 15:39, schrieb John Lee:
I'm guessing that you'd need to be pretty au fait with fpc internals
the code to do this eg because there's no spec, and no tools to help? J
ppudump.
If I'd lost the source of a unit I need (if the unit isn't too big), I'd
just ppudump the .ppu and write
Am 01.03.2013 18:33, schrieb Martin Schreiber:
Hi,
In order to have a good benchmark for FPC
Expect the next release to be even slower.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 01.03.2013 22:40, schrieb Martin Schreiber:
On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote:
Am 01.03.2013 18:33, schrieb Martin Schreiber:
Hi,
In order to have a good benchmark for FPC
Expect the next release to be even slower.
Will it produce better code instead?
What means
Am 02.03.2013 11:16, schrieb Martin Schreiber:
On Saturday 02 March 2013 10:12:51 Florian Klämpfl wrote:
Am 01.03.2013 22:40, schrieb Martin Schreiber:
On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote:
Am 01.03.2013 18:33, schrieb Martin Schreiber:
Hi,
In order to have a good
Am 02.03.2013 11:21, schrieb Martin Schreiber:
On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote:
I did a quick test on win32, it seems to be a little bit smaller than
2.6.2:
02.03.2013 10:09 5.774.848 mseide.exe
Compiled with which FPC version?
trunk.
??? MSEgui
Am 02.03.2013 11:28, schrieb Michael Van Canneyt:
On Sat, 2 Mar 2013, Martin Schreiber wrote:
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
Anyway, what seems obvious from your numbers is that it is the linking
stage that needs speedup. This does not really come as a
Am 02.03.2013 23:17, schrieb Michael Ring:
I am not sure if I have hit work in progress code here
my arm-embedded app crashes during initialization, the reason is that
now exceptions are part of the rtl but there is no properly initialized
heapmanager:
Procedure InitExceptions;
{
Am 03.03.2013 10:46, schrieb Martin Schreiber:
On Sunday 03 March 2013 10:04:54 Daniël Mantione wrote:
Op Sun, 3 Mar 2013, schreef Martin Schreiber:
BTW, a significant percentage of the time is waiting for FPC compiling
because FPC normally crashes without -B.
I think you should focus your
Am 03.03.2013 20:40, schrieb Martin Schreiber:
On Sunday 03 March 2013 20:08:43 Michael Van Canneyt wrote:
On Sun, 3 Mar 2013, 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,
Source
Am 03.03.2013 19:51, schrieb Michael Ring:
I just saw that armv6m has showed up in the sourcecode of trunk version.
You guys are great, thank you very much
I just checked, I do have a LPCXpresso LPC812 Board here, now I can put
it to good use!
Note that it is still work in progress.
Am 03.03.2013 21:27, schrieb Michael Ring:
I have created a new patch, this time it uses the values of the two
commandline parameters -Ch and -Cs to set the size of Stack and Heap. I
am not sure if those params were for this use case but in my opinion it
makes sense.
Florian, could I ask
Am 03.03.2013 22:09, schrieb Michael Ring:
That would of course be even better, the compiler could calculate if
vars+stack+heap fit in the given memory configuration and issue at
minimum a warning or even better a compile error.
But this is definitely something that is out of my league,
Am 03.03.2013 20:09, schrieb Michael Ring:
$
$00142333
$00144647
$00144B00
$001AF725
$001970A5
$0003295E
make[3]: *** [system.ppu] Error 217
make[2]: *** [embedded_all] Error 2
make[1]: *** [rtl_all] Error 2
make: *** [base.build-stamp.arm-embedded] Error 2
Am 04.03.2013 01:00, schrieb Graeme Geldenhuys:
4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That
is just too a huge performance difference to justify. Yes, we all know
the argument about more platforms, maintainable code etc, but that
couldn't possible be the only
Am 04.03.2013 15:33, schrieb Mattias Gaertner:
But I was talking about operator overloads. AFAIK there far less
operator overloads. And if a unit uses operator
overloads, then usually only a few, but many times.
I guess many units do not use overloaded operators at all.
Is it possible to
Am 04.03.2013 15:40, schrieb Graeme Geldenhuys:
On 2013-03-04 12:44, Sven Barth wrote:
that really contain class helpers). Maybe we can add an additional
has_operators flag and ignore all units when searching for overloads
that don't have this flag set (the flag would propagate from the
Am 04.03.2013 20:35, schrieb Ivanko B:
I am not so sure about this.
===
Hmm - 20 (!) times (!!) difference. Usually it means design flaws thus
broad ways for improvements reworks.
Awaiting your patches.
___
fpc-devel
Am 04.03.2013 13:22, schrieb Martin Schreiber:
On Monday 04 March 2013 12:05:37 Florian Klämpfl wrote:
Am 04.03.2013 01:00, schrieb Graeme Geldenhuys:
4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That
is just too a huge performance difference to justify. Yes, we all know
Michael Ring m...@michael-ring.org schrieb:
Florian, did you find some spare time to work on this?
Not yet but still on my todo list.
Michael
Am 03.03.13 22:59, schrieb Florian Klämpfl:
Am 03.03.2013 22:09, schrieb Michael Ring:
That would of course be even better, the compiler could
Am 03.03.2013 11:04, schrieb Michael Ring:
In r23853 I committed a patch which creates automatically a heap on the
embedded targets if heapmgr is used. Further, sysutils depends now on
heapmgr.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 09.04.2013 08:57, schrieb Mattias Gaertner:
Hi,
According to this bug report cairo.ppu is not installed on win64 fpc
2.6.3:
http://bugs.freepascal.org/view.php?id=24215#c66862
I don't have Windows to test. Was there some revision that didn't
install cairo.ppu?
As far as I can see
Am 05.05.2013 09:56, schrieb Michael Van Canneyt:
On Sun, 5 May 2013, Bruce Tulloch wrote:
FWIW, I ran into this problem trying to use the RTL from the FPC 2.6.2
release branch when built with -Cr. Attached is a patch that
works around the problematic code (in sockets.inc).
It does not
Am 05.05.2013 11:14, schrieb Marco van de Voort:
In our previous episode, Michael Van Canneyt said:
fcl-passrc, chm and fpdoc are afaik fairly clean. When debugging fpdoc I
always build those packages with -CRriot and fixed all issues.
I've also done whole make all builds with that, and fixed
Am 13.05.2013 20:07, schrieb Michael Ring:
OK, I got kind of bored last weekend and started to implement
mips-embedded target. The crosscompiler builds fine and already shows
the list of (not yet implemented) pic32mx controllers, I am now
searching through the code for places that I need to
Am 09.06.2013 18:22, schrieb Max Nazhalov:
Could this patch be reviewed and accepted/adapted/rejected?
Thanks, I applied it and fixed a few more things.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 21.06.2013 09:32, schrieb Michael Schnell:
A friend of mine just bought two BeagleBone Black boards for € 38.-
(+VAT) each. With the extremely versatile and well supported TI 1 GHz
chip (that is taken from TI's AM... series of devices for embedded
use instead of for cellphone use), with
Am 21.06.2013 16:29, schrieb Sergei Gorelkin:
and the fact that SetCodePage goes through implicit
try..finally block even if it does not need to convert the string.
I've fixed this one on r24942
___
fpc-devel maillist -
Am 21.06.2013 12:23, schrieb Graeme Geldenhuys:
On 20/06/13 22:41, Michael Ring wrote:
Doing crosscompiles and remotedebugging will add a level of complexity
that will not justify the better performance of lazarus when using it on
the 'real' linux box.
It doesn't need to be!
Having
Am 24.06.2013 01:39, schrieb Graeme Geldenhuys:
On 23/06/13 20:56, Florian Klämpfl wrote:
So they support now native development on MacOS X as well?
No, all development is still ONLY done under Windows. You cross compile
to OS X and iOS. You also remote debug to OS X and iOS.
This is my
Am 05.07.2013 22:23, schrieb Michael Ring:
I have now found out why debug symbols get discarded by
pic32mx-elf32-gdb. The problem is a bug in the generation of
dwarf-debuginfo. My guess is that the problem should also exist in linux
target.
For mips unaligned data in dward debug info needs
Am 02.08.2013 17:46, schrieb Sven Barth:
- using an array declared as a ranged array (array[0..2] of LongInt) the
for-loop is inlined and optimized a bit (especially depending on the
optimization settings), but the compiler does not yet fold the loop...
At least I fixed loop unrolling for
Sven Barth pascaldra...@googlemail.com schrieb:
On 03.08.2013 09:36, Sven Barth wrote:
Am 02.08.2013 23:26 schrieb Florian Klämpfl flor...@freepascal.org
mailto:flor...@freepascal.org:
Am 02.08.2013 17:46, schrieb Sven Barth:
- using an array declared as a ranged array (array[0..2
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.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
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
Am 04.08.2013 14:20, schrieb Sven Barth:
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
Am 09.08.2013 22:54, schrieb Joost van der Sluis:
On 08/09/2013 06:46 PM, Joost van der Sluis wrote:
Hi all,
I've cross-compiled a ppcarm, and now I try to use that compiler on qemu
to build fpc (2.6.2).
But the compiler crashes on compiling the system-unit. But with trunk
(2.7.1) this all
Am 19.08.2013 10:37, schrieb Sven Barth:
Adding a new platform to FPC is not cheesecake and you should know how
the compiler's backend work. Just looking at the output of a target
won't help you!
A good start is aarch64: I tried to work in it as structured as possible
to make it some draft for
mar...@stack.nl schrieb:
Is it possible to crosscompile a compiler (just the compiler) for a
architecture X, the compiler itself hosted on arch,os= Y while doing
this on
arch,os Z.
Mostly thinking about building go32v2 hosted tools that target 8086 on
Windows. (well strictly arch Y = arch Z
Bernd Oppolzer bernd.oppol...@t-online.de schrieb:
My goal was, for example, to have a cross compiler running on
Windows, that produces Assembler output for MIPS for example, and
for a second target S370, which is at the beginning simply a copy of
MIPS,
producing the identical output, but then I
Am 01.09.2013 16:55, schrieb Bernd Oppolzer:
No need to answer to that ... I understood in the meantime that FPC does
NOT rely on
PUSH and POP instructions. Instead the linear assembler representation
is already fully
CPU specific.
(which makes porting a bigger effort)
Proof?
Am 01.09.2013 19:53, schrieb Bernd Oppolzer:
Am 01.09.2013 18:01, schrieb Florian Klämpfl:
Am 01.09.2013 16:55, schrieb Bernd Oppolzer:
No need to answer to that ... I understood in the meantime that FPC does
NOT rely on
PUSH and POP instructions. Instead the linear assembler representation
Am 31.08.2013 10:02, schrieb Marco van de Voort:
Mostly thinking about building go32v2 hosted tools that target 8086 on
Windows. (well strictly arch Y = arch Z then)
For the record, it can be achieved with (empty line=line break)
cd fpc
make clean all crossinstall OS_TARGET=msdos
Am 09.12.2013 21:04, schrieb Sandro Cumerlato:
Operating System: Windows 7
Affected FPC svn revision: 26202
IDE is not properly installed into bin directory (bin\i386-win32 in my
case), listed below files are resetted in place instead:
ide\cvsco.tdf
ide\cvsdiff.tdf
ide\cvsup.tdf
Am 02.01.2014 15:18, schrieb Michael Ring:
I tried rev. 26354, the problem is not yet fixed, perhaps Jonas is right
and there's more to do... I both tried armv7m and armv6m, both break:
ring/devel/fpc/rtl/units/arm-embedded -darm -dRELEASE -O- -gw2
-Fi../objpas/sysutils sysutils.pp
Hi,
I plan to migrate the mailing lists to a another server within the next
hours/days. This might cause some down time. I hope no data gets lost :)
Florian
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Ok, it looks like that things are working again. Please tell me if
something does not work anymore.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Am 07.01.2014 14:34, schrieb Jonas Maebe:
On 07 Jan 2014, at 14:13, Mattias Gaertner wrote:
What is this crap:
http://wiki.freepascal.org/FPC_Unicode_support#FPC_Unicode_support
?
It's under the header Old/obsolete sections and as mentioned above,
that's incomplete or wishful thinking.
Am 19.01.2014 18:01, schrieb Martin:
As I just looked through some of the code, I found the following.
compiler\i386\popt386.pas
case taicpu(p).opcode Of
// line 1122
A_MOV:
has several if statements, some concatenated with else, but some
Am 20.01.2014 01:18, schrieb Martin:
Just been looking at the peehole opt (i386). Other than the 2 items
already mailed, I found that:
1) Gode as follows is sometimes generated (at various opt levels)
.Ll2:
# [36] i := 1;
movl$1,%eax
.Ll3:
# [38] i := i + 1;
movl
Am 22.01.2014 19:31, schrieb Den:
haha, well Sven, if some of my patches were to get accepted *cough*
What patches? Are they available somewhere?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 22.01.2014 00:06, schrieb Martin Frb:
On 21/01/2014 21:20, Florian Klämpfl wrote:
Am 19.01.2014 18:01, schrieb Martin:
In each of them GetNextInstruction(p, hp1) could be executed.
If I counted correct, it can be called up to 6 times for each a_mov.
On the other hand:
- no code
Am 22.01.2014 00:27, schrieb Martin Frb:
On 21/01/2014 21:28, Florian Klämpfl wrote:
Am 20.01.2014 01:18, schrieb Martin:
It used
(taicpu(p).oper[1]^.regtaicpu(hp1).oper[0]^^.ref^.base) and
(taicpu(p).oper[1]^.regtaicpu(hp1).oper[0]^^.ref^.index) then
but should only compare the supregister
Am 22.01.2014 02:17, schrieb Nikolay Nikolov:
On 01/21/2014 11:20 PM, Florian Klämpfl wrote:
It is still on my todo list though to update the peephole optimizer and
make a common one for i386 and x86_64 ...
And don't forget i8086 :)
I think there is little to share that's why I didn't
Am 22.01.2014 04:06, schrieb Martin Frb:
On 21/01/2014 21:28, Florian Klämpfl wrote:
Can you post some example code? It might be worth to think about
improving this already in at the node level.
While getting examples, another issue:
with -O2 , -O3 or -O4
Note the
movl%eax
Am 23.01.2014 00:26, schrieb Den:
Yep!
Ah, I thought you made cpp related ones.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Am 23.01.2014 02:38, schrieb Nikolay Nikolov:
On 01/22/2014 11:25 PM, Florian Klämpfl wrote:
Am 22.01.2014 02:17, schrieb Nikolay Nikolov:
On 01/21/2014 11:20 PM, Florian Klämpfl wrote:
It is still on my todo list though to update the peephole optimizer and
make a common one for i386
Am 22.01.2014 23:22, schrieb Martin Frb:
On 22/01/2014 21:29, Florian Klämpfl wrote:
Am 22.01.2014 04:06, schrieb Martin Frb:
On 21/01/2014 21:28, Florian Klämpfl wrote:
Can you post some example code? It might be worth to think about
improving this already in at the node level.
While
Am 23.01.2014 20:52, schrieb Martin Frb:
On 23/01/2014 19:35, Florian Klämpfl wrote:
Am 22.01.2014 23:22, schrieb Martin Frb:
One of the optimizations you said it where better avoided to be created
in first. I agree.
Only, even if that is archived at some time, who guarantees
Am 25.01.2014 23:00, schrieb Sven Barth:
On 25.01.2014 17:09, Florian Klaempfl wrote:
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
Am 25.01.2014 23:33, schrieb Nico Erfurth:
On 25.01.14 17:09, Florian Klaempfl wrote:
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
Am 26.01.2014 18:48, schrieb Maciej Izak:
Hi,
As always I am working on new Generics.* and I found very annoying bug.
Essence: http://bugs.freepascal.org/file_download.php?file_id=19514type=bug
Examples: http://bugs.freepascal.org/file_download.php?file_id=19513type=bug
Bugtracker:
201 - 300 of 802 matches
Mail list logo
