Tue, 10 Jul 2018 03:36:01 +1000 Thorsten Engler wrote:
>> -Original Message-
>> From: fpc-devel On Behalf Of
>> Max Nazhalov via fpc-devel
>> Sent: Tuesday, 10 July 2018 02:25
>>
>> Just one question: doesn't all this new stuff introduce anoth
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 so
Dimitrios Chr. Ioannidis wrote Thu Jun 15 14:11:11 CEST 2017
> is the SEH for win32 enabled by default on 3.0.2 or not
AFAIR, no.
The last answer from Sergei on this topic, if I didn't miss something, was
http://bugs.freepascal.org/view.php?id=28756#c86199
See also discussion in http://bug.fre
Wed, 29 Jun 2016 03:32:35 +0200, Sven Barth:
>
> And the tagging and building of 3.0.2 should start soon (TM).
>
Is there any chance that bug#0030240 will be fixed/merged?
---
WBR, Max.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://
These are fix compiling softfpu with FPC_SOFTFLOAT_FLOATX80 and
FPC_SOFTFLOAT_FLOAT128 enabled.
--
WBR, Max
Index: rtl/inc/softfpu.pp
===
--- rtl/inc/softfpu.pp (revision 33913)
+++ rtl/inc/softfpu.pp (working copy)
@@ -6227,7 +62
Wednesday, October 21, 2015, 4:00:01 PM, Joost van der Sluis
wrote:
fdrlfo> Subject: [fpc-devel] FPC 3.0.0-rc2 release
..skip..
fdrlfo> * Features
..skip..
fdrlfo> - can compile code into assembler source code for these assemblers:
..skip..
fdrlfo>- Microsoft Assembler/Turbo Assembler (Masm
>> I can't think of a use case either. And just because another language
>> provides such a solution, does not imply that FPC should. As to achieving
>> the functionality in FPC:
>>
>> if cond then
>>while cond do
>> foo
>> else
>>bar;
>
>That's what I've thought about from the beginni
> I can't think of a use case either. And just because another language
> provides such a solution, does not imply that FPC should. As to achieving
> the functionality in FPC:
>
> if cond then
>while cond do
> foo
> else
>bar;
That's what I've thought about from the beginning of this
On 12.10.2015 17:17 schrieb "Dmitry Boyarintsev"
wrote:
> About while-then. While the syntax is unlikely to break anything, it's
> inconsistent with if-statement.
> where, if-then is executed when condition is true.
> For while-then is executed then condition is false.
> Thus, while-else or whil
Wednesday, April 9, 2014, Nikolay Nikolov wrote:
> I think only pointer arithmetic will need helpers (i.e. adding a pointer
> with an integer and pointer difference). As for the other routines in the
> RTL like (h)FillChar and (h)Move, they will have to be made to work with
> unnormalized huge poin
Wednesday, April 9, 2014, Nikolay Nikolov wrote:
> Hmm, then maybe we should support both and add a
> {$HUGEPOINTERNORMALIZATION} directive?
Well, I don't know for sure..
But I think introducing huge pointers implies introduction of some minimal
support routines, like [h]move(hugefrom,hugeto,huge
Monday, April 7, 2014, Nikolay Nikolov wrote:
NN> Back in the old days, I never used huge pointers, because I wrote in
NN> Turbo Pascal, which didn't have them, so I don't have an opinion which
NN> way is better.
I've rechecked -- and yes, You are right, BP7 RTL itself uses SelectorInc only
in DP
Sunday, April 6, 2014, Nikolay Nikolov wrote:
NN> Back in the old days, I never used huge pointers, because I wrote in Turbo
Pascal,
NN> which didn't have them, so I don't have an opinion which way is better.
NN> So, which way should FPC for i8086 follow?
BP7 does not normalize pointers, since i
> Date: Tue, 31 Dec 2013 19:42:44 +0200
> From: Nikolay Nikolov
>
> I got my PSU fixed and now I have results from my 10 MHz PS/2 Model 30 286:
> 32pas: ticks = 814
> 32asm: ticks = 30
> ~27x faster
>
> 64pas: ticks = 1130
> 64asm: ticks = 30
> ~38x faster
Thanks for follow-up, Nikolay!
I'm stil
On Sat, 28 Dec 2013 01:15:41 +0200, Nikolay Nikolov wrote:
> It looks correct, but I still haven't reviewed the overflow checking part of
> the 64-bit multiplication routine. I'll commit the patch when I finish that.
Thanks for the effort, Nikolay!
To help with the understanding of data/decision
Hello, Everybody!
Can anyone having the real i8086 hardware check attached MUL-helpers?
I've tested them on a modern Intel CPU -- "mul_dword" is about 4.5..5
times faster comparing to the generic FPC implementation, and
"mul_qword" is about 18..20, but these numbers surely should be quite
differen
Regarding mysterious failure of "test/units/system/tstr1.pp" on powerpc64..
(expected: " 5.45660677913695E-108", got: " 5.87119109913695E-108")
I have no such machine around, so could anyone who have access to it try the
attached program?
It should print
1: 5456606779
2: 136949926
3: 5
4: 456606
Tuesday, November 5, 2013, 5:28:19 AM, Jonas Maebe wrote:
JM> I don't know whether it works, only that it apparently compiles.
JM> Charlie, did you check the testsuite results?
It works, as can be seen there:
http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1&run1id=162790&run2id=
Hello Jonas,
Sunday, November 3, 2013, 9:34:44 PM, you wrote:
JM> On 03/11/13 09:52, Max Nazhalov wrote:
>> On 01/11/13 09:22, Michael Ring wrote:
>>> >I tried today's trunk, unfortunately it does not build:
>>> >
>>> >
>>> >/U
On 01/11/13 09:22, Michael Ring wrote:
> I tried today's trunk, unfortunately it does not build:
>
>
> /Users/ring/devel/fpc/compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur
> -Tembedded -Parm -XParm-none-eabi- -Xr -Ur -Xs -O2 -n -Fi../inc
> -Fi../arm -FE. -FU/Users/ring/devel/fpc/rtl/units/arm-embedded
Attached final patch that fixes compilation for JVM target (mantis #25267).
It combines previous two + fix of the runtime error during application startup.
Now an example
http://svn.freepascal.org/svn/fpc/branches/jvmbackend/tests/test/jvm/trange1.pp
compiles and runs under Win7.
Also STR and VA
Attached an additional patch that tries to fix compilation for JVM target
(mantis #25267). It fixes internal error 2011032601.
Cross-compiling the compiler is now works at least in Win7.
---
WBR, Max.
jvmfix_take1_add1.diff
Description: Binary data
__
Attached a patch that tries to fix compilation for JVM target (mantis #25267).
---
WBR, Max.
jvmfix_take1.diff
Description: Binary data
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
To Jonas Maebe (regarding tstrreal2.pp):
7{$else FPC_HAS_TYPE_EXTENDED}
8 '0.10001',
9{$endif FPC_HAS_TYPE_EXTENDED}
This one might be from the GRISU1_F2A_AGRESSIVE_ROUNDUP define. It
fixes some tests on some platforms, but potential
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 anoth
Since I can not comment on 'resolved' issue, just a side note here:
think valid Pascal program could never ever start with #-token..
---
WBR, Max.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc
And furthermore, current intrinsic implementation of BSR/BSF also does not
check Z-flag after execution. That is bad, I think.. :(
I have no AMD/etc CPU to stress-test, only Intel. So I can not guarantee
the assumption of "unchanged destination, if source=0".
---
WBR,
Max.
BTW, I found only one caveat in that asm-implementation: according to Intel docs
target register of BSR is "undefined" if source=0, so Z-flag should always
be checked after BSF/BSR.
In case of "int_str" ECX randomisation after BSR surely will lead to crash,
but in practice I can not reproduce suc
On Sun Sep 2 15:51:05 CEST 2012 Amir wrote:
> I could not follow what the code does, as it is in assembly, but it
> looks like it has the same idea as mine.
>
>In general, how can one propose some changes in a library? Should the
> suggestion goes through this mailing list?
Don't bother
On Sun, 02 Sep 2012, Amir wrote:
> Hi,
>In one of my project, I have to call IntToStr more than 10M times.
> I noticed that IntToStr calls Str function. I implemented my own version
> of IntToStr which is almost twice faster than the current implementation
> of IntToStr.
> I wonder if it is p
On Tue Jul 3 17:46:58 CEST 2012 Marcel M?rtens wrote:
> Hello,
> i think i've found a bug in the procedure TryStrtoFloat.
> To get this bug, create a new project and run this lines (i'm using a
> button to run the line, but it shouldn't matter)
> --
Trying to run test suit out of r21343 results in
C:\prog\FPC_UTIL\make.exe full TEST_FPC=C:\prog\FPC\bin\i386-win32\fpc.exe
...
Free Pascal Compiler version 2.7.1 [2012/05/20] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling dotest.pp
Compiling re
Trying to run test suit out of r21343 results in
C:\prog\FPC_UTIL\make.exe full TEST_FPC=C:\prog\FPC\bin\i386-win32\fpc.exe
...
Free Pascal Compiler version 2.7.1 [2012/05/20] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling dotest.pp
Compiling red
Sorry, 1st post was eaten somewhere..
Float to string conversion is very slow when dealing with high-order numbers.
Conversion time is almost linearly increases with exponent.
Test case [i386/Win32,"ValReal=extended"]: converting 100 numbers into
default exponential format by "writeln(them
Float to string conversion is very slow when dealing with high-order numbers.
Conversion time is almost linearly increases with exponent.
Test case [i386/Win32,"ValReal=extended"]: converting 100 numbers into
default exponential format by "writeln(them)" to dev/nul.
"1.2345678901234568E+3999
35 matches
Mail list logo
