Re: [fpc-devel] Why is FPC so self-contained ?
On Tue, 4 Nov 2008, Michael Schnell wrote: AFAIK FPC works quite similar, but while only the parser really knows about the programming language, it comes with it's own preprocessor (which is only used optionally), it's own code generator and it's own linker. AFAIK, it even provides it's own make to compile multiple files. This last is not correct. it's regular make. I could imagine a system that only provides a Pascal-to-RTL-parser and uses many of the GNU tools (preprocessor optionally, optimizer, code generator, linker, make). This would just provide another language for GCC and for hopefully allow me to use FPC-Pascal for any processor architecture supported by GCC. Are there other than historical reasons that FPC is this self-contained ? (I suppose compiling speed is an issue here, so a GCC compatible parser might only be an additional tool provided by the FPC team, but I'd really love to use this for my embedded projects.) We don't want to depend on the work of other people. Do do what you want would also mean that the RTL depends on libc, and this is totally out of the question. What you want is done by GPC and p2c. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
Op Tue, 4 Nov 2008, schreef Michael Schnell: Are there other than historical reasons that FPC is this self-contained ? (I suppose compiling speed is an issue here, so a GCC compatible parser might only be an additional tool provided by the FPC team, but I'd really love to use this for my embedded projects.) Speed is an issue, but not the main reason. Using GCC's backend is difficult, reasons are it is a moving target and because it doesn't necessarily implement the features we need, many of our features, like resourcestring tables, require heavy support from the code generator. Another reason is that GCC is written in C, and the code is hard to understand for an outsider. I prefer coding in Pascal, and I understand the architecture of FPC. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
In our previous episode, Michael Schnell said: While I do all PC projects (for Windows and Linux) in Object Pascal, which is my favorite programming language as it offers the best productivity and the lowest count on errors that show at runtime, I am forced to use GCC for the embedded projects as the processors used here (usually 68K, PIC and NIOS) are not supported by FPC. Correct. Now I just took a somewhat deeper look at how the new 4.x versions of GCC work and so the question comes up (again) why I can't use FPC for the embedded software tasks. Because you haven't ported FPC to those architectures yet. GCC uses the preprocessor and the parser to create an intermediate code (RTL: Generic or Gimple). This process is independent from the target-architecture the code is to be compiled for (... in a between coffees first order design sketch... Better check that this also really the case in practice) I could imagine a system that only provides a Pascal-to-RTL-parser and uses many of the GNU tools (preprocessor optionally, optimizer, code generator, linker, make). Are there other than historical reasons that FPC is this self-contained ? It started out on Dos, not Unix, and the early gcc's were pretty unusable. At least I heard Florian say that once (and I can imagine) Actually, using gcc on windows is still ackward to this day. Keep in mind that you would have to maintain your own ecosystem of all those tools on Windows. Moreover, gcc is a moving target that goes through a major restructure every few years. Keeping up is a chore. (see the many discussions on the GPC list about moving to newer versions). While the basic concept parser-IL-binary code remains the same, the border conditions don't. Moreover, adding an additional architecture to such fpc-gcc hybrid might still be a lot work, because of specific things in that architecture that need to be fixed, worked around etc. (I suppose compiling speed is an issue here, so a GCC compatible parser might only be an additional tool provided by the FPC team, but I'd really love to use this for my embedded projects.) If I had to point a finger, then the handling and supportability is the main reason. If I want to use a compiler, I want to use simply a compiler, not a construction kit with twenty tools ranging from a generator to query my system to a linker. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
On 04 Nov 2008, at 10:01, Michael Schnell wrote: I could imagine a system that only provides a Pascal-to-RTL-parser and uses many of the GNU tools (preprocessor optionally, optimizer, code generator, linker, make). FPC-generated object files can already be integrated with the GNU linker and make. A preprocessor has no place anymore (optional or not) once you have parsed and generated some form of intermediate code. Running a C preprocessor on the initial Pascal code could create quite unexpected errors, since the tokens recognised by the C preprocessor have no special meaning in Pascal and can thus appear anywhere. As for using the gcc code generators and optimisers: gcc's ability to use gimple as input is quite new (can it actually already do that? afaik it's still a work-in-progress as part of its whole program optimisation infrastructure). Before that, to use the rest of the gcc infrastructure you would have to integrate the gcc backend into your compiler (as gpc has done). That really is an enormous job and requires constant updating every time a new gcc version is released. Are there other than historical reasons that FPC is this self- contained ? (I suppose compiling speed is an issue here, so a GCC compatible parser might only be an additional tool provided by the FPC team, but I'd really love to use this for my embedded projects.) The main reasons are 1) all people working on FPC are primarily Pascal programmers, and hence prefer programming in Pascal 2) a number of FPC's core developers are very averse to external dependencies for various reasons Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
In our previous episode, Michael Van Canneyt said: Are there other than historical reasons that FPC is this self-contained ? (I suppose compiling speed is an issue here, so a GCC compatible parser might only be an additional tool provided by the FPC team, but I'd really love to use this for my embedded projects.) We don't want to depend on the work of other people. Do do what you want would also mean that the RTL depends on libc, and this is totally out of the question. I'm not too fond of linking in libc, but IMHO dealing with the whole ecosystem of tools and binaries and emulation layers on major platforms as windows to just make proper releases would be my biggest fear. Not that I couldn't handle it, but to package it transparantly to users in the hope that it will actually work. GPC never even got to that stage. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
Marco and all others: Thanks, all points taken, another dream down the drain :(. So the only future option I am still intending to take one day is doing a NIOS code generator for FPC. Though since some time there is a concurrent concept: you now can buy (!) a CLR (they say .NET) - framework for the NIOS. Using Oxygen/Prism there might be a reasonable path to port Delphi software to the embedded device. Still quite far-fetched as well, but sounds interesting. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
On 04 Nov 2008, at 10:30, Michael Schnell wrote: Thanks, all points taken, another dream down the drain :(. I am personally (every now and then) working on an FPC backend that emits llvm code. Llvm has been designed from the ground up to take some form of intermediate code as input and as a generic backend for other compilers. It's still quite young as a project and does not yet support as many targets as gcc, but it is evolving and improving very quickly. See http://llvm.org for more info. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
In our previous episode, Bernd Mueller said: Marco van de Voort wrote: So the main reason for using HW as much as possible is to keep the actual uc free as much as possible for other tasks. yes, this is why I consider to use an ARM7 controller in front of an ARM9 (Linux) controller, although the ARM9 should have the power to handle my realtime stuff. Can't you simply get an ARM with some of the relevant hardware integrated? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
On Tue, Nov 4, 2008 at 8:04 AM, Michael Schnell [EMAIL PROTECTED] wrote: I did not have many hope for really using Pascal on the PIC If you google for: pic pascal compiler There are plenty of options. I am using mikroPascal, and it's an excelent choice: http://www.dontronics-shop.com/mikroelektronika-pascal-compiler-for-pic.html Similarly there are lot's of Pascal compilers for other embedded platforms. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
Michael Schnell wrote: which system/vendor did you choose? We are going to design some controller boards with Altera Cyclone III FPGAs. The NIOS processor is optimized for this FPGA architecture, is very easily implemented into the HDL design, offers acceptable features How big is the implementation? In LUTs, FFs, BlockRAMs? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
What you want is done by GPC and p2c. Do you suggest they offer the rich Object Pascal language that FPC has ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
If you google for: pic pascal compiler There are plenty of options. I am using mikroPascal, and it's an excelent choice: http://www.dontronics-shop.com/mikroelektronika-pascal-compiler-for-pic.html Thanks a lot for the pointers ! -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
Felipe Monteiro de Carvalho schrieb: On Tue, Nov 4, 2008 at 8:10 AM, Marco van de Voort [EMAIL PROTECTED] wrote: Well, I gave up PIC24 since they don't contain motorcontrol, I've always wanted to know what does a microcontroller with motorcontrol is supposed to do different from a normal microcontroler? Having PWM by setting simply some registers and hardware controlled dead times in the bridge circuits makes your programs much more simpler and robust. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
In our previous episode, Felipe Monteiro de Carvalho said: Well, I gave up PIC24 since they don't contain motorcontrol, I've always wanted to know what does a microcontroller with motorcontrol is supposed to do different from a normal microcontroler? I mean, to drive a stepper motor, for example, you just need 4 or 5 output pins from any microcontroller and a darlington driver to deacoplate and power up. True. Note: that we typically use a PIC print as a realtime device between our vision PC, and the clients systems (PLC's and I/O signals). This because most of the customers PLCs are old and/or have high cycle times, but came with the machinery, so can't be replaced easily. If you uc only has one function, you could try to do that. But we have multiple functions, and several might need a quite high speed IRQ. (currently up to 50KHz), and still do other stuff. Reliability is also a point. Using the motorcontrol (and other on PIC hw) saves on high speed IRQ and/or load in the uc's main loop, making those free for other, more custom purposes. We don't typically use the motor control to control motors, but to get quadrature encoder input. Typically 10-25KHz, but higher values have happened. Sometimes we have additional quadrature encoders on ordinary pins (after exhausting the one or two hw ones) So the main reason for using HW as much as possible is to keep the actual uc free as much as possible for other tasks. It is not that much that you couldn't stuff it all on a slower one manually, but more the validation required for that if something is added, which often can only be done when hooked up to the customers hardware etc etc. And we only deliver one uc per machine, and the BOM lists among others several 2000 euro cameras. So 3 or 4 euro more to go from a basic PIC24 to the topmodel dspic doesn't really hurt. The pain is more in making the prints and adding the components to them. Besides (sometimes several) motorcontrols, the dspics are also faster, up to 40MHz (at least before the most recent roadmap) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
But they do their job as you ask it... The job I am asking for is porting Delphi software to different CPU architectures. If the tool level is not as high as FPC can provide, I can redo the code in C as just as well. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
Marco van de Voort wrote: In our previous episode, Bernd Mueller said: Marco van de Voort wrote: So the main reason for using HW as much as possible is to keep the actual uc free as much as possible for other tasks. yes, this is why I consider to use an ARM7 controller in front of an ARM9 (Linux) controller, although the ARM9 should have the power to handle my realtime stuff. Can't you simply get an ARM with some of the relevant hardware integrated? the ARM9 has most of the relevant hardware integrated. The unknown factor for me is to deal with Linux (which is required for the project). Writing kernel driver (at DMA/interrupt level) is certainly doable, but I fear the problems I could get with this approach since I am relatively new to ARM-Linux. If things go well, I still can later remove the ARM7. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
Marco van de Voort wrote: So the main reason for using HW as much as possible is to keep the actual uc free as much as possible for other tasks. yes, this is why I consider to use an ARM7 controller in front of an ARM9 (Linux) controller, although the ARM9 should have the power to handle my realtime stuff. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
llvm is interresting to say the least. I experimented with it a bit but never got to do anything serious. A llvm backend is surely doable especially if you can get an AST out of FPC. -- Aleš Katona [EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
On 04 Nov 2008, at 10:56, Michael Schnell wrote: But OTOH I feel a bit uncomfortable to see yet another intermediate code (after GCC's RTL, CLR's (.Net/Mono) CIL and FPC's own stuff) in the game. GCC's RTL and FPC's node tree representation were never designed as a generic intermediate layer that you can target from any other compiler. GCC's RTL also has too little high level information to be useful when performing whole program optimisation and various advanced transformations. That's the whole reason why they came up with gimple. CLR is more high level than LLVM. As mentioned in the main LLVM paper (http://llvm.org/pubs/2004-01-30-CGO-LLVM.ps ): *** [Smalltalk, Self, Java, CLR] Note that these systems all represent a program in a much higher (and language specific) representation than LLVM does. Although this presents a lot of high-level information to the runtime optimizer, it also makes it largely impossible for the static compiler to do a meaningful amount of optimization before runtime. As mentioned in Section 1.1.2, this requires the runtime optimizer to perform many mundane optimizations at runtime just to get acceptable code, which makes aggressive optimizations even more costly. [...] Another strength of LLVM is that it does not require a specific object model, set of exception semantics, or any other high-level language feature from a front-end. This makes it very flexible, but a set of inter-language conventions would need tobe defined to allow code produced by different front-ends to communicate (an LLVM Application Binary Interface, or ABI). *** BTW: it is possible to up-compile LLVM bitcode into CLR. There even is a proof-of-concept backend for that, but nobody is interested enough in that functionality to maintain it (so it doesn't work anymore). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
I am personally (every now and then) working on an FPC backend that emits llvm code. Llvm has been designed from the ground up to take some form of intermediate code as input and as a generic backend for other compilers. It's still quite young as a project and does not yet support as many targets as gcc, but it is evolving and improving very quickly. See http://llvm.org for more info. Sounds very interesting indeed ! Please keep me informed on what you come up with on that behalf ! NIOS is a very simple load-store 32 Bit RISK architecture, similar to the initial ARM Core, so I suppose it would be quite easy to port the ARM code generator of llvm to NIOS. But OTOH I feel a bit uncomfortable to see yet another intermediate code (after GCC's RTL, CLR's (.Net/Mono) CIL and FPC's own stuff) in the game. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
On Tue, Nov 4, 2008 at 8:10 AM, Marco van de Voort [EMAIL PROTECTED] wrote: Well, I gave up PIC24 since they don't contain motorcontrol, I've always wanted to know what does a microcontroller with motorcontrol is supposed to do different from a normal microcontroler? I mean, to drive a stepper motor, for example, you just need 4 or 5 output pins from any microcontroller and a darlington driver to deacoplate and power up. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
Bernd Mueller wrote: Michael Schnell wrote: This is why I decided to handle this kind of complexity with an FPGA with embedded (Linux-) Processor. which system/vendor did you choose? We are going to design some controller boards with Altera Cyclone III FPGAs. The NIOS processor is optimized for this FPGA architecture, is very easily implemented into the HDL design, offers acceptable features and speed (100 MHz, some 50 bogomips), can be selected to come with or without MMU and there is a very active Linux community. I have a NEEK demo board (with 32 MB DRAM) from Altera and Linux runs very nicely on it (including Ethernet, touch-screen based nano-X etc. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
How much do you need on a PIC ? I did not have many hope for really using Pascal on the PIC, but I am just thinking about a project with a PIC24 (which is a quite normal 16 bit processor core with 64K linear addressable memory (completely integrated in the chip), other than the PIC16, which is an 8 Bit processor with no memory bit only Registers in multiple 256 Byte banks). Here I in fact need to port part of an existing Delphi project (a master node of a serial communication network). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
yes, this is why I consider to use an ARM7 controller in front of an ARM9 (Linux) controller, although the ARM9 should have the power to handle my realtime stuff. This is why I decided to handle this kind of complexity with an FPGA with embedded (Linux-) Processor. The fast stuff can be done in HDL while the processor can take it's time to do the complex stuff. And we only have a single chip that (other than special processor chips) is very unlikely to become unavailable any time soon. And if the FPGA chip used is discontinued, there will very likely be a bigger compatible one. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Why is FPC so self-contained ?
Hi Compiler developers. I do lots of software projects for PCs and for embedded devices. While I do all PC projects (for Windows and Linux) in Object Pascal, which is my favorite programming language as it offers the best productivity and the lowest count on errors that show at runtime, I am forced to use GCC for the embedded projects as the processors used here (usually 68K, PIC and NIOS) are not supported by FPC. Now I just took a somewhat deeper look at how the new 4.x versions of GCC work and so the question comes up (again) why I can't use FPC for the embedded software tasks. GCC uses the preprocessor and the parser to create an intermediate code (RTL: Generic or Gimple). This process is independent from the target-architecture the code is to be compiled for. Now the RTL is optimized and finally a target specific code generator produces the object code which now is combined with other object code by the linker. AFAIK FPC works quite similar, but while only the parser really knows about the programming language, it comes with it's own preprocessor (which is only used optionally), it's own code generator and it's own linker. AFAIK, it even provides it's own make to compile multiple files. I could imagine a system that only provides a Pascal-to-RTL-parser and uses many of the GNU tools (preprocessor optionally, optimizer, code generator, linker, make). This would just provide another language for GCC and for hopefully allow me to use FPC-Pascal for any processor architecture supported by GCC. Are there other than historical reasons that FPC is this self-contained ? (I suppose compiling speed is an issue here, so a GCC compatible parser might only be an additional tool provided by the FPC team, but I'd really love to use this for my embedded projects.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
In our previous episode, Michael Schnell said: I'm going to use the PIC24 series, as same features an USB interface. I had bad experiences using the PIC18 with USB interfaces (bad latency, loss of connection without automatic reconnect). We reverted to RS232/RS422, and are experimenting with the newer ethernet versions. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
I'm going to use the PIC24 series, as same features an USB interface. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
Op Tue, 4 Nov 2008, schreef Michael Schnell: The point is those compilers cannot provide it because of (a) technical limitations, I don't think this is true. GCC can compile Java which I think is an object language in a similar extend as Object pascal is. And it seems to be similarly rich, though of course in different directions. While I do not deny this, I want to say is that our code generator has a lot of support for Object Pascal specific features that are for certain not available inside the GCC backend. This includes resourcestring, but also Pascal objects/classes, interfaces and more. It might be possible to work around it (after all GCC is Turing complete so any program should be implementable on the backend in theory), it would never become the same quality implementation that we have now. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
