Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Michael Schnell
Jonas Maebe wrote: Does anyone see a problem with the following CSuspendThread/CResumeThread implementations? 1) This of course is the Linux version. Are the other implementation already in place so that the result is platform independent ? 2) In Linux we have the old ("Linux thread" ->

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Michael Van Canneyt
On Wed, 8 Nov 2006, Michael Schnell wrote: > Jonas Maebe wrote: > > > > Does anyone see a problem with the following CSuspendThread/CResumeThread > > implementations? > > > > 1) This of course is the Linux version. Are the other implementation already > in place so that the result is platform i

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
As for general use, you can't do a Timer this way. Right ! The beauty of TTimer (and GUI events as well) is that it does not work in a thread. Otherwise it e.g. would not be possible to do GUI stuff in a timer event, as VCL and LCL are not thread save (and probably can't be made thread save).

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Van Canneyt
On Wed, 8 Nov 2006, Michael Schnell wrote: > > > As for general use, you can't do a Timer this way. > Right ! The beauty of TTimer (and GUI events as well) is that it does not work > in a thread. Otherwise it e.g. would not be possible to do GUI stuff in a > timer event, as VCL and LCL are not

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 09:15, Michael Schnell wrote: > Right ! The beauty of TTimer (and GUI events as well) is that it does > not work in a thread. Well, I don't consider it beautiful, I consider it a hack. :) Vinzent. ___ fpc-devel maillist

Re: [fpc-devel] Bug 0007281 / MemLeak with interfaces

