Re: [fpc-devel] LEA instruction speed

On 10/11/23 11:21, Tomas Hajny via fpc-devel wrote: On 2023-10-11 04:15, J. Gareth Moreton via fpc-devel wrote: Sweet, thank you.  Would you be willing to share your modified test's source? I was worried that if CPUID wasn't present it would cause a SIGILL. Sure, attached, but I didn't do

Re: [fpc-devel] WebAssembly compilation problems - Wasm32 symbol xxx without index value error

, Michalis czw., 30 mar 2023 o 21:11 Nikolay Nikolov via fpc-devel napisał(a): On 3/28/23 02:12, Michalis Kamburelis via fpc-devel wrote: Hi, We're experimenting with compiling Castle Game Engine using FPC WebAssembly target. A lot of units and classes compiled smoothly, however we hit a w

Re: [fpc-devel] WebAssembly compilation problems - Wasm32 symbol xxx without index value error

On 3/28/23 02:12, Michalis Kamburelis via fpc-devel wrote: Hi, We're experimenting with compiling Castle Game Engine using FPC WebAssembly target. A lot of units and classes compiled smoothly, however we hit a weird bug(s) at compiling our (big, too big!) unit X3DNodes. We get errors "Wasm32

Re: [fpc-devel] Sorting tests

On 11/30/22 08:30, Nikolay Nikolov wrote: On 11/30/22 01:57, J. Gareth Moreton via fpc-devel wrote: Familarity mostly.  More people are familiar with quicksort than introsort. Are there any explicit code examples where quicksort succeeds and introsort fails?  I'm told even Lazarus crashes

Re: [fpc-devel] Sorting tests

On 11/30/22 01:57, J. Gareth Moreton via fpc-devel wrote: Familarity mostly.  More people are familiar with quicksort than introsort. Are there any explicit code examples where quicksort succeeds and introsort fails?  I'm told even Lazarus crashes (or used to crash), so I'll be interested to

Re: [fpc-devel] Sorting tests

