Re: [fpc-devel] Re: Porting FPC to IBM zArch
Am 19.08.2013 06:00, schrieb Paul Robinson:
I've been busy, I have other things I had to attend to, then I
realized I couldn't figure out what was going on without a decent
cross reference program, but nothing that's out there supports the
UNIT construct, nor do they know how to skip over {$DEFINE} {$IF}
{$ELSE}, and so I stopped to write one and I was busy with the work on
that. I'm having trouble there, so I set it aside.
I don't get what you're trying to say here.
Anyway, I came back and realized if I can get one of the Big Endian
ports working I can just figure out what files it uses and then edit
those to change the generated assembly language and/or the object
files if it makes object files the way the Pascal 8000 compiler for
the 370 from the Australian Atomic Energy Commission did back in the
late 1970s and early 1980s did.
Analyzing what a big-endian compiler generates won't help you there. You
need to look into the compiler's code and learn how it does generate
code for a specific platform. That has nothing to do with big endian or
little endian.
In FPC there is the frontend which generates a sort of abstract syntax
tree on which then the platform specific backend generates code. Thereby
the backend provides platform specific nodes for that abstract syntax
tree of which then the generate_code method is invoked. Platform
independant stuff is normally located in the ncg*.pas units and the
platform specific stuff is in the nXY*.pas unit of the corresponding CPU
directory where XY is a short form of the CPU, e.g. n68kadd.pas for the
m68k add/compare node. Best is you look how other CPUs are implemented
(prefereably the simpler ones like MIPS or m68k) and copy that more or
less for the new platform.
Adding a new platform to FPC is not cheesecake and you should know how
the compiler's backend work. Just looking at the output of a target
won't help you!
There are two things I'd like to find out to determine how it might be
possible to get Free Pascal ported to the s370 series.
First, I want to add some of the compiler flags I mention in the
description of my attempts on the WIKI to add the s370 and/or zSystem
architecture, how do I get those flags - they do not break the build -
added as hooks to the compiler sources so that eventually a {$DEFINE
S370} statement can be added to get the compiler to build itself for
the 370 (and possibly other defines depending on the machine and OS
target}? There will eventually need a new directory for the files that
the 370 and whatever OSs it uses supports, but, again, that's months
away. I have to start over, and I have to start somewhere.
First step is to get a cross compiler to s370/zSystem working so that
simple programs can be compiled which you can use to implement the RTL.
Only when enough of the RTL is implemented and the code generator works
good enough then you can try to cross compile the compiler, but not earlier.
So how would I get the constants and values added to include the s370
as a target for FPC? Would I submit them as a bug fix request as a
patch through bugs.freepascal.org on Mantis or something else? I want
to reserve a definition number for that processor, at least for now so
it has a fixed identifier so eventually it can have its own PPU files
and everything else in the toolchain.
Search the compiler's source for e.g. m68k to see how other platforms
are implemented.
Second, how do I create a cross-compiler that runs on Windows, for any
of the big-endian processors, so that I can see what it has to
generate code for the target machine? Given that, I can change the
code to either change the generated object file - if it does direct
object files - or the assembly language so it generates S370 assembly.
No. You should learn how the compiler generates code and then implement
a new code generator backend for s370, maybe based on a copy of another
platform. Playing around with the output won't help you.
I can then run the compiler through itself to create a cross-compiler
assembly for the 370. Then I can recompile the required modules, then
take the assemblies, assemble them with a 370 assembler, producing an
actual object module, then run the program against itself and the
compiler will at least compile itself. Having done that, I can then
create any necessary changes to implement anything needed to provide
the equivalent functionality and rebuild the toolchain so it is native
to the s370 and units to provide localized services can be created as
needed.
First step consists of cross compiled hello world programs to implement
and test the RTL. The compiler is much too complicated to get it running
at first.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TCustomApplication
Hi Experts. Since ages I am searching for an easy method to do normal (i.e. event driven) Pascal programming using Lazarus as an IDE and targeting headless embedded devices (with no GUI hardware and/or GUI software infrastructure). I understand that the fpc RTL already provides TCustomApplication (while Lazarus creates descendants from same to do Lazarus Applications - of several kinds, definable by Lazarus WidgetTypes - in the LCL). Now, unfortunately, there is no predefined WidgetType that out of the box allows for event driven programming using normal stuff like TTimer, TThread.Synchronize, TThread,Queue, and Application.QueuAsnycCall without forcing a GUI binding (while all this seems to be possible with mseide). In fact some years ago I tried to create an LCL Widget Type like that, using the Lazarus Way, but failed due to the complexity of the LCL. I understand that (without using the LCL at all), in the RTL, it is possible to do e.g. an Application that provides at least one timer (see testtimer.pp) or things like a DaemonApplication (see daemonapp.pp). At least the DaemonApplication seems to auto-adapt to Linux or Windows while being compiled. But here it seems, the application programmer needs to dedicatedly tailor his code for a very special kind of application himself. Is there (or would it be viable to have in an LCL-independent package) a more general TCustomApplication descendant such as TApplication or similar, that (auto-adapting to Linux and Windows when being compiled) provides TTimer, TThread.Synchronize, TThread,Queue, and Application.QueuAsnycCall, while allowing for decent event driven programming ? Here a decent (OS-dependent) mechanism needs to be implemented to notify the main thread of timer and Thread generated events so that it is able to try to fetch the next event from the queue as soon as possible after (and only when) at least one has been generated. I would happily try to do something like that myself, but at least for the rest of this year I will not find the time :( . But as this thought comes in my mind, I now try to collect information on this issue. Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On Mon, 19 Aug 2013, Michael Schnell wrote: Hi Experts. I would happily try to do something like that myself, but at least for the rest of this year I will not find the time :( . But as this thought comes in my mind, I now try to collect information on this issue. I am having a déjà vu :-) I have told you many years ago on these very mailing lists that what you need to do is create a TCustomApplication descendant which implements a simple event loop. This can be done based on libevent, fpasync, lnet, glib event loop, dbus or some other custom-made mechanism. If memory serves me well, MSEGUI contains such an event loop descendent using a custom made mechanism. There is nothing magical about such an application. Basically, it watches one or more file descriptors (object handles in windows-speak) for changes, using a timeout, and triggers some event handler when something happens. It calls checksynchronize from time to time. That's it. It should not take more than an hour to implement. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On Monday 19 August 2013 11:28:25 Michael Van Canneyt wrote: It should not take more than an hour to implement. Maybe some additional minutes for the implementation of an efficient and precise timer queue. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On 08/19/2013 11:28 AM, Michael Van Canneyt wrote: I am having a déjà vu :-) Yep. But at that time I (maybe completely erroneously) decided to do this as an LCL Widget Type as I had extensions in mind that would fit just there (such as stuff based on ExtPascal or mse-ifi). If memory serves me well, MSEGUI contains such an event loop descendent using a custom made mechanism. Of course. In fact I understand that any LCL Widget Type does this, too. There is nothing magical about such an application. Basically, it watches one or more file descriptors (object handles in windows-speak) for changes, using a timeout, and triggers some event handler when something happens. It calls checksynchronize from time to time. That's it. It should not take more than an hour to implement. In fact I do know this. If I would have a current practical project to do, I of course would do this right away, but (as always) I am doing just researching and groundwork for future projects. So - if I would start doing anything on that behalf - I would do something with as wide reach as possible: providing (at least) all of TTimer, TThread.Synchronize, TThread,Queue, and Application.QueuAsnycCall, as well for Linux and for Windows in a ready to use way (including documentation). In fact the cause why this becomes more prominent for me right now is that since some time TThread.Queue is provided in the rtl (in fact on my request and happily implemented by very knowledgeable supporters like yourself) and thus I feel that in a similar way TTimer and Application.QueuAsnycCall would be doable. -Michael (known as the weird mind) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On 08/19/2013 11:51 AM, Martin Schreiber wrote: Maybe some additional minutes for the implementation of an efficient and precise timer queue. ;-) _MANY_ thanks for the support, making me feel that I am not completely insane. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] z370 Cross Compilation, Pass 2 of ....
Based on information and belief, on Mon, 19 Aug 2013 10:37:43 +0200, Sven Barth pascaldra...@googlemail.com wrote to the Free Pascal list: I don't get what you're trying to say here. I mean I spent the better part of a year writing a cross-reference tool for Free Pascal since the compiler doesn't include one as they used to do (Mainframe and minicomputer Cobol, Fortran and Assembler all have built-in cross-reference as part of the compiler/assembler), then I had problems implementing a piece of it, so I realized that I'll come back to it at some time later, and right now I want to go back and try again with Free Pascal since I now know what I need to tackle. When I wasn't sure how to ask for what I knew I needed, I set this request aside to work on the cross-reference. I had to figure out what was going on and what I had to do. Analyzing what a big-endian compiler generates won't help you there. Possibly, but I have to start somewhere. You need to look into the compiler's code and learn how it does generate code for a specific platform. That has nothing to do with big endian or little endian. It does if the compiler generates object files directly (the way Pascal 8000 did on the 370, UCSD did, and Delphi does). If the compiler generates assembly language source files (the way OMSI Pascal did on the PDP-11 and the National Bureau of Standards Pascal Compiler did), then no, endianness probably won't matter. But I don't know from direct examination which FPC does, it's a huge application and I have no idea what all 100+ units and 264,000 lines of code do. I have to start somewhere and I have to take a guess. There are three possibilities. (I don't care what FPC does when it scans the program; that's all magic I probably don't have to worry about or deal with right now.) (1) The compiler, when it generates code, generates an intermediate output file processed by something else (Stanford Pascal, P4, P5, Java Compilers). (2) The compiler, when it generates code, generates an assembly language file (or possibly some other language) for the target that is passed to the Assembler (OMSI Pascal for the PDP-11). (3) The compiler, when it generates code, generates an actual object file and/or an executable (Pascal 8000, Turbo Pascal, Microsoft Pascal, Delphi). I know not which of these three Free Pascal does. Platform independant stuff is normally located in the ncg*.pas units and the platform specific stuff is in the nXY*.pas unit of the corresponding CPU directory where XY is a short form of the CPU, e.g. n68kadd.pas for the m68k add/compare node. Best is you look how other CPUs are implemented (prefereably the simpler ones like MIPS or m68k) and copy that more or less for the new platform. My spell checker says you spelled independent and preferably worng. :) Yeah, and I still have to figure out what compiler switches to set to enable the existing compiler to create a cross-compiler for that target that runs on Windows, and I'm asking for help on that point, because I figure someone might be able to tell me in 10 words which switches I need. The documentation is rather sparse on cross-compiling and the code is, well, to say the least, not very forthcoming. Adding a new platform to FPC is not cheesecake I'm fully aware of this, I'm not stupid and this is not the first compiler I've worked on, just the largest. I've written patches to six different Pascal compilers and I've written two compilers from scratch (not for Pascal), one was a Fortran IV to Visual Basic translator written in 7,000 lines of VB5, the other was a compiler I needed for a different purpose. I'm not someone who just fell off the turnip truck. I know there's (a lot of) work involved. I have to take a guess on where to start. Given an existing implementation, that I actually get it to work, I can then figure out what is being done, and from that, then I can figure out what files are being used and/or called, and what procedures/methods are invokes. And that's what I'm asking for help. What do I do to get one of the existing compilers that generates code for some other machine to run on Windows and when fed itself, have it generate an output file of the generated code of itself for that machine? Given that, I can then figure out what to look for. and you should know how the compiler's backend work. Just looking at the output of a target won't help you! It will a little. Seeing what is generated means I can look in the source code for where that is generated from, sort of the way the NSA, if it thinks you're calling a terrorist, it can search the billions of phone records it secretly seized to see who else you called! Given the generated output, I can (presumably) trace it back to whatever program file generated it and thus figure out what files were used. Going further, if necessary, I can insert procedure or unit traces on those files and see
Re: [fpc-devel] TCustomApplication
On Mon, 19 Aug 2013, Michael Schnell wrote: On 08/19/2013 11:28 AM, Michael Van Canneyt wrote: I am having a déjà vu :-) Yep. But at that time I (maybe completely erroneously) decided to do this as an LCL Widget Type as I had extensions in mind that would fit just there (such as stuff based on ExtPascal or mse-ifi). If memory serves me well, MSEGUI contains such an event loop descendent using a custom made mechanism. Of course. In fact I understand that any LCL Widget Type does this, too. There is nothing magical about such an application. Basically, it watches one or more file descriptors (object handles in windows-speak) for changes, using a timeout, and triggers some event handler when something happens. It calls checksynchronize from time to time. That's it. It should not take more than an hour to implement. In fact I do know this. If I would have a current practical project to do, I of course would do this right away, but (as always) I am doing just researching and groundwork for future projects. So - if I would start doing anything on that behalf - I would do something with as wide reach as possible: providing (at least) all of TTimer, You may need to do ttimer if you need that. TThread.Synchronize, TThread,Queue, and Application.QueuAsnycCall, as well for Linux and for Windows in a ready to use way (including documentation). YOU DO NOT NEED TO DO THIS. Just implement the loop and let it call CheckSynchronize at regular intervals. All the rest will be done for you. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On 08/19/2013 01:47 PM, Michael Van Canneyt wrote: YOU DO NOT NEED TO DO THIS. Just implement the loop and let it call CheckSynchronize at regular intervals. All the rest will be done for you. Did you ever do embedded software ? The result of the event in the main queue is not having something displayed to a human, but may be a command to the attached machine, which might be really fast. Thus regular polling is an absolute no-go here. Doing the polling slow results in huge latency regarding the events. Doing the polling fast results in a huge processor overhead and thus in a huge overhead regarding anything else that the CPU is supposed to do. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On Monday 19 August 2013 11:55:37 Michael Schnell wrote: On 08/19/2013 11:51 AM, Martin Schreiber wrote: Maybe some additional minutes for the implementation of an efficient and precise timer queue. ;-) _MANY_ thanks for the support, making me feel that I am not completely insane. BTW, why don't you simply use MSEgui which provides all this out of the box instead to constantly annoy FPC and Lazarus people? ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On Mon, Aug 19, 2013 at 02:03:11PM +0200, Michael Schnell wrote: On 08/19/2013 01:47 PM, Michael Van Canneyt wrote: YOU DO NOT NEED TO DO THIS. Just implement the loop and let it call CheckSynchronize at regular intervals. All the rest will be done for you. Did you ever do embedded software ? The result of the event in the main queue is not having something displayed to a human, but may be a command to the attached machine, which might be really fast. Thus regular polling is an absolute no-go here. Doing the polling slow results in huge latency regarding the events. Doing the polling fast results in a huge processor overhead and thus in a huge overhead regarding anything else that the CPU is supposed to do. You don't need to poll. Just make sure that you assign and implement WakeMainThread (classes.pp). When Synchronize() is called, it will check if WakeMainThread is assigned and call it. This will wake up your main loop and you can then call CheckSynchronize(). How you implement WakeMainThread will depend on your event loop mechanism. A simple way to do this is with the self-pipe trick. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
Am 19.08.2013 13:47, schrieb Michael Van Canneyt: TThread.Synchronize, TThread,Queue, and Application.QueuAsnycCall, as well for Linux and for Windows in a ready to use way (including documentation). YOU DO NOT NEED TO DO THIS. Just implement the loop and let it call CheckSynchronize at regular intervals. All the rest will be done for you. (Except QueueAsyncCall which is only implemented in the LCL's TApplication and is not triggered by CheckSynchronize) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On 08/19/2013 02:21 PM, Martin Schreiber wrote: BTW, why don't you simply use MSEgui which provides all this out of the box instead to constantly annoy FPC and Lazarus people? ;-) (We already did discuss this years ago ;-) . I do hope that just asking a question each year is not too annoying) I am (supposedly) not going to a use anything to do any real applications at all, but I am doing some groundwork to help my colleagues to port some of their Delphi stuff to Linux. I am quite sure that I will not be able to have the 30 years Delphi users switch to mse, but some hope remains to talk them into using Lazarus. Right now, there is news by Embarcadero that the next version of Delphi will support doing native ARM application on Android devices. Thus Linux _is_ going to be supported somehow. But here they would need to switch to FireMonkey. This might be close to impossible, again, while the LCL is much closer to the legacy Delphi VCL. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On 08/19/2013 02:27 PM, Henry Vermaak wrote: How you implement WakeMainThread will depend on your event loop mechanism. A simple way to do this is with the self-pipe trick. Of course this is exactly what I have in mind. (But as said, I am doing nothing but groundwork research and don't have an actual application in mind. Thus if I am going to do anything it would need to be only be useful it it is widely usable for a greater class of applications. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On 08/19/2013 02:29 PM, Sven Barth wrote: (Except QueueAsyncCall which is only implemented in the LCL's TApplication and is not triggered by CheckSynchronize) ...and (AFAI understand) TTimer is not implemented at all. I suppose both events can be implemented similar to TThread.Queue. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On Mon, 19 Aug 2013, Michael Schnell wrote: On 08/19/2013 01:47 PM, Michael Van Canneyt wrote: YOU DO NOT NEED TO DO THIS. Just implement the loop and let it call CheckSynchronize at regular intervals. All the rest will be done for you. Did you ever do embedded software ? Yes. The result of the event in the main queue is not having something displayed to a human, but may be a command to the attached machine, which might be really fast. Thus regular polling is an absolute no-go here. Doing the polling slow results in huge latency regarding the events. Doing the polling fast results in a huge processor overhead and thus in a huge overhead regarding anything else that the CPU is supposed to do. So what ? That's a detail of the event loop. It has nothing to do with the mechanism of threads. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On 08/19/2013 02:35 PM, Michael Van Canneyt wrote: So what ? That's a detail of the event loop. My comment was not regarding event loop but regarding regular intervals. If you implement an event loop that does not do turns on regular intervals but only when it gets tickled by the event generating Thread or timer. I am of course fine. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On Mon, 19 Aug 2013, Michael Schnell wrote: On 08/19/2013 02:35 PM, Michael Van Canneyt wrote: So what ? That's a detail of the event loop. My comment was not regarding event loop but regarding regular intervals. If you implement an event loop that does not do turns on regular intervals but only when it gets tickled by the event generating Thread or timer. I am of course fine. I will not implement anything, you will :) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On 08/19/2013 02:48 PM, Michael Van Canneyt wrote: I will not implement anything, you will :) Right you are :-) . I sincerely hope I once will find the time to do this, now that we TThread.Queue which proves that it in fact is possible. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
Michael Schnell schrieb: So - if I would start doing anything on that behalf - I would do something with as wide reach as possible: providing (at least) all of TTimer, TThread.Synchronize, TThread,Queue, and Application.QueuAsnycCall, as well for Linux and for Windows in a ready to use way (including documentation). Now that you mention it, a new TApplication type would be a good choice. From D7 help: TServiceApplication encapsulates a Windows NT service application. Unit: SvcMgr DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On 08/19/2013 02:27 PM, Henry Vermaak wrote: A simple way to do this is with the self-pipe trick. I suppose in Windows we would use a message. In Linux I would prefer a semaphore or - supposedly best if really usable here - pthread.mutex as same uses FUTEX whenever the underlying arch allows for and thus the overhead is as small as possible, because there is no OS call necessary when scheduling an event and when an event is already scheduled at the time the previous is done. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On Mon, Aug 19, 2013 at 03:49:53PM +0200, Michael Schnell wrote: On 08/19/2013 02:27 PM, Henry Vermaak wrote: A simple way to do this is with the self-pipe trick. I suppose in Windows we would use a message. In Linux I would prefer a semaphore or - supposedly best if really usable here - pthread.mutex as same uses FUTEX whenever the underlying arch allows for and thus the overhead is as small as possible, because there is no OS call necessary when scheduling an event and when an event is already scheduled at the time the previous is done. That makes no sense. How do you suppose that a mutex in linux will wake up an event loop? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On 08/19/2013 04:31 PM, Henry Vermaak wrote: How do you suppose that a mutex in linux will wake up an event loop? The mutex gets taken before the loop is started. Now the loop blocks when taking it. It is freed whenever an event is scheduled. Whether or not a mutex blocks when the same thread tries to take it that already owns it and whether a thread that does not own it can free it, is an implementation detail that here of course needs to be taken into account. (I once did a Mutex implementation that did block on re-take, but AFAIK there are different implementations.) AFAIR the FUTEX system call (that is not a MUTEX itself, but only helps to implement one in user space) allows for doing this. But I don't know what in detail pthread.mutex does in detail. (Anyway, I'll be doing a research on those details when I in fact should do an Application implementation that needs it.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On Mon, Aug 19, 2013 at 04:43:52PM +0200, Michael Schnell wrote: On 08/19/2013 04:31 PM, Henry Vermaak wrote: How do you suppose that a mutex in linux will wake up an event loop? The mutex gets taken before the loop is started. Now the loop blocks when taking it. It is freed whenever an event is scheduled. So, only one event can ever wake up your even loop? I usually use select() or epoll(). I'm looking forward to seeing your implementation, though. However, judging by how long you've been talking about this, I think I'll be retired by then. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On 08/19/2013 08:45 AM, Michael Schnell wrote: On 08/19/2013 02:48 PM, Michael Van Canneyt wrote: I will not implement anything, you will :) Right you are :-) . I sincerely hope I once will find the time to do this, now that we TThread.Queue which proves that it in fact is possible. I'm enjoying this thread (one of my favorites every year :) ) and I am glad to learn that things are progressing! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Porting FPC to IBM zArch
Am 19.08.2013 10:37, schrieb Sven Barth: Adding a new platform to FPC is not cheesecake and you should know how the compiler's backend work. Just looking at the output of a target won't help you! A good start is aarch64: I tried to work in it as structured as possible to make it some draft for porting, so have a look at the history of fpc/compiler/aarch64 so you know how to start. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