2006-11-08 Thread Jonas Maebe
On 8 nov 2006, at 06:52, Martin Schreiber wrote: But what should we do if we can't use trunk because it is not stable and we can't use 2.0.4 because it is buggy? There will *always* be bugs in the latest release which cause it not to work for some people. If we'd release a 2.0.6, that sit

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Ales Katona
On st , 2006-11-08 at 07:35 +, Vinzent Hoefler wrote: > On Tuesday 07 November 2006 16:10, Ales Katona wrote: > > > As for general use, you can't do a Timer this way. > > Believe me, I can. :) > > > You can't just put > > a TTimer in which works in it's own thread and then calls some > > cal

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote: > On Wed, 8 Nov 2006, Michael Schnell wrote: > > > As for general use, you can't do a Timer this way. > > > > Right ! The beauty of TTimer (and GUI events as well) is that it > > does not work in a thread. Otherwise it e.g. would not b

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
Vinzent Hoefler wrote: On Tuesday 07 November 2006 17:10, Michael Schnell wrote: Of course, because the common concept of a timer is as asynchronous as in "multi-threaded" or even "interrupt". That is not true ! (See my other post.) Well, a timer i

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Jonas Maebe
On 8 nov 2006, at 10:05, Michael Schnell wrote: Does anyone see a problem with the following CSuspendThread/ CResumeThread implementations? 1) This of course is the Linux version. No, it's the generic *nix version (i.e., also used for Free/Net/ OpenBSD, Darwin and Solaris). Are the other

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
There is TCustomApplication in fcl/inc/custapp. The Lazarus TApplication descends from it. All you need to do is create a descendent of TCustomApplication which can implement all the messaging you wish for... That sounds very good. :-) I'll take a look at this. (Supposedly in January :

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Ales Katona
Jonas currently fpc2.1.1 doesn't compile on 2.1.1 with: rtl/units/i386-freebsd -di386 -dRELEASE ../unix/cthreads.pp cthreads.pp(252,42) Error: Incompatible type for arg no. 1: Got "LongInt", expected "Pointer" Note: unixtypes thread_t = pointer pthreads.inc thread_t (BSD and linux) = cInt {linux

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Van Canneyt
On Wed, 8 Nov 2006, Vinzent Hoefler wrote: > On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote: > > On Wed, 8 Nov 2006, Michael Schnell wrote: > > > > As for general use, you can't do a Timer this way. > > > > > > Right ! The beauty of TTimer (and GUI events as well) is that it > >

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Michael Van Canneyt
On Wed, 8 Nov 2006, Ales Katona wrote: > Jonas currently fpc2.1.1 doesn't compile on 2.1.1 with: > > rtl/units/i386-freebsd -di386 -dRELEASE ../unix/cthreads.pp > cthreads.pp(252,42) Error: Incompatible type for arg no. 1: Got > "LongInt", expected "Pointer" > > Note: > unixtypes thread_t = po

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 09:27, Ales Katona wrote: > On st , 2006-11-08 at 07:35 +, Vinzent Hoefler wrote: > > On Tuesday 07 November 2006 16:10, Ales Katona wrote: > > > As for general use, you can't do a Timer this way. > > > > Believe me, I can. :) > > > > > You can't just put > > > a T

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 09:42, Michael Van Canneyt wrote: > On Wed, 8 Nov 2006, Vinzent Hoefler wrote: > > On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote: > > > On Wed, 8 Nov 2006, Michael Schnell wrote: > > > > > As for general use, you can't do a Timer this way. > > > > > >

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Marco van de Voort
> Note: > unixtypes thread_t = pointer Wrong, same as in ptypes.inc > pthreads.inc thread_t (BSD and linux) = cInt {linux is Longint but > that's just bug) freebsd/pthreads.inc doesn't define thread_t, neither does the linux version? There is a small issue with tthreadid which is already used t

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
I even call the callback of another thread. :P No you can't. You still refuse to tell me why, so please stop telling me what I can't do, especially when I *am* doing it. Of course you can call any callback that exists in the application from anywher

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Jonas Maebe
On 8 nov 2006, at 10:42, Ales Katona wrote: Jonas currently fpc2.1.1 doesn't compile on 2.1.1 with: rtl/units/i386-freebsd -di386 -dRELEASE ../unix/cthreads.pp cthreads.pp(252,42) Error: Incompatible type for arg no. 1: Got "LongInt", expected "Pointer" So either TThreadID or pthread_t is de

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
It all depends on what you're trying to accomplish. I still like to have a "asynchronous timer event" model. It would still simplify some code. You are right that this would be desirable. Normal Delphi/Lazarus like TTimers are non-preemptive (you may call it synchronous) for a good reason

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Ales Katona
A cleaner naming of problematic parts: 1. TThreadID is defined stand-alone not as a pthread_t, should be fixed. 2. TThreadHandler (the callback for resume, suspend) has result as DWord while posix stuff (pthread_kill etc.) usualy return cInt 3. in linux I saw pthreads functions return longint, I t

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Jonas Maebe
On 8 nov 2006, at 11:16, Ales Katona wrote: A cleaner naming of problematic parts: 1. TThreadID is defined stand-alone not as a pthread_t, should be fixed. 2. TThreadHandler (the callback for resume, suspend) has result as DWord while posix stuff (pthread_kill etc.) usualy return cInt 3.

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 10:01, Michael Schnell wrote: > But doing a function call (or hence using a callback) does not change > the thread context you are running in and thus you are still the same > thread. IOW: code lines are not _dedicated_ to a thread context. Oh that, of course. Seem

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
It can't because X-Windows or MS-Windows are not thread-safe. Yeah, right. And threading in DOS is not possible either, because DOS is non-reentrant, is it? You _can_ use threads in an X-Windows, MS-Windows or DOS environment, you just can't do X-Windows, MS-Windows or

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Ales Katona
You can call a callback in same thread, but since you can't ensure what the callback does from your "lib" you can't make it threadsafe in any way. Even if you put the callback itself into a "criticalsection" it might eg: change some variable which was "just in use" by the main thread, and once the

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 10:14, Michael Schnell wrote: > If you take a look the start of this thread, I mentioned that after > implementing Delphi/Lazarus like behavior for the main thread without > the need for a GUI, I'd like to enhance the concept by optionally > having an TApplication obj

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Michael Van Canneyt
On Wed, 8 Nov 2006, Ales Katona wrote: > A cleaner naming of problematic parts: > > 1. TThreadID is defined stand-alone not as a pthread_t, should be fixed. > 2. TThreadHandler (the callback for resume, suspend) has result as DWord > while posix stuff (pthread_kill etc.) usualy return cInt Jus

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
Well, I don't consider it beautiful, I consider it a hack. :) It's beautiful, as the user does not need to care about mutually exclude access of the objects that are used both in the main line code and the timer callbacks. Most "application programmers" would not be able to deal with this

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Micha Nelissen
Michael Van Canneyt wrote: It can't because X-Windows or MS-Windows are not thread-safe. FTR: AFAIK MS WinAPI is thread safe, just don't do stupid things yourself of course (like passing buffers that are going to be messed with by another thread and such). Micha

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Marco van de Voort
> If you take a look the start of this thread, I mentioned that after > implementing Delphi/Lazarus like behavior for the main thread without > the need for a GUI, I'd like to enhance the concept by optionally having > an TApplication object for any thread Not every thread or program is event

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 10:26, Ales Katona wrote: > This is an old problem, and not fixable by wishing it. If you want a > good async. timer, sure make one, but don't expect it to work safely > by magic. I'm sure I won't, I'm paranoid. :) > That's what I ment, it won't simply "just work wi

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Micha Nelissen
Vinzent Hoefler wrote: Maintaining thread-safety ain't so complex once you start following some simple rules. Either you're underestimating thread-safety or you're a genius. Can you document those simple rules on the wiki ? Micha ___ fpc-devel mai

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
But now ... rereading the post, the original text was "You can't just put a TTimer in which works in it's own thread and then calls some callback in it's own thread," and I still wonder why I shouldn't be able to do that (well, if TTimer would actually do what its name suggests and no-one els