On 11/29/22 22:16, J. Gareth Moreton via fpc-devel wrote: On 29/11/2022 20:03, Nikolay Nikolov via fpc-devel wrote: if (a That's the big one that sorting algorithms rely on... the transitive law.  If that is violated, then you cannot guarantee a sorted result. It doesn't matter if (a <

Re: [fpc-devel] Sorting tests

On 11/29/22 16:44, Ondrej Pokorny via fpc-devel wrote: Am 29.11.2022 um 14:25 schrieb Sven Barth via fpc-devel: For such a comparison function the issue is indeed in the comparison function, but Nikolay also mentioned "ais the case for equal elements. I assume this was some kind of typo or

Re: [fpc-devel] Sorting tests

On 11/24/22 20:51, J. Gareth Moreton via fpc-devel wrote: Hi everyone, I just need to touch on the knowledge base.  What tests exist that test the functionality of rtl/inc/sortbase.pp?  As Olly suggested, I'm looking at creating Introsort for this unit as well, but I need to know if such a

Re: [fpc-devel] Wasm/embedded target compilation error

On 7/22/22 01:36, Kostas Michalopoulos via fpc-devel wrote: Hi all, I was trying to use the Wasm/embedded target to port a game i made some time ago[0] to WebAssembly to run inside a browser, but i am getting a bunch of errors that i can't figure out the issue. When compiling with the

Re: [fpc-devel] Questions about cross-compiling (z80)

On 2/11/22 19:14, Sven Barth via fpc-devel wrote: Tomas Hajny via fpc-devel schrieb am Fr., 11. Feb. 2022, 17:24: On 2022-02-11 14:14, Sven Barth via fpc-devel wrote: > BogDan via fpc-devel schrieb am Fr., > 11. Feb. 2022, 11:09:   .   . >> It seems is an IHX

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 1/15/22 01:47, Ben Grasset via fpc-devel wrote: On Fri, Jan 14, 2022 at 5:49 AM Nikolay Nikolov via fpc-devel wrote: No, it's not, because in linux I tested "make -j24 all" in the compiler directory That isn't what you said in your original comment about benchmarking

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 1/14/22 06:45, Ben Grasset via fpc-devel wrote: On Thu, Jan 13, 2022 at 11:38 PM Nikolay Nikolov via fpc-devel wrote: For the record, I did try make cycle for ppc386 and ppcx64 on my Windows 10 (with Windows Defender turned on) and both finished in exactly 42 seconds

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 1/14/22 05:55, Ben Grasset via fpc-devel wrote: On Thu, Jan 13, 2022 at 10:18 PM Nikolay Nikolov via fpc-devel wrote: Just for the record, is this with antivirus off or on and which antivirus program? I have no anti-virus actively installed or enabled on an ongoing basis at all

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 1/14/22 03:18, Ben Grasset via fpc-devel wrote: On Thu, Jan 13, 2022 at 11:28 AM Nikolay Nikolov via fpc-devel wrote: So, instead of giving actual benchmark data on the Windows performance, you speculate by claiming that having faster exception handling matters, and then you

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 1/13/22 16:33, Nikolay Nikolov wrote: On 1/13/22 10:58, Ben Grasset via fpc-devel wrote: On Thu, Jan 13, 2022 at 1:58 AM Nikolay Nikolov via fpc-devel wrote: I haven't tested in Windows, but it would be very strange and suspicious if the results are very different. It would

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 1/13/22 10:50, Ben Grasset via fpc-devel wrote: On Thu, Jan 13, 2022 at 1:25 AM Nikolay Nikolov via fpc-devel wrote: We do care about scientific code as well as fast code, that's why we support both the FPU and SSE2+ (as well as AVX, etc.). FPC *chooses *not to generate x87 FPU

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 1/13/22 10:58, Ben Grasset via fpc-devel wrote: On Thu, Jan 13, 2022 at 1:58 AM Nikolay Nikolov via fpc-devel wrote: I haven't tested in Windows, but it would be very strange and suspicious if the results are very different. It would be neither of those things. The exception

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 1/13/22 02:31, Ben Grasset via fpc-devel wrote: On Wed, Jan 12, 2022 at 7:38 AM Martin Frb via fpc-devel wrote: The downloads provided by Lazarus are also NOT a "pure, native 64-bit download". Only the "fpc.exe" and the non-cross "ppc64.exe" are native 64 bit. As I

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 1/13/22 07:44, Ben Grasset via fpc-devel wrote: It does work on 64-bit Windows, it's just technically deprecated. Beyond that, the 80-bit Extended type dates back to the mid 1980s, The year 1980, not the mid 1980s. But the x86 family dates back to 1978. Most x86_64 instructions are the

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

On 1/13/22 05:59, Travis Siegel via fpc-devel wrote: On 1/12/2022 5:20 PM, Sven Barth via fpc-devel wrote: When compiling from a target supporting Extended to one only supporting Double there isn't a loss of precision when calculating values at compile time. The other way around however,

Re: [fpc-devel] Discussion on a particular optimisation development (WARNING: Technical!)

On 2/2/21 11:06 PM, J. Gareth Moreton via fpc-devel wrote: Hi everyone, I've found a potential optimisation for conditions of the form "(x <> 0) and (y <> 0)", which are very common because this is semantically equivalent to "Assigned(x) and Assigned(y)", for example, and such a construct

Re: [fpc-devel] x86_64 question

platform a Windows or a Unix machine?  I ask because I don't want to send you functions that use the wrong calling convention! I dual boot Linux and Windows, but prefer testing on Linux. Best regards, Nikolay Gareth aka. Kit On 02/10/2020 14:13, Nikolay Nikolov via fpc-devel wrote: On 10/2

Re: [fpc-devel] x86_64 question

On 10/2/20 2:13 PM, J. Gareth Moreton via fpc-devel wrote: Confirmed my suspicions.  if I zero the upper bits of the register (I used something akin to "AND RCX, $F"), there is no speed loss. Therefore, I can make the hypothesis, on my Intel(R) Core(TM) i7-10750H, that using TEST on a

Re: [fpc-devel] x86_64 question

On 10/1/20 11:36 PM, J. Gareth Moreton via fpc-devel wrote: I thought that might be the case - thanks Nikolay.  And I meant to say lower bits of a REGISTER, not an instruction! Admittedly I'm cycle-counting and byte-counting again!  I was looking for ways to reduce 13 bytes of padding in one

Re: [fpc-devel] x86_64 question

On 10/1/20 8:17 PM, J. Gareth Moreton via fpc-devel wrote: Hi everyone, I have a small question with assembler size optimisation that maybe one of you guys can give me a second opinion on: If you are using the "test" instruction to test some of the lower bits of an instruction, e.g. TEST

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

On 9/28/20 10:01 PM, Bart via fpc-devel wrote: On Mon, Sep 28, 2020 at 3:45 PM Nikolay Nikolov via fpc-devel wrote: compile to win32 via: fpc -Pi386 hello.pas AFAIK a simple fpc hello.pas will do in that setup. Yes, that is true. The -Pi386 is optional in this case. and to win64 via

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

On 9/28/20 12:24 AM, Travis Siegel via fpc-devel wrote: How does one get a 64-bit version on windows.  When I try to run a 64-bit version on windows, I encounter an error, though I don't remember what that error is, since I've not tried it for a couple weeks.  I didn't even know there was a

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

On 9/28/20 12:30 AM, Tomas Hajny via fpc-devel wrote: On 2020-09-27 18:27, Nikolay Nikolov via fpc-devel wrote: On 9/27/20 7:21 PM, Florian Klämpfl via fpc-devel wrote: Am 27.09.20 um 18:03 schrieb Martin Frb via fpc-devel: On 27/09/2020 09:34, Sven Barth via fpc-devel wrote: Ben Grasset via

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

On 9/27/20 7:21 PM, Florian Klämpfl via fpc-devel wrote: Am 27.09.20 um 18:03 schrieb Martin Frb via fpc-devel: On 27/09/2020 09:34, Sven Barth via fpc-devel wrote: Ben Grasset via fpc-devel > schrieb am So., 27. Sep. 2020, 07:50:     That last quote

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

On 9/27/20 7:03 PM, Martin Frb via fpc-devel wrote: On 27/09/2020 09:34, Sven Barth via fpc-devel wrote: Ben Grasset via fpc-devel > schrieb am So., 27. Sep. 2020, 07:50: That last quote is absolute BS, to be very frank. There is no reason

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

On 9/27/20 10:48 AM, Florian Klämpfl via fpc-devel wrote: As long as there is no generic 80 bit float support in the compiler, there is no need to discuss anything else. Yes. And unlike some other compilers, we don't exhaust our 32-bit address space during compilation or linking of very

Re: [fpc-devel] Object upgrades

On 5/27/19 1:08 AM, Ryan Joseph wrote: Records don’t have a VMT table and overriding but otherwise they’re the same afaik (constructors don’t work the same also). Operator overloads simply aren’t enabled for objects because apparently they’re a legacy syntax but as you pointed out they’re

Re: [fpc-devel] New sorting routines

On 2/3/19 11:22 PM, C Western wrote: I suspect the new sorting routines need some work - lazarus compiled with the latest trunk hangs on start up, and it looks like an infinite loop in sorting. Stack trace below. Even though the sort routine did slightly change, I believe this exposes a bug

Re: [fpc-devel] Wrong docs: not initialized global variables

On 04/05/2018 05:22 PM, Karoly Balogh (Charlie/SGR) wrote: 2.) Class fields are initialized. (Why is simple class fields initialization needed for internal bookkeeping of the compiler?) I think this is something which happens when constructing the class, so this is runtime behavior, and not

Re: [fpc-devel] rdtscp

On 10/23/2017 02:21 AM, Wolf wrote: On 23/10/17 02:53, Nikolay Nikolov wrote: FPC trunk supports rdtscp. And if you're using a FPC version that doesn't support an instruction, you can always hardcode it with 'db' (make sure you add a comment with the real instruction to keep your code

Re: [fpc-devel] rdtscp

On 10/21/2017 10:41 PM, Wolf wrote: Hi, How do you measure time with a one cycle resolution? EpicTimer clearly does not cut it, and from what I gather , rdtsc cannot do it either. You

Re: [fpc-devel] Last call for 3.0.4 merges

On 06/18/2017 01:33 AM, Nikolay Nikolov wrote: On 06/17/2017 10:31 PM, Marco van de Voort wrote: While I have not done much the last month, I did keep up with most of the merging so most requests have been honoured, and I plan to branch mid next week or even monday if there is not much

Re: [fpc-devel] Last call for 3.0.4 merges

On 06/17/2017 10:31 PM, Marco van de Voort wrote: While I have not done much the last month, I did keep up with most of the merging so most requests have been honoured, and I plan to branch mid next week or even monday if there is not much response. If I missed some, or there are important

Re: [fpc-devel] Last call for 3.0.4 merges

On 06/17/2017 10:31 PM, Marco van de Voort wrote: While I have not done much the last month, I did keep up with most of the merging so most requests have been honoured, and I plan to branch mid next week or even monday if there is not much response. If I missed some, or there are important

Re: [fpc-devel] Just saw that FreeSparta now is open source :-)

On 03/22/2015 11:12 PM, Maciej Izak wrote: Yes, it has been submitted in the fpc bug tracker as well: http://bugs.freepascal.org/view.php?id=27206 Hi, you are wrong :), my http://bugs.freepascal.org/view.php?id=27206 is only for Generics.Collections library. My new dedicated

Re: [fpc-devel] Just saw that FreeSparta now is open source :-)

