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
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] 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 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 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 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
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: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
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: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 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: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 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: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
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 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
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 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 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
[fpc-devel] z370 Cross Compilation, Pass 2 of ....
Based on information and belief, on Mon, 19 Aug 2013 10:37:43 +0200, Sven Barth 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 what proc
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
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 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 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
[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] 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