Re: [fpc-devel] Bug 0007281 / MemLeak with interfaces

2006-11-08 Thread Martin Schreiber
On Wednesday 08 November 2006 10.25, Jonas Maebe wrote: > On 8 nov 2006, at 06:52, Martin Schreiber wrote: > > But what should we do if we can't use trunk because it is not > > stable and we > > can't use 2.0.4 because it is buggy? > > There will *always* be bugs in the latest release which cause i

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
Sorry, if it caused confusion, ... No problem, taking more ideas as an input is always useful ! Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bug 0007281 / MemLeak with interfaces

2006-11-08 Thread Jonas Maebe
On 8 nov 2006, at 11:47, Martin Schreiber wrote: There will *always* be bugs in the latest release which cause it not to work for some people. If we'd release a 2.0.6, that situation would not change and some of those people would also think that their bug is so important it requires a new rele

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Micha Nelissen
Michael Schnell wrote: the need for a GUI, I'd like to enhance the concept by optionally having an TApplication object for any thread (e.g. TThread.Application) and It shouldn't be named Application, because there is only one application per process. thus having an event scheduler for same.

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
Also I think a base thread should remain free from this. You can of course create a descendant of tthread that is event driven (e.g. messagequeue, pump and list of known events/methodvars in overriden tthread.execute) Right. That is a decent way to do it "optionally" (as I of course would do

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
Separate event scheduler and application. Hint registered and saved in the to-do list :-) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
No, the timer will still be synchronous, only to the current thread's event handler, not to the main (GUI) one. These timers are assigned to a thread. They are synchronous (non-preemptive) regarding their own thread and asynchronous (preemptive) regarding all other threads. So, by accessing

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Michael Schnell
FPC does not decide anything. The pthread library decides this. AFAIK this means that with Kernel 2.4 this will be a Linux process for each thread and with Kernel 2.6 this will be NPTL and thus only one process. So both ways need to be verified to work with the implementations. -Michael

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Micha Nelissen
Michael Schnell wrote: I don't see how async timers can be useful for software It decreases the latency. This is always the reason to do _preemptive_ multitasking. This is not an async timer in the way Vincent meant it, assuming I read his mails correctly. Also, pre-emptive multitasking is di

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
This is not an async timer in the way Vincent meant it, assuming I read his mails correctly. Also, pre-emptive multitasking is different from the async timer as you're explaining here in exactly this detail. An asynchronous timer needs to do a preemptive callback. Preemptive execution needs it

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Micha Nelissen
Michael Schnell wrote: An asynchronous timer needs to do a preemptive callback. No. Preemptive execution needs it's own thread. No. This is a way to provide the timer with a thread. Preemptive means same thread, as it 'preempts' it. That's what a (unix) signal is. That's what Vincent

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Marco van de Voort
> Michael Schnell wrote: > > I don't see how async timers can be useful for software (maybe to > control hardware perhaps, but only the trivial kind as well, no complex > state allowed), as you cannot take any locks, and must be re-entrant. No, not reentrant, unless you use the same event in t

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Jonas Maebe
On 8 nov 2006, at 11:21, Jonas Maebe wrote: Question about #2. Well.. this is a tough nut? I suspect it's because of various threading backends, but we need to handle those -1 properly if nothing else but this implies going over by all used pthread functions and seeing all possible values

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
Micha Nelissen wrote: Michael Schnell wrote: An asynchronous timer needs to do a preemptive callback. No. Ooops ? What is an asynchronous timer according to your definition ? Preemptive execution needs it's own thread. No. Ooops ? What do you think is preemptive ? By definition preempti

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Micha Nelissen
Micha Nelissen wrote: Preemptive means same thread, as it 'preempts' it. That's what a (unix) signal is. That's what Vincent meant (I think). Sorry, "Vinzent", it is. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepa

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 10:53, Micha Nelissen wrote: Sorry for all the confusion, I'm trying to clarify what I actually mean (or what I would *expect* from such a timer object): > I don't see how async timers can be useful for software (maybe to > control hardware perhaps, but only the tri

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Micha Nelissen
Vinzent Hoefler wrote: So, the semantics would be about the same as in a signal (apart from the "softer" timing), but you would have much less restrictions in the handler's implementation compared to a real OS signal, which acts more like an interrupt. Impossible. You'll end with TThread.Sync

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 12:44, Micha Nelissen wrote: > Vinzent Hoefler wrote: > > So, the semantics would be about the same as in a signal (apart > > from the "softer" timing), but you would have much less > > restrictions in the handler's implementation compared to a real OS > > signal, whic

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
There is TCustomApplication in fcl/inc/custapp. The Lazarus TApplication descends from it. All you need to do is create a descendent of TCustomApplication which can implement all the messaging you wish for... I took a look at TCustomApplication. Same does not provide anything that is relate

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Micha Nelissen
Vinzent Hoefler wrote: repeat SysUtils.Sleep (self.Interval); self.Logger.Flush; until self.Terminated; is totally impossible to work? To implement something less crude you It works, but it's not realtime by any definition. Micha ___

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 13:21, Micha Nelissen wrote: > Vinzent Hoefler wrote: > >repeat > > SysUtils.Sleep (self.Interval); > > self.Logger.Flush; > >until self.Terminated; > > > > is totally impossible to work? To implement something less crude > > you > > It works, Oh w

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Van Canneyt
On Wed, 8 Nov 2006, Michael Schnell wrote: > > > There is TCustomApplication in fcl/inc/custapp. The Lazarus TApplication > > descends > > from it. All you need to do is create a descendent of TCustomApplication > > which > > can implement all the messaging you wish for... > > > I took a loo

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
Michael Van Canneyt wrote: TThread.Synchronize does not need to be changed. You can set a series of callbacks (from classes unit) which you can then use to configure the whole synchronize issue... Sounds great ! Seems correct. And all this cross-platform, of course :-) Of course !!! :-)

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Van Canneyt
On Wed, 8 Nov 2006, Michael Schnell wrote: > Michael Van Canneyt wrote: > > TThread.Synchronize does not need to be changed. You can set a series > > of callbacks (from classes unit) which you can then use to configure > > the whole synchronize issue... > > > > > Sounds great ! > > Seems corr

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Micha Nelissen
Vinzent Hoefler wrote: but it's not realtime by any definition. First, I never said "real-time" in that context and second: it sure can I concluded that from your quote: Timing events allow for a handler to be executed at a future point in time in an efficient way, as it is a standalone ti

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 14:43, Micha Nelissen wrote: > Vinzent Hoefler wrote: > >> but it's not realtime by any definition. > > > > First, I never said "real-time" in that context and second: it sure > > can > > I concluded that from your quote: > > > Timing events allow for a handler to be

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
The answer to my "I always thought a timer is more comparable to an interrupt or signal than a polling loop." was "That is a very common misconception." which I still refuse as being a correct answer. I misunderstood that you meant a Delphi TTimer. And I wanted to point out that many Delphi

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Micha Nelissen
Vinzent Hoefler wrote: The answer to my "I always thought a timer is more comparable to an interrupt or signal than a polling loop." was "That is a very common misconception." which I still refuse as being a correct answer. The irony is of course that you clamp to your interrupt definition, bu