On 03/22/2015 10:12 PM, Boian Mitov wrote: Hello Everyone, Just saw this on Google+, I think it will be great if some of it makes it into Lazarus :-) . FreeSparta is now really free (new interface for Lazarus (similar to Delphi), and Generics.Collections library). Soon will be possible to

Re: [fpc-devel] Dumping the syntax tree

guess it shouldn't be too hard to make the compiler output ppu files for programs as well. Nikolay On 10/22/2014 4:44 AM, Nikolay Nikolov wrote: On 10/22/2014 12:23 AM, Vsevolod Alekseyev wrote: Hi all, I wonder where in the FPC compilation flow would be a good spot to dump the parsed

Re: [fpc-devel] Dumping the syntax tree

On 10/22/2014 12:23 AM, Vsevolod Alekseyev wrote: Hi all, I wonder where in the FPC compilation flow would be a good spot to dump the parsed syntax tree of a source? Here's why I'm asking. For a while now, I've been struggling to adapt a bunch of Pascal code to various mobile platforms.

Re: [fpc-devel] Suggestion: reference counted objects

On 10/13/2014 10:58 PM, Sven Barth wrote: On 13.10.2014 19:23, hinsta...@yandex.ru wrote: Great! Sorry for misspelling your name btw I had worse already. Swen for example. Or a common one at uni was Svn ;) Better than git ;-) Nikolay ___

