> On May 22, 2017, at 9:24 PM, Marco van de Voort wrote:
>
> I saw Florian worked hard last weekend, and the new value is 23.0 - 23.6
> (was 19.1 - 19.5) for x86_64. Sometimes floating point division by zero.
>
> and for x86 10.8 but half of the time I get an exception (ctrl-C
Hi,
If you have some apps or components which was written in Object Pascal and
you would like to use them in Web applications (client-side, previously
installed) what is the best option to choose nowadays?
My users use Windows so, I thought in ActiveX. It works, but I think Chrome
do not use
I realized I should have posted this in fpc-other. So, please reply in
[fpc-other] and not here.
On 05/23/2017 03:03 AM, Nikolay Nikolov wrote:
On 05/23/2017 01:20 AM, nore...@z505.com wrote:
On 2017-05-18 19:54, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster
>Here is a simple sample program that has the issue for me on both my windows
>10 desktop and my windows 10 laptop, both are 64bit.
>https://hastebin.com/nubonozaho.pas
I started thinking about this, and did some more tests, and I think I have
narrowed down what is really happening, but not
On 2017-05-18 19:54, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster
wrote:
62.44 1.33 1.33 fpc_frac_real
26.76 1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33 2.12 0.22
On 2017-05-19 05:25, Graeme Geldenhuys wrote:
On 2017-05-19 06:58, Florian Klämpfl wrote:
Over the weekend I’ll verify by testing on both FreeBSD and Windows,
and
then see if “calling conventions” make any difference.
*BSD is the same as Linux.
Good to know, thanks.
It has its purposes,
On 2017-05-19 06:16, Graeme Geldenhuys wrote:
On 2017-05-18 16:33, Reimar Grabowski wrote:
and JS is clearly not faster than FPC.
The JavaScript version runs very smooth on my system. There is no
framerate counter though, so I don't know how much faster.
http://jsdo.it/notch/dB1E
Again,
On 2017-05-19 06:32, Graeme Geldenhuys wrote:
Bottom line is, with the exact same code, NO work-arounds is required
for GCC or Java! So why must we have work-arounds for FPC? It's a
compiler or RTL issue - not being able to understand the code good
enough to generate more efficient binaries.
>I cannot reproduce it on my machine after the r714 fix. Can you send me a
>small example program, that demonstrates the problem, as well as detailed
>steps to reproduce?
Here is a simple sample program that has the issue for me on both my windows 10
desktop and my windows 10 laptop, both are
Hi,
On Mon, 22 May 2017, Nikolay Nikolov wrote:
> Today, I checked whether we can take advantage of this optimization for
> floats, but I didn't see any load-modify-store instructions in the x86
> instruction set (neither x87, nor SSE/AVX). Are there any floating point
> instructions on any
Am 22.05.2017 um 19:34 schrieb Nikolay Nikolov:
>
>
> On 05/20/2017 12:07 AM, Nikolay Nikolov wrote:
>>
>>
>> On 05/19/2017 11:24 PM, Sven Barth via fpc-pascal wrote:
>>> On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote:
Hi,
On Fri, 19 May 2017, Sven Barth via fpc-pascal
On 05/22/2017 02:21 AM, James Richters wrote:
I have the window title working, Thank you for that.
However I still have the same issue with non-responsive keyboard when I return
to the graph window after an ALT-TAB. I am running on windows 10 64bit -
program compiled for win32.
I cannot
On 05/20/2017 12:07 AM, Nikolay Nikolov wrote:
On 05/19/2017 11:24 PM, Sven Barth via fpc-pascal wrote:
On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote:
Hi,
On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:
I think Jeppe wanted to add vector support. Though the question
here
In our previous episode, Marco van de Voort said:
>
> i386:
> just compile : 7.9 (both 3.0.2 and 3.1.1)
> -O4 3.0.2: 8.2 3.1.1: 8.1
> -O4 -Opcoreavx2 -Cfavx2 -Cpcoreavx2 3.0.2 8.35 3.1.1 : 12.1
>
>
> x64: only 3.1.1, sometimes divide by zero (have to set exception mask?)
>
14 matches
Mail list logo