[fpc-devel] Request info on static single use

2006-11-08 Thread Bart van den Broek
Can someone give me a reference to static single use (for example scientific paper). I know SSA and SSI (I = information). Thanks --Bart. _ Een eigen webpagina voor foto's en weblog in 2 tellen! http://spaces.live.com _

Re: [fpc-devel] Request info on static single use

2006-11-08 Thread Daniël Mantione
Op Wed, 8 Nov 2006, schreef Bart van den Broek: > Can someone give me a reference to static single use (for example scientific > paper). > I know SSA and SSI (I = information). http://www.freepascal.org/wiki/index.php/Single_assignment Daniël___ fpc-

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Michael Schnell
Your code can perfectly be implemented as an add-on unit, which we can distribute. The first goal I see is that FPC comes with portable support for TTimer and Delphi/Lazarus compatible thread support, that can be used in a GUI-less Application - thus without Lazarus. If that's possible wit

Re: [fpc-devel] Request info on static single use

2006-11-08 Thread Jonas Maebe
On 8 nov 2006, at 17:11, Bart van den Broek wrote: Can someone give me a reference to static single use (for example scientific paper). I know SSA and SSI (I = information). http://www.google.com/search?q=static+single+use First hit (the Google summary even contains all necessary informati

Re: [fpc-devel] Request info on static single use