Re: [fpc-devel] Support needed in understanding some heap.inc related stuff

On 09/28/2014 05:45 PM, Lag Programming wrote: Hi! I need some help in understanding three things viewed in heap.inc. ... 3) I'm not interested in the importance of the presented function. Why the existing code design is preferred over alternative code? Existing code: function

Re: [fpc-devel] Support needed in understanding some heap.inc related stuff

On 09/28/2014 08:58 PM, Lag Programming wrote: @Nikolay Thank you for your answer. :) Now that you've answered, can you further respond to the following question: why is it needed to zero fill the memory allocated that exceeds the requested value? a) pointer:=allocmem(initialsize);

Re: [fpc-devel] weak referencing (was Suggestion:.....)

On 09/23/2014 11:31 AM, Giuliano Colla wrote: Il 23/09/2014 02:24, John Briggs ha scritto: Sven At the risk of starting a flame war I have been pondering this question since these threads have started: Why has there been so many messages on this list debating the pros and cons of reference

Re: [fpc-devel] weak referencing (was Suggestion:.....)

On 09/23/2014 03:55 AM, Boian Mitov wrote: Because none of those is a strong typed language. Each language has weak and strong points. Pascal is semi strong typed language, and as such is very well declarative style oriented. Functional programming however merges very well with strong typed

