Am 17.02.19 um 02:42 schrieb Neil Graham:
On 17/02/19 10:37 AM, Ralf Quint wrote:
On 2/14/2019 9:28 PM, James via fpc-devel wrote:
I'm interested in starting (or joining) a discussion on the next
(*non* backwards compatible) version of FPC. Instead of being
classically object oriented, there i
Am 17.02.19 um 04:48 schrieb Ben Grasset:
His compiler code was / is just kind of an unreadable mess, to be
perfectly honest.
This is a property of production compiler code.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepa
Am 17.02.19 um 01:47 schrieb Ralf Quint:
On 2/16/2019 12:43 AM, Florian Klämpfl wrote:
but we try as much as possible to break old code.
Really? =-O
Ralf ;-)
You should have noticed, you follow this list for years/decades ;)?
___
fpc-devel mailli
Am So., 17. Feb. 2019, 04:42 hat Ben Grasset
geschrieben:
> The idea that it is "bloated" as I sometimes hear doesn't make a whole lot
> of sense, for one. FPC does not magically add things you don't use to your
> binary. How would that work? Why would you think it did? It's illogical.
>
For som
On 2/17/2019 12:15 AM, Florian Klämpfl wrote:
Am 17.02.19 um 01:47 schrieb Ralf Quint:
On 2/16/2019 12:43 AM, Florian Klämpfl wrote:
but we try as much as possible to break old code.
Really? =-O
Ralf ;-)
You should have noticed, you follow this list for years/decades ;)?
Yup, it's prob
On 17/02/19 9:12 PM, Florian Klämpfl wrote:
Am 17.02.19 um 02:42 schrieb Neil Graham:
I think for the most part, if any clean slate is needed for FPC it is
for the Libraries and not the language. A Class library that was
built to support the language as it currently stands rather than
colle
There are some good examples out there where being able to directly inline
assembler routines has beneficial importance but where intrinsics don't cut
it. One example is the following:
function GetClockTics_RDTSC: QWord; assembler; nostackframe; inline;
asm
RDTSC
{$ifdef CPUX64}
SHL RDX
> On Feb 17, 2019, at 3:24 AM, Sven Barth via fpc-devel
> wrote:
>
> Blaise is still working on it. Some bugs still need to be fixed and then he
> needs to adjust the code to the points of criticism I had given. Most
> importantly however are the missing tests. Even if the feature would be
The debug_eh branch contains now support for dwarf based exception
handling for i386-linux.
Testing fpc/tests/bench/bansi1.pp gives with trunk
Test 1: 100 done in 0.367 sec
Test 2: 100 done in 0.414 sec
Test 3: 100 done in 0.359 sec
while with debug_eh it results in
Test 1: 10