2006-11-08 Thread Micha Nelissen
Jonas Maebe wrote: On 8 nov 2006, at 17:11, Bart van den Broek wrote: Can someone give me a reference to static single use (for example scientific paper). I know SSA and SSI (I = information). http://www.google.com/search?q=static+single+use Is SSU easier to implement than SSA ? Aren't va

Re: [fpc-devel] Request info on static single use

2006-11-08 Thread Bart van den Broek
All links you gave me lead to SSA, I have gathered quite some documents on the subject. I found one reference in an SSI document to SSU and it was discredited as incomplete (no algorithms) and vague. I thought you found some info i didnt see yet. So i guess you are using SSA? --Bart. Ori

Re: [fpc-devel] Request info on static single use

2006-11-08 Thread Jonas Maebe
On 8 nov 2006, at 17:46, Micha Nelissen wrote: Jonas Maebe wrote: On 8 nov 2006, at 17:11, Bart van den Broek wrote: Can someone give me a reference to static single use (for example scientific paper). I know SSA and SSI (I = information). http://www.google.com/search?q=static+single+use

Re: [fpc-devel] Request info on static single use

2006-11-08 Thread Jonas Maebe
On 8 nov 2006, at 17:58, Bart van den Broek wrote: All links you gave me lead to SSA, No. The first google hit is a wikipedia article about SSA, but contains a subsection about SSU. I have gathered quite some documents on the subject. I found one reference in an SSI document to SSU and i

Re: [fpc-devel] Request info on static single use

2006-11-08 Thread Bart Hotmail
No. The first google hit is a wikipedia article about SSA, but contains a subsection about SSU. Ah found it (but no articles/reports that compares it with SSA). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mai

Re[2]: [fpc-devel] Request info on static single use

2006-11-08 Thread Пётр Косаревский
> Ah found it (but no articles/reports that compares it with SSA). There are some bibliographies: http://www.cs.man.ac.uk/~irogers/SSA.xhtml and http://www.cs.man.ac.uk/~jsinger/ssa.html (with comments). (However, to view some articles you must have subscription.) ___