Re: [fpc-devel] Suggestion: reference counted objects

On 09/23/2014 08:47 PM, Boian Mitov wrote: This is a valid point. The only downside is that the object will every time do a deep copy versus a shallow (pointer only) copy. Deep copy is very, very expensive operation. Adding ref. counting to objects is probably equivalent of one interlocked

Re: [fpc-devel] binutils for avr 8 bit

On 05/26/2014 03:32 PM, Sven Barth wrote: Am 26.05.2014 11:42 schrieb Michael Schnell mschn...@lumino.de mailto:mschn...@lumino.de: On 05/26/2014 11:37 AM, Sven Barth wrote: Where did he say that he wants to sell anything? Maybe he just wants to try FPC on AVR 8-bit for fun? OK :-)

Re: [fpc-devel] OT: Code generation

On 04/11/2014 11:22 AM, Mark Morgan Lloyd wrote: Knowing that there are some good compiler guys in here: does anybody remember a paper and set of patches for GCC that randomises register allocation and makes random choices for the code generator (e.g. zero a register either by xor a,a or sub

Re: [fpc-devel] i8086 huge pointers

On 9.4.2014 г. 16:32, Max Nazhalov wrote: 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

Re: [fpc-devel] i8086 huge pointers

On 7.4.2014 г. 15:09, Max Nazhalov wrote: 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

Re: [fpc-devel] i8086 huge pointers

On 04/07/2014 03:51 AM, Max Nazhalov wrote: 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

Re: [fpc-devel] i8086 huge pointers

On 04/07/2014 12:10 PM, Tomas Hajny wrote: On Mon, April 7, 2014 10:56, Nikolay Nikolov wrote: . . Ok, I just added this constant to the msdos rtl (r27497). However, as far as BP7 compatibility is concerned, it doesn't really matter which huge pointer model we use, because BP7 doesn't have

[fpc-devel] i8086 huge pointers

I started investigating huge pointer support in 16-bit C compilers and discovered there are at least two different implementations: Borland C++ 3.1: Huge pointers aren't changed when converting from a far pointer. They are normalized as soon as some pointer arithmetic is performed on them.

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

On 03/10/2014 03:03 PM, Sven Barth wrote: Am 10.03.2014 13:52, schrieb Vsevolod Alekseyev: I don't now remember the exact history behind each replacement, but here they are. - DGROUP is a problem; I comment it out - So is ASSUME - The syntax of SEGMENT is different - Instead of .386p

Re: [fpc-devel] optimizing the peephole optimizer?

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 and x86_64 ... And don't forget i8086 :) I think

Re: [fpc-devel] optimizing the peephole optimizer?

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 :) Nikolay ___ fpc-devel maillist -

Re: [fpc-devel] DOS GUI

On 01/16/2014 05:17 PM, Jonas Maebe wrote: On 16 Jan 2014, at 16:11, Travis Siegel wrote: The only problem with the whole public domain thing is that it's not as easy to donate things to public domain as one thinks. Beats me why, but there's a whole legal thing, apparently, you can't just

Re: [fpc-devel] Improving i8086 performance..

On 01/01/2014 05:35 PM, Max Nazhalov wrote: Date: Tue, 31 Dec 2013 19:42:44 +0200 From: Nikolay Nikolov nick...@gmail.com 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

Re: [fpc-devel] Improving i8086 performance..

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 The 286 is a speed monster! :) Nikolay ___ fpc-devel maillist -

Re: [fpc-devel] Improving i8086 performance..

On 12/28/2013 04:52 PM, Max Nazhalov wrote: 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

