Re: [fpc-devel] Circular references and forward declarations
2010/1/6 Vincent Snijders vsnijd...@vodafonevast.nl: You are getting old: http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13343.html Ah, but that would explain why I don't use it. I never develop in delphi mode, only objfpc mode - unless I work with projects like tiOPF where both compilers (Delphi and FPC) are requirements. I'll double check now if objfpc mode also supports strict private/protected. If not, this thread might be a good reason for it to be supported in objfpc mode too. It shouldn't cause any harm to other developers either - if you never used it before you will not notice anything different either. Using a single big unit with loads of include files will not be a problem for me as long as I can still keep information private to specific classes. This will solve my issues regarding circular references (an acceptable work-around). -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Graeme Geldenhuys schrieb: 2010/1/6 Vincent Snijders vsnijd...@vodafonevast.nl: You are getting old: http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13343.html Ah, but that would explain why I don't use it. I never develop in delphi mode, only objfpc mode - unless I work with projects like tiOPF where both compilers (Delphi and FPC) are requirements. Does my sentence exclude that strict works in fpc mode too. iirc it is supposed to work in all modes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Free Pascal Current Version in www.freepascal.org
In our previous episode, Mehmet Erol Sanliturk said: it seems that 2.2.4 needs to be 2.4.0 , and 2.3.x needs to be 2.5.x . Fixed, will be updated soon (I hope) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Nikolai ZHUBR schrieb: Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote: On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote: Then do the same as in C++ and put it in different include files. Right, include files could solve this problem at least partly. They seem to be Curious enough, nobody even mentioned interfaced objects (interfaces), though they are available in both FPC and Delphi since ages. Indeed, there are multiple ways to prevent the hell of circular class references between units: - abstract base classes - interfases - include files - big units - type casting (in the worst case) - ... The right choice depends on the application. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On keskiviikko, 6. tammikuuta 2010 03:08:35 Nikolai ZHUBR wrote: Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote: On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote: Then do the same as in C++ and put it in different include files. Right, include files could solve this problem at least partly. They seem to be Curious enough, nobody even mentioned interfaced objects (interfaces), though they are available in both FPC and Delphi since ages. Not that I would recommend this seriously, however here goes: I have tried that, too, but it doesn't solve the problem in real cases either. The problem are data members, not methods. You sometimes need to access data between dependent classes and with interface you then define Get... and Set... methods for them. That is little too much if you just want to avoid circular reference. Abstract base class is little better because you can define at least part of the data there. Still, best solution has been to put everything into one big file. And still, I don't like that compiler forces such a thing. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On keskiviikko, 6. tammikuuta 2010 10:59:36 Florian Klaempfl wrote: Indeed, there are multiple ways to prevent the hell of circular class references between units: - abstract base classes - interfases - include files - big units - type casting (in the worst case) - ... The right choice depends on the application. Abstract base classes and interfaces are recommended by many but actual projects end up copying everything into one file. Surprising... :-) I must try include files for this problem sometimes. Does FPC really treat them differently than Delphi. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 5 Jan 2010, at 22:40, Graeme Geldenhuys graemeg.li...@gmail.com wrote: I must say, I agree with the original poster - it would be very useful. I have had many battles to try and overcome circular reference issues, and I do take care in my class designs. I would also agree. I used to use Interfaces or raise shared classes/ declarations to a new unit both could use to overcome this issue myself. But I remember the Be GUI porters having loads of issues mimicing the Be API header structure because there were so many forward class declarations in the C++. It was impossible to do a unit to header file match because circular dependencies crept up at almost every turn. Without direct matching of header and unit names, the Be API documentation became hard to use. I don't know if they ever solved it, maybe if Olivier is still about, he can chime in? M ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Juha Manninen said: - big units - type casting (in the worst case) - ... The right choice depends on the application. Abstract base classes and interfaces are recommended by many but actual projects end up copying everything into one file. Surprising... :-) I never do this, there is no need. Probably similar to the fact that 90% of the Delphi programs have all important code in event handlers of the GUI components. That still doesn't make a good thing. I must try include files for this problem sometimes. Does FPC really treat them differently than Delphi. IIRC the only difference is that FPC recompiles on .inc change, and under Delphi you need to force a build after an .inc change. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 06 Jan 2010, at 11:14, Juha Manninen wrote:
I must try include files for this problem sometimes. Does FPC really
treat
them differently than Delphi.
No. {$i xxx} is exactly the same as copy/pasting the contents of xxx
into the current file at that point.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On Wed, 6 Jan 2010, Marco van de Voort wrote: In our previous episode, Juha Manninen said: - big units - type casting (in the worst case) - ... The right choice depends on the application. Abstract base classes and interfaces are recommended by many but actual projects end up copying everything into one file. Surprising... :-) I never do this, there is no need. Probably similar to the fact that 90% of the Delphi programs have all important code in event handlers of the GUI components. That still doesn't make a good thing. Glad you give this example. I try for years to convince my fellow programmers that an event handler should contain at most 1 or 2 lines of code: a call to a routine that does the actual work, and maybe some status updating... But old habits die hard :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: Still, best solution has been to put everything into one big file. And still, I don't like that compiler forces such a thing. The compiler forces you many other things. Still, I don't get what's the problem with a large unit if it's really needed (and nothing like abstract base classes or interfaces or type casts or ... helps). Stuff closely depending on each other should end in the same unit. You even cannot test a unit with external circular class references without the other involved units. So why should the stuff be separated? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Michael Van Canneyt said: projects end up copying everything into one file. Surprising... :-) I never do this, there is no need. Probably similar to the fact that 90% of the Delphi programs have all important code in event handlers of the GUI components. That still doesn't make a good thing. Glad you give this example. I try for years to convince my fellow programmers that an event handler should contain at most 1 or 2 lines of code: a call to a routine that does the actual work, and maybe some status updating... But old habits die hard :-) I'm not that strict. It may have more code but then that code must interact with the GUI, usually to tie together various GUI components so that they become a complete abstraction. Example: a listbox, its repaint/fill events and the buttons that add/remove/edit etc make a list of classes edit together. But for anything more complicated than setting a field in the business code they must call other code. This is a deliberate violation of the presentation layer idea, that routs nearly every event over controller code. The reason is that while those kind of principles map perfectly to webapps, the principle makes GUI apps more complicated without really getting anything back IMHO ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime
Stefan Kisdaroczi wrote: to create hard realtime linux programs with freepascal and xenomai [1] in userspace Ooops Userspace means Linux and Linux means no hard realtime possible (with the official definition of hard realtime: reaching a predefined timing deadline with 100% certainty). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Florian Klaempfl said: Still, best solution has been to put everything into one big file. And still, I don't like that compiler forces such a thing. The compiler forces you many other things. Still, I don't get what's the problem with a large unit if it's really needed (and nothing like abstract base classes or interfaces or type casts or ... helps). Stuff closely depending on each other should end in the same unit. You even cannot test a unit with external circular class references without the other involved units. So why should the stuff be separated? I don't like extremely large ( few thousand lines) units from an overview perspective. But I'm no visibility micro-manager. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime
Michael Schnell schrieb: Stefan Kisdaroczi wrote: to create hard realtime linux programs with freepascal and xenomai [1] in userspace Ooops Userspace means Linux and Linux means no hard realtime possible (with the official definition of hard realtime: reaching a predefined timing deadline with 100% certainty). Did you look at the xenomai website? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Florian Klaempfl schrieb: Juha Manninen schrieb: Still, best solution has been to put everything into one big file. And still, I don't like that compiler forces such a thing. The compiler forces you many other things. Still, I don't get what's the problem with a large unit if it's really needed (and nothing like abstract base classes or interfaces or type casts or ... helps). Stuff closely depending on each other should end in the same unit. You even cannot test a unit with external circular class references without the other involved units. So why should the stuff be separated? Add: FPC can also smartlink large units so no need to split stuff into thousands of object files. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime
On 05 Jan 2010, at 16:39, Stefan Kisdaroczi wrote: Looking at rtl/inc/heap.inc from 2.4.0 it seems that the locking is now done using CriticalSections, is that true ? Yes. To adapt my ThreadManager for 2.4.0 I think I have to: - remove the SetMemoryMutexManager() call - implement the *CriticalSection() calls in my XenoThreadManager Has someone any hints, comments or concerns about the approach ? It sounds perfectly fine to me. You should also experience much better performance with the new heap manager, as the critical section is seldom used in normal operation. If you want a program in which this scenario is stress tested, you can use http://svn.freepascal.org/svn/fpc/trunk/tests/test/theapthread.pp Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort schrieb: In our previous episode, Florian Klaempfl said: Still, best solution has been to put everything into one big file. And still, I don't like that compiler forces such a thing. The compiler forces you many other things. Still, I don't get what's the problem with a large unit if it's really needed (and nothing like abstract base classes or interfaces or type casts or ... helps). Stuff closely depending on each other should end in the same unit. You even cannot test a unit with external circular class references without the other involved units. So why should the stuff be separated? I don't like extremely large ( few thousand lines) units from an overview perspective. One can also say a lot of small files make it hard to find stuff (remember the people to complain about the huge amount of files of the fpc rtl :)?). With a good ide you don't care about this anymore: it works the same with a lot of small files or one huge file. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] mlockall() unit libc
In our previous episode, Stefan Kisdaroczi said: i need the mlockall() call (unit libc) in my realtime apps on linux i386 to lock the address space of the process. Works, but unit libc has no future and it's the only function i need from this unit. mlockall is part of the posix 2001 realtime extensions, which are afaik optional. And usually it only works for root. IOW not all Unices might implement it, which is more or less the rule of thumb to get into one of the portalbe units (unix,baseunix) Sometimes exceptions to this rule are made (e.g. for UUID functions) when the function are found to be implemented on all unix platforms. I checked and they (+ the corresponding unlock) are in FreeBSD5+, so FreeBSD is no problem (MCL_CURRENT and MCL_FUTURE are the mandatory flags by Posix, and FreeBSD only supports those) I saw some hints on the web that OS X doesn't support it (but it should be checked against 10.3/10.4+ since afaik those implement a lot more calls due to synchronization with FreeBSD5) Then solaris and Haiku as the other unices must be checked. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen wrote: IMO, the compiler should not force a programmer to make a 34 000 lines source file (like VirtualTreeView has). Programmer should have a choice to split it if he wants. What about include files (used a lot in Lazarus LCL) ? You can e.g. separate the interface part from the installation part into separate files (which is standard in ANSI C by using .h files) I use a C compiler (for 8 Bit PICs) that can't link at all. Here you do a kind of linking manually by using a main file that includes everything else. GCC has an option to do a kind of source code linking by building a huge source from all files that usually are linked as binaries and doing a single compile process on that. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Florian Klaempfl said: cannot test a unit with external circular class references without the other involved units. So why should the stuff be separated? I don't like extremely large ( few thousand lines) units from an overview perspective. One can also say a lot of small files make it hard to find stuff Yes. But I didn't say that limiting the maximum size means going to the other extreme (remember the people to complain about the huge amount of files of the fpc rtl :)?). The point is that they are right from a birds-eye general application development view. But wrong from the perspective of the exact requirements on the RTL. IOW the RTL is not a normal piece of code. With a good ide you don't care about this anymore: it works the same with a lot of small files or one huge file. Then I never saw a good IDE. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Michael Schnell said: I use a C compiler (for 8 Bit PICs) that can't link at all. Here you do a kind of linking manually by using a main file that includes everything else. Which is that then? Afaik the microchip own, and the Hitech compilers can do so perfectly? These compilers work roughly like gcc, from data in the project (or makefile) they generate a linker commandline. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] mlockall() unit libc
On 06 Jan 2010, at 11:54, Marco van de Voort wrote: I saw some hints on the web that OS X doesn't support it (but it should be checked against 10.3/10.4+ since afaik those implement a lot more calls due to synchronization with FreeBSD5) $ gcc -o mlockall mlockall.c $ ./mlockall mlockall:1: Function not implemented munlockall:1: Function not implemented mlockall:2: Function not implemented mlockall:3: Function not implemented $ sw_vers ProductName:Mac OS X ProductVersion: 10.5.8 BuildVersion: 9L31a (that's the mlockall test program from http://www.oit.uci.edu/dcslib/digital_unix/digital-v40d/APS33DTE/DOCU_005.HTM) Then solaris and Haiku as the other unices must be checked. Solaris at least has man pages for those functions. The test program fails there too, but that's probably simply because I'm not root (the man page says that root permissions are required). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort schrieb: (remember the people to complain about the huge amount of files of the fpc rtl :)?). The point is that they are right from a birds-eye general application development view. I wanted only to point out that there pros and cons for small/large units and if a design requires to put a lot of stuff into one unit becuase it is heavily interwinded, I see no problem with it. But wrong from the perspective of the exact requirements on the RTL. IOW the RTL is not a normal piece of code. With a good ide you don't care about this anymore: it works the same with a lot of small files or one huge file. Then I never saw a good IDE. With lazarus you don't notive in which files the code actually is? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] mlockall() unit libc
In our previous episode, Jonas Maebe said: I saw some hints on the web that OS X doesn't support it (but it should be checked against 10.3/10.4+ since afaik those implement a lot more calls due to synchronization with FreeBSD5) $ gcc -o mlockall mlockall.c $ ./mlockall mlockall:1: Function not implemented munlockall:1: Function not implemented mlockall:2: Function not implemented mlockall:3: Function not implemented Hmm, in that case I'll actually try to run this program on FreeBSD with root tonight. But, to summarize then chances for generic units are slim. The unportable garbage linux unit is then the only solution, and then hope that cut down linuxes don't cut it out. Then solaris and Haiku as the other unices must be checked. Solaris at least has man pages for those functions. The test program fails there too, but that's probably simply because I'm not root (the man page says that root permissions are required). If such a recent Darwin doesn't have it, then IMHO it is not an option now. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On keskiviikko, 6. tammikuuta 2010 12:42:23 Florian Klaempfl wrote: Juha Manninen schrieb: Still, best solution has been to put everything into one big file. And still, I don't like that compiler forces such a thing. The compiler forces you many other things. Still, I don't get what's the problem with a large unit if it's really needed (and nothing like abstract base classes or interfaces or type casts or ... helps). Stuff closely depending on each other should end in the same unit. You even cannot test a unit with external circular class references without the other involved units. So why should the stuff be separated? I must admit this is a good point. This is more of a cultural issue between programming languages. If the tool chain supports big source files and if people accept them, there is no problem. OOT I hope Lazarus can soon edit parts of one file in many editor tabs. /OOT Other programming languages have different cultures. See the comment from my original post in this thread. It was from a professional programmer and I understand it. Some development teams want to put every class into its own file. C and C++ even have headers in separate files (which is messy IMO). So, if a professional team chooses a programming language / environment for a project, this one feature can make a strong point against Object Pascal. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Florian Klaempfl schrieb: Marco van de Voort schrieb: (remember the people to complain about the huge amount of files of the fpc rtl :)?). The point is that they are right from a birds-eye general application development view. I wanted only to point out that there pros and cons for small/large units and if a design requires to put a lot of stuff into one unit becuase it is heavily interwinded, I see no problem with it. ... and splitting the unit by external circular class types makes no use, it even makes things less readable. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort wrote: Which is that then? Afaik the microchip own, and the Hitech compilers can do so perfectly? CCS Same had been the cheapest option for a C compiler to try out the PICs. I never switched to something else, as I am abandoning the 8 bit PICs for the 16 Bit ones that are supported by a decent gcc that can be tested in a non-payed public version and now the commercially supported version. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Juha Manninen said: Other programming languages have different cultures. See the comment from my original post in this thread. It was from a professional programmer and I understand it. Some development teams want to put every class into its own file. C and C++ even have headers in separate files (which is messy IMO). So, if a professional team chooses a programming language / environment for a project, this one feature can make a strong point against Object Pascal. If we change FPC so that a C++ team that only knows C++ feels perfectly at home directly, we might as well throw away FPC and restart building a C++ system. There is no end to this kind of uninformed arguments, and when you really dig into it, there is nothing practical to be gained from it. Specially for systems like Java and C# that have a totally different concept of organizing source and finding compilation order. (for C++ you could also C#, Java, VB.NET, Ruby, Python or whatever) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On Wed, 6 Jan 2010, Juha Manninen wrote: On keskiviikko, 6. tammikuuta 2010 12:42:23 Florian Klaempfl wrote: Juha Manninen schrieb: Still, best solution has been to put everything into one big file. And still, I don't like that compiler forces such a thing. The compiler forces you many other things. Still, I don't get what's the problem with a large unit if it's really needed (and nothing like abstract base classes or interfaces or type casts or ... helps). Stuff closely depending on each other should end in the same unit. You even cannot test a unit with external circular class references without the other involved units. So why should the stuff be separated? I must admit this is a good point. This is more of a cultural issue between programming languages. If the tool chain supports big source files and if people accept them, there is no problem. OOT I hope Lazarus can soon edit parts of one file in many editor tabs. /OOT Other programming languages have different cultures. See the comment from my original post in this thread. It was from a professional programmer and I understand it. Some development teams want to put every class into its own file. C and C++ even have headers in separate files (which is messy IMO). So, if a professional team chooses a programming language / environment for a project, this one feature can make a strong point against Object Pascal. Why ? Every class in 1 file is perfectly possible with include files, and 1 big unit file. If someone comes from C this should not be a problem, since every C file simply is an include file, header file or not. There are no privileged files. In pascal there are: the unit and the program. The unit is called 'unit' because it 'unites' a set of routines that are closely interrelated. Honestly, I don't understand what the fuss is all about. You can make it as complicated or as simple as you want, it is all up to you. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: Other programming languages have different cultures. See the comment from my original post in this thread. It was from a professional programmer and I understand it. Some development teams want to put every class into its own file. Different languages, different habits. I even consider putting every class in its own header and implementation file as a bad habit. There is no reason to do anymore because modern C/C++ compiler can smartlink on a sub-object level which they could not for years. C and C++ even have headers in separate files (which is messy IMO). So, if a professional team chooses a programming language / environment for a project, this one feature can make a strong point against Object Pascal. Then they are not eduacated well enough because they don't know the reason why C++ programmers put (past tense) every class into it's own object file. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Michael Schnell said: Which is that then? Afaik the microchip own, and the Hitech compilers can do so perfectly? CCS Same had been the cheapest option for a C compiler to try out the PICs. Well, the microchip one academic option is free. So CCS gives money with their tools ? :-) I never switched to something else, as I am abandoning the 8 bit PICs for the 16 Bit ones that are supported by a decent gcc that can be tested in a non-payed public version and now the commercially supported version. I already switched to 16-bit (33FJA128MC510 and -804) long ago, and am very happy with them. But I still use the PIC18F60j60 part since there is no 16-bit integrated ethernet part, and as spare replacement for legacy parts. The PIC32 look interesting, but there is no motorcontrol (quadrature decoder) in that family yet, something that I require. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime
Florian Klaempfl wrote: Did you look at the xenomai website? Seemingly you need to do your own device drivers and not use any Linux system calls in your realtime process, that seems to run Linux in a kind of virtualization. So FPC programming for realtime would require to prevent FPC from creating Linux system calls. Thus you need a modified RTL (e.g. for memory management). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime
Michael Schnell schrieb: Florian Klaempfl wrote: Did you look at the xenomai website? Seemingly you need to do your own device drivers and not use any Linux system calls in your realtime process, that seems to run Linux in a kind of virtualization. Hard real time causes a lot of limitation, indeed. So FPC programming for realtime would require to prevent FPC from creating Linux system calls. Thus you need a modified RTL (e.g. for memory management). Guess why the topic of this thread is custom ThreadManager and MemoryMutexManager ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen wrote:
OOT I hope Lazarus can soon edit parts of one file in many editor tabs.
/OOT
It can compress entities (e.g. Functions) to a single line. Seems
helpful on that behalf. Maybe this feature could be extended e.g. by
recognizing {$part xxx} comments or similar.
Maybe you could even do this :)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote: Why ? Every class in 1 file is perfectly possible with include files, and 1 big unit file. Ok, include files seem to solve this problem. I don't know why they are not commonly used in Delphi programs as source files. It may be a culture or convention also, technically it should be possible with Delphi as well. I must change my mindset for those include files. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen wrote: Ok, include files seem to solve this problem. I don't know why they are not commonly used in Delphi programs as source files. Maybe because (some old version of the) Delphi IDE's debugger could not step into include files. AFAIK, the actual Lazarus can do this with no problem. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Did you have a look at AVR? They use GCC, although commercial compilers are also available should you need it. I have used GCC-AVR for years without problems. Marco van de Voort wrote: In our previous episode, Michael Schnell said: Which is that then? Afaik the microchip own, and the Hitech compilers can do so perfectly? CCS Same had been the cheapest option for a C compiler to try out the PICs. Well, the microchip one academic option is free. So CCS gives money with their tools ? :-) I never switched to something else, as I am abandoning the 8 bit PICs for the 16 Bit ones that are supported by a decent gcc that can be tested in a non-payed public version and now the commercially supported version. I already switched to 16-bit (33FJA128MC510 and -804) long ago, and am very happy with them. But I still use the PIC18F60j60 part since there is no 16-bit integrated ethernet part, and as spare replacement for legacy parts. The PIC32 look interesting, but there is no motorcontrol (quadrature decoder) in that family yet, something that I require. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 06 Jan 2010, at 12:14, Florian Klaempfl wrote: Different languages, different habits. I even consider putting every class in its own header and implementation file as a bad habit. There is no reason to do anymore because modern C/C++ compiler can smartlink on a sub-object level which they could not for years. Another reason is probably to speed up the compilation: * (re)compiling huge source files can be slow and/or require lots of memory, depending on the used compiler (and debug information or optimization settings) * every separate C/C++ file can be compiled in parallel with all others Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort wrote: I already switched to 16-bit (33FJA128MC510 and -804) long ago, and am very happy with them. Same here (with PIC 24xx). A friend of mine uses the 33s very happily, too. But I still use the PIC18F60j60 part since there is no 16-bit integrated ethernet part, and as spare replacement for legacy parts. This fried uses the (quite new) Microchip Ethernet MAC/PHY chip (including frame buffers, doing 100MBit) that can be connected to the PIC as an SPI slave (just three or four wires). Microsoft provides appropriate software for this setup. He's going to give me one of his board very soon. I'm looking forward to playing with that. The PIC32 look interesting, but there is no motorcontrol (quadrature decoder) in that family yet, something that I require. What about using a slave-PIC coupled by SPI (this is what my friend does all the time). As the PIC32 is a MIPS architecture, it could benefit from the MIPS port of FPC that quite recently was discussed here. As you are considering PIC32 the MIPS FPC might have a better chance to come into existence now I would be inclined to help on this issue, as I am intending to use NIOS which is very similar architecture to MIPS. :) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On Wed, 6 Jan 2010, Juha Manninen wrote: On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote: Why ? Every class in 1 file is perfectly possible with include files, and 1 big unit file. Ok, include files seem to solve this problem. I don't know why they are not commonly used in Delphi programs as source files. It may be a culture or convention also, technically it should be possible with Delphi as well. The Delphi compiler has no problems with include files, but the Delphi IDE has; Include files - just like conditioanl defines - totally mess up all code tools. Probably the reason why they are not encouraged. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Jonas Maebe schrieb: On 06 Jan 2010, at 12:14, Florian Klaempfl wrote: Different languages, different habits. I even consider putting every class in its own header and implementation file as a bad habit. There is no reason to do anymore because modern C/C++ compiler can smartlink on a sub-object level which they could not for years. Another reason is probably to speed up the compilation: * (re)compiling huge source files can be slow and/or require lots of memory, depending on the used compiler (and debug information or optimization settings) For single class c++ files, imo most of the time is spent into reading the huge headers which are often even not needed and a complete mess because nobody has an overview which classes are used and which not. * every separate C/C++ file can be compiled in parallel with all others That's might be a point. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Include files - just like conditional defines - totally mess up all code tools. Is this true for the newest versions of Delphi, too ? I seem to remember rumors about lots of IDE improvements. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On Wed, 6 Jan 2010, Michael Schnell wrote: Include files - just like conditional defines - totally mess up all code tools. Is this true for the newest versions of Delphi, too ? I seem to remember rumors about lots of IDE improvements. Well, not yet in D2009 as far as I remember, but I don't know about D2010, since I don't own a copy yet ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Michael Schnell said: But I still use the PIC18F60j60 part since there is no 16-bit integrated ethernet part, and as spare replacement for legacy parts. This fried uses the (quite new) Microchip Ethernet MAC/PHY chip (including frame buffers, doing 100MBit) that can be connected to the PIC as an SPI slave (just three or four wires). Microsoft provides appropriate software for this setup. He's going to give me one of his board very soon. I'm looking forward to playing with that. Yes. I bought the pictail kit for that part, and it is lying right beside me. Trouble is that the print we have now (externally fabricated) don't connect the INT pin needed for SPI frame mode to a connector, so it'll have to wait a generation. Luckily we didn't buy a large batch of prints. But it is also a bit that the whole point of the controller is being realtime. THe ethernet stuff till now is on systems that only have to react to 1ms magnitude events, while the 16-bitters are more like pseudo realtime into the 10us magnitude. External (microchip stack) software can detract from this, and will need a lot of testing. An extra reason is that the pic18 10-mbit stuff doesn't work very well connected to gigabit switches. The PIC32 look interesting, but there is no motorcontrol (quadrature decoder) in that family yet, something that I require. What about using a slave-PIC coupled by SPI (this is what my friend does all the time). That is more like what I'm planning. It will depend how good the frame-spi works. (IOW if it doesn't increase latency) As the PIC32 is a MIPS architecture, it could benefit from the MIPS port of FPC that quite recently was discussed here. Not for my (work) purposes, though I'd certainly play with it. While I would welcome a more forgiving syntax than C (with its == vs = problems), the avg program is small (1000 line magnitude, of which 700 lines are the same everywhere). It is not worth abondoning the supported compiler for. I rather use FPC to substitute some of my 10-20 line programs on the delphi side. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Florian Klaempfl said: memory, depending on the used compiler (and debug information or optimization settings) For single class c++ files, imo most of the time is spent into reading the huge headers which are often even not needed and a complete mess because nobody has an overview which classes are used and which not. And even if you forget that, there is the added compiler startup/initialization/finalization per compilation for gcc. Average larger files compile probably faster overall. * every separate C/C++ file can be compiled in parallel with all others That's might be a point. Only if you stuff it in one, and have no others to parallelize One big file just goes as well parallel (with other big files and smaller files). Moreover it assumes that the smaller files don't depend too much on eachother. (since that would effectively serialize them again) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime
Am 06.01.2010 12:35, schrieb Michael Schnell: Florian Klaempfl wrote: Did you look at the xenomai website? Seemingly you need to do your own device drivers and not use any Linux system calls in your realtime process, that seems to run Linux in a kind of virtualization. So FPC programming for realtime would require to prevent FPC from creating Linux system calls. Thus you need a modified RTL (e.g. for memory management). You can call normal linux system calls without problems, that is one of the big features of xenomai, but of course you have to take care, it can have an impact on the realtime performance. I try to explain the concept: (There are much better documents on xenomai.org) Tasks: - Xenomai adds a realtime scheduler - two cooperating schedulers. - ALL Tasks are 'normal' linux tasks, realtime task are additionaly registered in the realtime scheduler. - A realtime Task can be scheduled by linux AND xenomai: - The Tasks can migrate while running from on to the other scheduler: running on realtime scheduler - primary mode running on linux scheduler - secondary mode On a linux system call in primary mode, the task will migrate to secondary mode automatically, with a blocking realtime call it will switch automatically back to primary mode. A lot of information is in the /proc-Interface, so you can see which task migrated how often to secondary mode. You can install a Trap-Handler too, which is great to find unwanted mode-switches. IRQ's: - Xenomai adds a Interrupt-Pipeline: Interrupts are handled first by the xenomai scheduler and then passed to the linux scheduler. -- Linux interrupt handling is stalled while the realtime scheduler has tasks to run Device Drivers are programmed in kernel-space using RTDM: - RTDM is a realtime driver Interface supported by Xenomai and RTAI (another linux realtime extension), maybe others. There is also a RTDM interface for linux native realtime support using the preempt_rt-patch probably in mainline soon ... Future: If you build your realtime apps as Xenomai userspace apps and make RTDM-Drivers, in about two years (just guessed), you will be able to run your realtime apps with the Xenomai Duo-Kernel approach or on the linux native preempt_rt realtime support without changing anything in the application or driver code, just recompile. kisda -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel signature.asc Description: OpenPGP digital signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 06 Jan 2010, at 13:04, Florian Klaempfl wrote: Jonas Maebe schrieb: Another reason is probably to speed up the compilation: * (re)compiling huge source files can be slow and/or require lots of memory, depending on the used compiler (and debug information or optimization settings) For single class c++ files, imo most of the time is spent into reading the huge headers which are often even not needed and a complete mess because nobody has an overview which classes are used and which not. It depends. Since these compilers only see whatever is in the current source file (and its header files), putting more code in the same source file can significantly slow down interprocedural optimizations (as soon as one algorithm with quadratic complexity is involved). And inlining can significantly increase the complexity of single routines as well, making stuff such as register allocation much slower :) At least compiling Apple's Mac OS X linker is fairly slow, even though it's only about 1MB of code. The reason is that they put virtually all of the classes into the header files, and then include those together in the main cpp file. See http://www.opensource.apple.com/source/ld64/ld64-95.2.12/src/ld/ . Pretty much the entire linker is implemented in MachOReaderRelocatable.hpp and MachOWriterExecutable.hpp (note that I'm not claiming that this is how typical C++ programs are structured, it's only to illustrate that compiling one huge file can be quite slow). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Jonas Maebe schrieb: On 06 Jan 2010, at 13:04, Florian Klaempfl wrote: Jonas Maebe schrieb: Another reason is probably to speed up the compilation: * (re)compiling huge source files can be slow and/or require lots of memory, depending on the used compiler (and debug information or optimization settings) For single class c++ files, imo most of the time is spent into reading the huge headers which are often even not needed and a complete mess because nobody has an overview which classes are used and which not. It depends. Since these compilers only see whatever is in the current source file (and its header files), putting more code in the same source file can significantly slow down interprocedural optimizations (as soon as one algorithm with quadratic complexity is involved). And inlining can significantly increase the complexity of single routines as well, making stuff such as register allocation much slower :) On the other hand keeping things in different files avoids these optimizations. And being honest: I think using a debug switch set without any optimization and with maximum checks and fast compilation should be used for developer builds while wpo, inlining etc. is switched on during relese builds. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Wimpie Nortje said: Did you have a look at AVR? Yes, but from what I remember it was canceled because the amount of periphery on the chip is poor. I also looked at ARM, but while there is more choice there, it is fragmented over multiple vendors, with multiple toolchains (if a free one exists at all) PIC32 is only interesting because it is slightly faster and has more mem. But that would be more a future proofing thing, since we don't really lack it atm. But motorcontrol parts (integrated quadrature encoder, preferably several) is absolutely mandatory. They use GCC, although commercial compilers are also available should you need it. I have used GCC-AVR for years without problems. So does 16-bit microchip, and I'm using it for 2 years in production now. The 8-bit embedded ethernet part (even PHY!) is the only exception, and functions at the same time (same print) as spare part for stuff older than 2 years, so we can't get rid of it anyway and is quite cheap. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort schrieb: In our previous episode, Wimpie Nortje said: Did you have a look at AVR? Yes, but from what I remember it was canceled because the amount of periphery on the chip is poor. I also looked at ARM, but while there is more choice there, it is fragmented over multiple vendors, with multiple toolchains (if a free one exists at all) Of course ;) Called FPC :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime
Stefan Kisdaroczi wrote: You can call normal linux system calls without problems, that is one of the big features of xenomai, but of course you have to take care, it can have an impact on the realtime performance. Meaning that when doing a Linux system call, at this point a potentially huge delay might be introduced. As the standard FPC memory management in the RTL potentially does Linux system calls, you either need to modify the RTL on that behalf (AFAIK the memory manager is done as a plugin and thus you easily _can_ provide your own one), or avoid memory management completely (no idea how this might be possible). IRQ's: - Xenomai adds a Interrupt-Pipeline: Interrupts are handled first by the xenomai scheduler and then passed to the linux scheduler. -- Linux interrupt handling is stalled while the realtime scheduler has tasks to run That is what I meant with running Linux in a kind of virtualization. Future: If you build your realtime apps as Xenomai userspace apps and make RTDM-Drivers, in about two years (just guessed), you will be able to run your realtime apps with the Xenomai Duo-Kernel approach or on the linux native preempt_rt realtime support without changing anything in the application or driver code, just recompile. Even closer to Virtualization. Of course this is very interesting when dual core hardware is provided (which gets more and more standard. I do suppose Xenomai offers some memory management paradigm, which you can use instead of Linux system calls in your alternative FPC memory manager. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort wrote: I rather use FPC to substitute some of my 10-20 line programs on the delphi side. This is what I intend to get running before I retire :) : Have an existing Delphi project of the size you mention run on NIOS/Linux. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort wrote: Yes, but from what I remember it was canceled because the amount of periphery on the chip is poor. I also looked at ARM, but while there is more choice there, it is fragmented over multiple vendors, with multiple toolchains (if a free one exists at all) What was canceled? The AVR devices is certainly not and neither are the GCC toolchains (one for 8b and one for 32b). PIC32 is only interesting because it is slightly faster and has more mem. But that would be more a future proofing thing, since we don't really lack it atm. I don't want to start a AVR/PIC fight because it always ends up in a religous war and this is the wrong list anyway. However, some of my reasons for moving from PIC to AVR are: - AVR is faster, - has usually more memory, which programs faster - has higher code density, - has cheaper tools (programmers etc) - has free toolchains for all devices The down side is that Microchip has never to my knowledge obsoleted a device, whereas Atmel quite often do obsolete parts which then requires recompiling the program for the replacement part. But motorcontrol parts (integrated quadrature encoder, preferably several) is absolutely mandatory. I have never used motor control but there are parts intended for this ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Matt Emson wrote: I would also agree. I used to use Interfaces or raise shared classes/declarations to a new unit both could use to overcome this issue myself. But I remember the Be GUI porters having loads of issues mimicing the Be API header structure because there were so many forward class declarations in the C++. It was impossible to do a unit to header file match because circular dependencies crept up at almost every turn. Without direct matching of header and unit names, the Be API documentation became hard to use. I don't know if they ever solved it, maybe if Olivier is still about, he can chime in? I would think any time you have two objects that need bidirectional access of any sort that you would need to define an connector object to make this link, so the data or functions that needs to be shared between the two don't reside in either object, but in the connector object. Because if the data or functions are needed by both, they really aren't a part of either, it is its own thing and should have its own object. Or maybe I'm not seeing the problem properly. I just know that the few times I've hit on the circular unit problem where A needed to know about B, and B needed to know about A, that's how I've solved it, by making another unit C with the parts that needed access and pointing both A and B to that new unit. Maybe my problems were trivial, though. I'm certainly no OOP expert. Jeff. -- I haven't smoked for 3 years, 4 months and 2 weeks, saving $5,572.94 and not smoking 37,152.94 cigarettes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Circular references and forward declarations
Wednesday, January 06, 2010, 2:47:24 PM, Juha Manninen wrote: On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote: Why ? Every class in 1 file is perfectly possible with include files, and 1 big unit file. Ok, include files seem to solve this problem. I don't know why they are not commonly used in Delphi programs as source I don't like include files and try to not use them anywhere except in some cross-platform libraries, along with conditional compilation, and even then, I always try to minimize them. An include file by its pure nature is just an arbitary fragment. It does not necessarily have any consistent meaning on its own, either logically or syntactically. Therefore, compiler does not (and have no way to) do any integrity/dependancy checking on include file as on a separate entity. For the same reason, looking at an include file may give absolutely no idea of its meaning unless you also open all its including files along with. The concept of include files is not part of the language. It is just a tool to mitigate the troubles of editing/storage/archiving and such other maintenance burden tasks. From the language perspective, include files just do not exist! They are substituted textually, just like copy-n-paste, effectively producing one (big or not, whatever) file anyway. Period. On the other hand, object pascal as a language offers 2 mechanisms for structuring code logically: units and classes. Both are language concepts, both allow compiler to actively help programmer by means of visibility restrictions etc. I would say, some corner cases do exist, where the concept of units and the concept of classes somehow clinch in unconfortable manner. IMHO this does not happen too often and there are some known workarounds. Still probably, the language in its current form has its limits. Maybe these could be extended eventually, at least out of academic curiosity. In practice however, object pascal already provides such benefits that it is imho quite fair to tolerate some corner rough edges. Nikolai ZHUBR files. It may be a culture or convention also, technically it should be possible with Delphi as well. I must change my mindset for those include files. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Wimpie Nortje said: Marco van de Voort wrote: Yes, but from what I remember it was canceled because the amount of periphery on the chip is poor. I also looked at ARM, but while there is more choice there, it is fragmented over multiple vendors, with multiple toolchains (if a free one exists at all) What was canceled? The AVR devices is certainly not and neither are the GCC toolchains (one for 8b and one for 32b). Our investigation into AVR. PIC32 is only interesting because it is slightly faster and has more mem. But that would be more a future proofing thing, since we don't really lack it atm. I don't want to start a AVR/PIC fight because it always ends up in a religous war and this is the wrong list anyway. However, some of my reasons for moving from PIC to AVR are: I've found that most of those sentiments are based on old arguments that don't go nowadays. Such discussions could be kept on track ( and interesting) if you simply name numbers. - AVR is faster, microchip 16-bit maxes at 40 or 50MIPS. Our is 40MIPS. 32-bit goes higher, 80MIPS or so. We keep speed mostly in reserve for unexpected problems we have to improvise on . Most of the normal functionality ( a shift register, encoder based) is done by hardware on the chip with no blocking or polling own code, leaving the CPU power (and a lot of normal goodies like pins with special purposes and timers) free for improvising in case of trouble. - has usually more memory, which programs faster Only if you need it. I typically use 1 - 1.5 kb of the PIC that has 8kb (and there are 16kb editions). PIC32 parts go up to 128kb (ram) iirc. All 16-bit and 32-bit mem is dual ported for DMA purposes. - has higher code density, No idea. Don't care. The flash of the standard part is 128kb, and I use typically 7k, and haven't been above 11k. We have more flash because the motorcontrol parts are more expensive, and the more expensive parts have more flash. (typical region Eur5/chip) - has cheaper tools (programmers etc) Microchip programmers start from Eur 20. (note that this particular bit has changed significantly in the last 2 years) - has free toolchains for all devices Afaik all 16-bit devices are supported by the free toolchains, but have optimization disabled. The down side is that Microchip has never to my knowledge obsoleted a device, whereas Atmel quite often do obsolete parts which then requires recompiling the program for the replacement part. Another important reason was the existance of high pin count (100,144) devices, since we have a lot of binary I/O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] COMPUNIT for building the compiler
Is there a way to find out what stuff have been generated after a make under osx ? The fpcbuild.zip includs a lot of files; I do a make all under ...ide/compiler/ and it seems that it compiles fine; I mean compunit.ppu and compunit.o are created however I was expecting a proper ppc* compiler as output ? am i confused here ? tnx ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] COMPUNIT for building the compiler
In our previous episode, London Disney said: Is there a way to find out what stuff have been generated after a make under osx ? The fpcbuild.zip includs a lot of files; I do a make all under ...ide/compiler/ and it seems that it compiles fine; I mean compunit.ppu and compunit.o are created however I was expecting a proper ppc* compiler as output ? am i confused here ? Yes. The commandline compiler is in ..compiler/ ide/compiler is the embedded compiler of the textmode ide. Have a look at the buildfaq http://www.stack.nl/~marcov/buildfaq.pdf ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Wimpie Nortje wrote: I don't want to start a AVR/PIC fight because it always ends up in a religous war We could just as well add Renesas and whatever other such archs :) . I suppose each has it's pros and cons, otherwise it would already have died out out taken the world. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] COMPUNIT for building the compiler
ok thanks. really hard to get into new stuff under *nix systems. would be nice to have xcode projects for all this as well as command-line make files. are there any plans to do that ? On Wed, Jan 6, 2010 at 2:06 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, London Disney said: Is there a way to find out what stuff have been generated after a make under osx ? The fpcbuild.zip includs a lot of files; I do a make all under ...ide/compiler/ and it seems that it compiles fine; I mean compunit.ppu and compunit.o are created however I was expecting a proper ppc* compiler as output ? am i confused here ? Yes. The commandline compiler is in ..compiler/ ide/compiler is the embedded compiler of the textmode ide. Have a look at the buildfaq http://www.stack.nl/~marcov/buildfaq.pdf ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] COMPUNIT for building the compiler
On 06 Jan 2010, at 15:09, London Disney wrote: would be nice to have xcode projects for all this as well as command-line make files. are there any plans to do that ? I don't think so, since I know of nobody that uses Xcode to work on FPC (and such a project would have to be kept up-to-date in parallel with the makefiles, unless we'd switch to something like cmake -- which is quite unlikely). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime
Am 06.01.2010 14:02, schrieb Michael Schnell: Stefan Kisdaroczi wrote: You can call normal linux system calls without problems, that is one of the big features of xenomai, but of course you have to take care, it can have an impact on the realtime performance. Meaning that when doing a Linux system call, at this point a potentially huge delay might be introduced. True, but for realtime apps the most important part is the application design. You never create tasks realtime, you never alloc mem in realtime. You dont take a normal app, recompile it with xenomai and everything works realtime. As the standard FPC memory management in the RTL potentially does Linux system calls, you either need to modify the RTL on that behalf (AFAIK the memory manager is done as a plugin and thus you easily _can_ provide your own one), or avoid memory management completely (no idea how this might be possible). AFAIK the RTL allocs the heap on app startup, or on thread-creation with 2.4.0. In my code im using getmem() to alloc mem from the heap, this will not generate syscalls because the heap is already allocated and the RTL has its own MemoryManager. Regarding the memory management I think using fpc with Xenomai is even better than using C, where you have to call malloc(), which will probably make a linux syscall. The only problem is the locking of the MemoryManager. It should not use Linux-Mutexes, it should use Xenomai-Mutexes. This is what I did with the custom MemoryMutexManager. If i'm wrong here please cry loud STOP, thx :-) The custom ThreadManager is like the cthreads implementation, but it creates tasks over the xenomai library instead of the pthreads lib. Important here is to setup the TLS after creating the tasks over xenomai for fpc. IRQ's: - Xenomai adds a Interrupt-Pipeline: Interrupts are handled first by the xenomai scheduler and then passed to the linux scheduler. -- Linux interrupt handling is stalled while the realtime scheduler has tasks to run That is what I meant with running Linux in a kind of virtualization. Future: If you build your realtime apps as Xenomai userspace apps and make RTDM-Drivers, in about two years (just guessed), you will be able to run your realtime apps with the Xenomai Duo-Kernel approach or on the linux native preempt_rt realtime support without changing anything in the application or driver code, just recompile. Even closer to Virtualization. Of course this is very interesting when dual core hardware is provided (which gets more and more standard. Its interesting on a singlecore too :-) But yes, on a duo-core you can use one processor exclusively for the realtime scheduler and the other one for the linux scheduler. Which variant you choose, duo-scheduler or single-scheduler with preempt_rt, depends on the worstcase latency your app needs. The worstcase latency on recent x86 machines is something like: - 20us : duo-kernel xenomai - 200us : linux preempt_rt - 2ms : linux native Of course that numbers are wrong, it depends on a lot of things, they are just to give an idea. I do suppose Xenomai offers some memory management paradigm, which you can use instead of Linux system calls in your alternative FPC memory manager. You can alloc realtime heaps, I use them for shared mems between multiple apps. Xenomai supports multiple API's (Native,Posix,VxWorks,pSOS+,VRTX,uITRON), i'm using the native skin for some reasons. If you want to use fpc for realtime with the posix skin, i think you just have to adapt cthreads that it links against pthread_rt instead of pthread. Not tested. kisda -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel signature.asc Description: OpenPGP digital signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] COMPUNIT for building the compiler
all done and built ! :) @Jonas yeah it was just a thought for people like me making a transition from some commercial tools under each platform (MSVS, XCode, etc...). good incentive to be able to visualize the structure w/o having to read lots, don't you think so ? anyway, just a thought. On Wed, Jan 6, 2010 at 2:21 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 06 Jan 2010, at 15:09, London Disney wrote: would be nice to have xcode projects for all this as well as command-line make files. are there any plans to do that ? I don't think so, since I know of nobody that uses Xcode to work on FPC (and such a project would have to be kept up-to-date in parallel with the makefiles, unless we'd switch to something like cmake -- which is quite unlikely). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime
On 06 Jan 2010, at 15:25, Stefan Kisdaroczi wrote: AFAIK the RTL allocs the heap on app startup, or on thread-creation with 2.4.0. In my code im using getmem() to alloc mem from the heap, this will not generate syscalls because the heap is already allocated and the RTL has its own MemoryManager. This is not entirely correct: while the rtl does pre-allocate some memory from the system on startup, it can still allocate more later if necessary, and it can also free memory back to the system. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Jeff Wormsley wrote: I would think any time you have two objects that need bidirectional access of any sort that you would need to define an connector object to make this link, so the data or functions that needs to be shared between the two don't reside in either object, but in the connector object. The problem at the time was that the BeAPI is C++ and uses multiple inheritance and a lot of the kinds of forward class declarations OP was asking for. The guys were trying to recreate a class for class analog of the API, so changing the API constructs was not an option. The rational was that creating a new API would alienate Pascal coders from the greater BeOS development community and would mean that all of the documentation would be useless as reference. This is obviously an edge case though and a self imposed restriction. M ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime
Am 06.01.2010 15:38, schrieb Jonas Maebe: On 06 Jan 2010, at 15:25, Stefan Kisdaroczi wrote: AFAIK the RTL allocs the heap on app startup, or on thread-creation with 2.4.0. In my code im using getmem() to alloc mem from the heap, this will not generate syscalls because the heap is already allocated and the RTL has its own MemoryManager. This is not entirely correct: while the rtl does pre-allocate some memory from the system on startup, it can still allocate more later if necessary, and it can also free memory back to the system. Thank you for that important hint. Are there any other options than a custom MemoryManager to disable that ? For the custom MemoryManager way I think I just copy the original one, try to disable the reallocating and freeing, and preallocate more on startup. On the other side I think its not really grave for my project, as I never allocate anything in the realtime loops. And there are no Objects/Classes, just plain pascal. The same code still needs to compile on a 16Bit Compiler from 1989 (DOS based realtime system)... Btw, about circular references : This old compiler uses C-like header files, no interface and implementation section. So you don't have any circular reference problems. To get the 15 apps with 500+ units compatible to fpc and to avoid circular references it was a lot of work, but its doable. kisda signature.asc Description: OpenPGP digital signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
OT: Lazarus behaviour (tabs/fold) [Re: [fpc-devel] Circular references and forward declarations]
Michael Schnell wrote:
Juha Manninen wrote:
OOT I hope Lazarus can soon edit parts of one file in many editor tabs.
/OOT
http://www.lazarus.freepascal.org/index.php/topic,8304.msg39889.html#msg39889
http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-November/046906.html
It can compress entities (e.g. Functions) to a single line. Seems
helpful on that behalf. Maybe this feature could be extended e.g. by
recognizing {$part xxx} comments or similar.
{$region}
{$endregion}
{%region}
{%endregion}
{$region /fold} // autofold on load
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Creating ppc386 from ppcx64
Hi, I'm trying to create a cross compiler from Linux-x86_64 to Linux-i386, to do this, I have installed the compiled version 2.4.0 from Ubuntu repositories, which is ppcx64, then got the compiler trunk version from svn. To create the cross compiler, I'm following this guide: http://wiki.lazarus.freepascal.org/Cross_compiling#To_Linux When I do sudo make all CPU_TARGET=i386 I receive this message: /usr/bin/fpc -Pi386 -XPi386-linux- -Xr -Fui386 -Fusystems -Fu../rtl -Fii386 -FEs Error: ppc386 can't be executed, error message: Failed to execute ppc386, err7 make: *** [ppc386] Error 1 Which is correct, since I don't have ppc386 installed. How can I create it?, is it correct to just create a symlink from ppcx64? Thanks in advance, Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [SPAM] [fpc-devel] Creating ppc386 from ppcx64
On 06 Jan 2010, at 20:15, Leonardo M. Ramé wrote: To create the cross compiler, I'm following this guide: http://wiki.lazarus.freepascal.org/Cross_compiling#To_Linux When I do sudo make all CPU_TARGET=i386 I receive this message: /usr/bin/fpc -Pi386 -XPi386-linux- -Xr -Fui386 -Fusystems -Fu../rtl -Fii386 -FEs Error: ppc386 can't be executed, error message: Failed to execute ppc386, err7 make: *** [ppc386] Error 1 I guess you are executing that command inside the fpc/compiler directory. You have to execute it in the top level fpc directory. And you don't need the sudo for the make all, only for the make install Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Creating ppc386 from ppcx64
Thanks Jonas, I went a step further. Now, when I just do fpc, to I got this: Error: ppc386 can't be executed, error message: Failed to execute ppc386, error code: 127 What can be causing this? ...but I found the new ppc386 in /usr/local/lib/fpc/2.5.1/ppc386, so I tried to compile a sample program, and got this: ... ... /usr/bin/ld: warning: link.res contains output sections; did you forget -T? /usr/bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/libdl.a when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib//libdl.so when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib//libdl.a when searching for -ldl /usr/bin/ld: cannot find -ldl Error: Error while linking Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Any hint? Leonardo M. Ramé http://leonardorame.blogspot.com --- On Wed, 1/6/10, Jonas Maebe jonas.ma...@elis.ugent.be wrote: From: Jonas Maebe jonas.ma...@elis.ugent.be Subject: Re: [SPAM] [fpc-devel] Creating ppc386 from ppcx64 To: FPC developers' list fpc-devel@lists.freepascal.org Date: Wednesday, January 6, 2010, 5:31 PM On 06 Jan 2010, at 20:15, Leonardo M. Ramé wrote: To create the cross compiler, I'm following this guide: http://wiki.lazarus.freepascal.org/Cross_compiling#To_Linux When I do sudo make all CPU_TARGET=i386 I receive this message: /usr/bin/fpc -Pi386 -XPi386-linux- -Xr -Fui386 -Fusystems -Fu../rtl -Fii386 -FEs Error: ppc386 can't be executed, error message: Failed to execute ppc386, err7 make: *** [ppc386] Error 1 I guess you are executing that command inside the fpc/compiler directory. You have to execute it in the top level fpc directory. And you don't need the sudo for the make all, only for the make install Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [SPAM] Re: [fpc-devel] Creating ppc386 from ppcx64
On 06 Jan 2010, at 21:15, Leonardo M. Ramé wrote: Thanks Jonas, I went a step further. Now, when I just do fpc, to I got this: Error: ppc386 can't be executed, error message: Failed to execute ppc386, error code: 127 What can be causing this? Create a symlink from /usr/local/bin/ppc386 to /usr/local/lib/fpc/2.5.1/ppc386. fpc searches for a compiler in the same directory as where its own binary is located. make install does not create/overwrite such symlinks, because that changes your default compiler. /usr/bin/ld: cannot find -ldl Error: Error while linking Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Any hint? Install 32 bit compatibility libraries on your Linux distribution. If they are unavailable: tough luck, I guess (unless you setup an complete i386 cross-compilation environment on your system, but that's not FPC specific in any way and I can't help with that). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [SPAM] Re: [fpc-devel] Creating ppc386 from ppcx64
Thanks again Jonas, that worked ok!. Leonardo M. Ramé http://leonardorame.blogspot.com --- On Wed, 1/6/10, Jonas Maebe jonas.ma...@elis.ugent.be wrote: From: Jonas Maebe jonas.ma...@elis.ugent.be Subject: Re: [SPAM] Re: [fpc-devel] Creating ppc386 from ppcx64 To: FPC developers' list fpc-devel@lists.freepascal.org Date: Wednesday, January 6, 2010, 6:26 PM On 06 Jan 2010, at 21:15, Leonardo M. Ramé wrote: Thanks Jonas, I went a step further. Now, when I just do fpc, to I got this: Error: ppc386 can't be executed, error message: Failed to execute ppc386, error code: 127 What can be causing this? Create a symlink from /usr/local/bin/ppc386 to /usr/local/lib/fpc/2.5.1/ppc386. fpc searches for a compiler in the same directory as where its own binary is located. make install does not create/overwrite such symlinks, because that changes your default compiler. /usr/bin/ld: cannot find -ldl Error: Error while linking Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Any hint? Install 32 bit compatibility libraries on your Linux distribution. If they are unavailable: tough luck, I guess (unless you setup an complete i386 cross-compilation environment on your system, but that's not FPC specific in any way and I can't help with that). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Fatal: Compilation aborted
Hello, I'm doing my first steps in fp - and for a long time in Pascal again - and use the 2.4.0 version. I more or less often come into a situation, where the compiler simply tries to compile my program and just says (after a long list of infos - but not errors or warning): Compilation aborted (and boy: I have lots of syntax errors - it is 20 years agos when I did my last Pascal programming). Then I terminate fp, start it again, compile the same source code and get the error messages I need to fix my errors. Marten Feldtmann ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