Re: [fpc-devel] Request info on static single use

2006-11-08 Thread Vincent Snijders
Jonas Maebe schreef: On 8 nov 2006, at 17:46, Micha Nelissen wrote: Is SSU easier to implement than SSA ? No, it's a bit more work. Aren't variables often more used than assigned (so more generated variables by SSU) ? Yes. How do the achieved optimizations compare ? SSU gives somewh

Re: [fpc-devel] Request info on static single use

2006-11-08 Thread Jonas Maebe
On 08 Nov 2006, at 20:13, Vincent Snijders wrote: Will you be working on SSA and/or SSU with control blocks (e.g. using SSA in procedures where a for loop is used) before 2.2? Or will that be released only in a later version. Later. But maybe Florian will work on it earlier. Jonas __

Re: [fpc-devel] Request info on static single use

2006-11-08 Thread Florian Klaempfl
Jonas Maebe schrieb: On 08 Nov 2006, at 20:13, Vincent Snijders wrote: Will you be working on SSA and/or SSU with control blocks (e.g. using SSA in procedures where a for loop is used) before 2.2? Or will that be released only in a later version. Later. But maybe Florian will work on it ear

Re: Re[2]: [fpc-devel] Request info on static single use

2006-11-08 Thread Bart Hotmail
(However, to view some articles you must have subscription.) Which is also my problem ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Ales Katona
> Just define an opaque type TThreadResult: > > TThreadResult = DWord // Windows > > TThreadResult = cInt // Unices > I don't like this solution for several reasons: 1. What if one OS has more backends for threading available, which differ in this? 2. How are we going to handle error state

Re: [fpc-devel] CSuspendThread/CResumeThread

2006-11-08 Thread Michael Van Canneyt
On Wed, 8 Nov 2006, Ales Katona wrote: > > > Just define an opaque type TThreadResult: > > > > TThreadResult = DWord // Windows > > > > TThreadResult = cInt // Unices > > > I don't like this solution for several reasons: > > 1. What if one OS has more backends for threading available, which >

[fpc-devel] lNet telnet

2006-11-08 Thread Ales Katona
Whoever first told me about bad input from lNet telnet example, could you please try again to see if it still persists? I did some fixes related to input and certain telnet commands recently which might fix it. Thanks (sorry I forgot who it was and deleted the mail since then) Ales

Re: [fpc-devel] Math.DivMod results should be signed

2006-11-08 Thread k
I just read your posting on Delphi's DivMod. It doesn't work very well, not on LongInt (Integer) values and negatives, not on Delphi 6, that I'm using, anyway. I wrote an alternative that handles LongInt and negatives. It takes only Integer parameters. It's a function, rather than a procedure

Re: [fpc-devel] Math.DivMod results should be signed

2006-11-08 Thread Florian Klaempfl
> function DivWithRemainder(Value, Divisor: Integer; var Remainder: Integer): > Integer; > { >In: > EAX = Value > ECX = @Remainder > EDX = Divisor > >Out: > EAX = Result > ECX = @Remainder > } > asm > PUSH EBX { Save EBX - this register is not f

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 16:08, Micha Nelissen wrote: > Vinzent Hoefler wrote: > > The answer to my "I always thought a timer is more comparable to an > > interrupt or signal than a polling loop." was "That is a very > > common misconception." which I still refuse as being a correct > > answer

Re: [fpc-devel] Math.DivMod results should be signed

2006-11-08 Thread Daniël Mantione
Op Thu, 9 Nov 2006, schreef Florian Klaempfl: > Is this really faster than using CDQ? At least on RISC86 CPU's, CDQ is a fast directpath instruction. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/

Re: [fpc-devel] Math.DivMod results should be signed

2006-11-08 Thread Florian Klaempfl
Daniël Mantione schrieb: > > Op Thu, 9 Nov 2006, schreef Florian Klaempfl: > >> Is this really faster than using CDQ? > > At least on RISC86 CPU's, CDQ is a fast directpath instruction. That's why I'am asking :) ___ fpc-devel maillist - fpc-devel@li