Re: [fpc-devel] Improving i8086 performance..

On 12/23/2013 03:34 PM, Max Nazhalov wrote: 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

Re: [fpc-devel] State of i8086 generation?

On 11/30/2013 12:33 AM, Jim Leonard wrote: On 11/29/2013 3:45 PM, Nikolay Nikolov wrote: It should be functional, although it does break occasionally, so you should always keep the latest working version if you plan on using it. I run the testsuite weekly and try to fix any regressions

Re: [fpc-devel] Multithreading under DOS

On 09/27/2013 11:15 AM, Marco van de Voort wrote: In our previous episode, Nikolay Nikolov said: if you aim to use 32-bit anyway, I see no reason to use an DOS extender over a real multitasking OS. Low resource usage perhaps. How well does Linux run on a 386 with 4 MB of RAM? What about 2 MB

Re: [fpc-devel] Multithreading under DOS

On 09/25/2013 08:13 PM, Tomas Hajny wrote: Anyway, interesting thread. ;-) Still, the overall goal (or set of goals) is not clear for me from the limited context included: Ok, here's my point: Since the FPC RTL offers pluggable thread manager support, we can offer multiple implementations.

Re: [fpc-devel] Multithreading under DOS

On 09/26/2013 08:24 PM, Leif Ekblad wrote: DOS extenders are even worse candidates for multitasking than DOS. And if you aim to use 32-bit anyway, I see no reason to use an DOS extender over a real multitasking OS. Low resource usage perhaps. How well does Linux run on a 386 with 4 MB of RAM?

Re: [fpc-devel] Multithreading under DOS

On 09/26/2013 09:25 PM, Sven Barth wrote: On 26.09.2013 19:48, Nikolay Nikolov wrote: On 09/26/2013 08:24 PM, Leif Ekblad wrote: DOS extenders are even worse candidates for multitasking than DOS. And if you aim to use 32-bit anyway, I see no reason to use an DOS extender over a real

Re: [fpc-devel] Multithreading under DOS

On 09/26/2013 09:41 PM, Hans-Peter Diettrich wrote: Nikolay Nikolov schrieb: On 09/26/2013 08:24 PM, Leif Ekblad wrote: DOS extenders are even worse candidates for multitasking than DOS. And if you aim to use 32-bit anyway, I see no reason to use an DOS extender over a real multitasking OS

Re: [fpc-devel] Multithreading under DOS

On 09/26/2013 11:33 PM, Tomas Hajny wrote: On Thu, September 26, 2013 21:03, Nikolay Nikolov wrote: On 09/26/2013 09:41 PM, Hans-Peter Diettrich wrote: Nikolay Nikolov schrieb: On 09/26/2013 08:24 PM, Leif Ekblad wrote: DOS extenders are even worse candidates for multitasking than DOS

[fpc-devel] Multithreading under DOS (was: [Lazarus] Why development remains constant for msdos?)

On 09/25/2013 01:45 PM, Mark Morgan Lloyd wrote: Nikolay Nikolov wrote: On 09/25/2013 11:26 AM, Michael Schnell wrote: On 09/24/2013 10:58 AM, Nikolay Nikolov wrote: When you try to create a thread, your program terminates and writes a message that threading is not supported. While

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

As an ex-competitive programmer and multiple IOI and BOI medalist, let me try to explain, although I realize it might be difficult for normal programmers to understand, but let's just say that: - the people who setup the programming environment for these competitions are not the same people

[fpc-devel] How are Makefile and Makefile.fpc regenerated in fpc trunk?

Hi, I'd like to update hermes and ptcpas to the latest version in the fpc trunk, but I don't know how to regenerate the Makefile and Makefile.fpc files. I'm new to fpmake, I've only used fpcmake before. Nikolay ___ fpc-devel maillist -

Re: [fpc-devel] Bounty for MIPS

On 01/29/2012 02:21 PM, Florian Klämpfl wrote: Main problem with MIPS is to get hands on a reasonable development system (full fledged unix like Debian Linux, *BSD, CPU in the range of 1 GHz, 128 MB or more RAM, at least 1 GB of HD/SSD). Cross compiling is possible of course, but it makes

Re: [fpc-devel] Free Pascal 2.4.4 available

On 05/28/2011 12:13 AM, Marco van de Voort wrote: In our previous episode, Nikolay Nikolov said: The go32v2 download links are broken: http://freepascal.org/down/i386/go32v2-ftp.freepascal.org.var The file names should be dos244.zip and dos244full.zip, not dos242.zip and dos242full.zip

Re: [fpc-devel] Free Pascal 2.4.4 available

The go32v2 download links are broken: http://freepascal.org/down/i386/go32v2-ftp.freepascal.org.var The file names should be dos244.zip and dos244full.zip, not dos242.zip and dos242full.zip ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)

On 11/26/2010 10:42 AM, Max Vlasov wrote: Is anyone aware of similar concept in any other OOP language? Yes, C++ has it: http://duramecho.com/ComputerInformation/WhyHowCppConst.html It's true that it's a little bit messy, but that's pretty much the norm with everything in C++ ;-)

Re: [fpc-devel] proposal for palette-related graph unit interface changes

On 09/17/2010 04:32 PM, Florian Klaempfl wrote: Am 15.09.2010 17:05, schrieb Nikolay Nikolov: On 09/15/2010 05:48 PM, Florian Klaempfl wrote: Am 15.09.2010 16:39, schrieb Nikolay Nikolov: and then introduce TP7-compatible MaxColors, PaletteType and procedures/functions. They'll be made

[fpc-devel] proposal for palette-related graph unit interface changes

Currently, the following palette-related things from the fpc graph unit aren't TP7 compatible: MaxColors (constant) PaletteType (record) procedure SetAllPalette(const Palette: PaletteType); procedure GetPalette(var Palette: PaletteType); function GetPaletteSize: smallint; procedure

Re: [fpc-devel] proposal for palette-related graph unit interface changes

On 09/15/2010 05:48 PM, Florian Klaempfl wrote: Am 15.09.2010 16:39, schrieb Nikolay Nikolov: and then introduce TP7-compatible MaxColors, PaletteType and procedures/functions. They'll be made optionally hookable (so the go32v2 implementation will be able to implement them with the real EGA

Re: [fpc-devel] proposal for palette-related graph unit interface changes

On 09/15/2010 06:27 PM, Tomas Hajny wrote: On Wed, September 15, 2010 16:39, Nikolay Nikolov wrote: Currently, the following palette-related things from the fpc graph unit aren't TP7 compatible: MaxColors (constant) PaletteType (record) procedure SetAllPalette(const Palette: PaletteType

Re: [fpc-devel] proposal for palette-related graph unit interface changes

On 09/15/2010 05:39 PM, Nikolay Nikolov wrote: Currently, the following palette-related things from the fpc graph unit aren't TP7 compatible: ... What do you think? There are also 2 other palette-related incompatibilities, that I'd also like to fix. They're relatively independent from

Re: [fpc-devel] UTF-8 patch for the video unit

On 09/19/2009 05:16 PM, Olivier Coursiere wrote: Nice ! What used to be a hack for the limited BeOS terminal now become a feature. Well, initially I was just trying to fix the feature that switched the linux console out of UTF-8 mode, which caused most non-ascii characters to look wrong (if

[fpc-devel] fpsignal broken on linux-x86_64 (+patch)

Hi On linux-x86_64, programs have odd behaviour after a signal handler, installed with fpsignal is invoked. The handler executes fine and after it finishes, the program either crashes or terminates. Attached program demonstrates this, when run on linux-x86_64. After some debugging, I found

Re: [fpc-devel] fpsignal broken on linux-x86_64 (+patch)

Submitted a bug report: http://bugs.freepascal.org/view.php?id=14514 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] UTF-8 patch for the video unit

Hi all, spent some time today, trying to make the text mode IDE look pretty under modern Linuxes and here's the result - a patch for UTF-8 console output. Previously, only BeOS used UTF-8. Tested with: - the linux console - xterm - gnome-terminal - konsole - rxvt-unicode all under Fedora

Re: [fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit

On 08/16/2009 04:29 PM, Daniël Mantione wrote: I can see the issue with abnormal program exits, but I disabled it because calling it twice had unintended effects. So we need to verify we don't break anything. Well, I can think of 2 thing that could go wrong: - DoneKeyboard is called _after_

[fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit

Does anyone have an idea why the call to DoneKeyboard was previously commented? It leaves the keyboard in a bad state if the IDE crashes. Index: packages/fv/src/drivers.pas === --- packages/fv/src/drivers.pas (revision 13526) +++

Re: [fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit

On 08/16/2009 03:22 PM, Daniël Mantione wrote: Op Sun, 16 Aug 2009, schreef Jonas Maebe: On 16 Aug 2009, at 12:15, Nikolay Nikolov wrote: Does anyone have an idea why the call to DoneKeyboard was previously commented? It leaves the keyboard in a bad state if the IDE crashes

[fpc-devel] Microsoft Game API header translation for Windows CE

For more information about GAPI: http://msdn2.microsoft.com/en-us/library/aa459123.aspx You may add this unit to the fpc wince rtl, if you want. Unit gx; {$MODE objfpc} { convention is cdecl for WinCE API} {$calling cdecl} Interface Uses Windows; Const GXDLL = 'gx'; Type

[fpc-devel] patch for unit sockets

SocketError should be a threadvar, I think Index: rtl/inc/socketsh.inc === --- rtl/inc/socketsh.inc(revision 2308) +++ rtl/inc/socketsh.inc(working copy) @@ -152,7 +152,7 @@ TSockArray = Array[1..2] of Longint;

Re: [fpc-devel] patch for unit sockets

Marco van de Voort wrote: SocketError should be a threadvar, I think Socketerror is legacy. Use fpgeterrno (or errno) to get the error. 1.0.x had no threadsupport Yes, but there's no fpgeterrno in win32 :) ___ fpc-devel maillist -

Re: [fpc-devel] PR advancement

Adriaan van Os wrote: P.S. Here is a text, specially for managers, applicable for any tech project: Blah blah ... de facto standard ... Blah blah ... highly committed ... Blah bah ... industrial strength ... Blah blah ... world class support ... Blah blah ... handholding ... Blah blah ...

[fpc-devel] X11/cursorfont.h header translation

X11/cursorfont.h header translation. Yes, it's one of the standard headers of the official Xlib :) { $Xorg: cursorfont.h,v 1.4 2001/02/09 02:03:39 xorgcvs Exp $ } { Copyright 1987, 1998 The Open Group Permission to use, copy, modify, distribute, and sell this software and its documentation for

Re: [fpc-devel] broken shmat on x86_64-linux

Jonas Maebe wrote: On 29 sep 2005, at 22:35, Florian Klaempfl wrote: Can anybody who understand the patch, apply it ;)? Does ir work for i386 too? Patch looks ok according to what I see in the man page of shmat on a x86-64 box here. It just seems error checking (via errno) is missing

[fpc-devel] broken shmat on x86_64-linux

The 'shmat' function from the 'ipc' unit seems to be broken on x86_64-linux. This patch seems to fix it. (Apply to rtl/linux/ipcsys.inc) 35,36d34 Var raddr : pointer; error : ptrint; 38,42c36

[fpc-devel] header translation for the X Window System video extension

you may add it to packages/extra/x11 x11.tar.gz Description: GNU Zip compressed data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PPC64 port

Florian Klaempfl wrote: I think it depends if other people are working on it as well. How many people are working on it? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] integer, cardinal

Ales Katona wrote: I think that pascal typesystem requires a bit overhaul when it comes to integers. First of all Integer should be size independent, that is, xy bits depending on the platform. All others should be specific. Second, we should force people in a friendly way to use more

  1   2   >