Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 19 Aug 2011, at 04:28, John Clymer wrote: > Did an analysis of the Stellaris current product lineup, there are over 180 > current Stellaris products on TI's selection guide. Boiling through the > FLASH and RAM availability, there are 31 unique configuratios of FLASH / SRAM > between those 180 devices. So, the case() statements in t_embed.pas will > have 31 more entries to completely support the entire line of Stellaris > processors (and a few more with products slated for future release). could it not just be two numeric command line options which are used to write the relevant strings to 'linkres'? This would be future proof. > > Currently, everything is in a handful of giant arrays. Just wondering if it > would be better to switch to a record structure for the controller entries - > rather than individual arrays. (Add in a variety of STM parts and the other > manufacturers, and there could easily be over 100 memory configurations in > the table.) > > Looking at RTL support. Currently for each ARM variant, they have a > contoller unit (the controllerunitstr entry). Inside the current controller > units, registers are defined. These registers definitions "automatically" > become part of the variable space of an application. Is the intent for ALL > controller registers be provided inside the RTL ? I would think this would > be better provided by outside files. (i.e. "uses LM3S8962" - brings in a > file containing all the 8962 register definitions.) I agree. The ones I included in 'stellaris.pas' were enough to get the basic system working with a non-trival test and to give anybody who took it further some suggestions which I found worked ok eg. putting the registers in absolute records. Really they should all be in separate files for each peripheral, then you only need to include whichever ones are relevant to the device you are actually using. > > Having an outside file (it would be akin to a C header file - interface only > specifications for the registers, and that would be it) would be much clearer > than hiding the details inside a "hidden" file. If the user wants to chase > down exactly where the definition is coming from, using a non-RTL file saves > the user from having to dig through the compiler source to determine where it > was coming from. (Although for a newb, it may be preferable to have them > automatigically available.) In fact I have subsequently been using the C header files for bit definitions after conversion using h2pas. This saved a lot of time. > > My suggestion would be that the register definitions come in an UNIT file > that only defines registers. The controller unit in the compiler source > would only provide the bare minimum necessary to bring the system up and call > PASCALMAIN. However, if it is deemed better to have the entire register set > defined inside the RTL - that would be fine too. Units are convenient too; you can include access methods alongside the register definitions. Geoffrey > > John > > From: Florian Klämpfl > To: FPC developers' list > Sent: Tue, August 9, 2011 7:59:06 PM > Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status > > Am 09.08.2011 17:04, schrieb Jeppe Græsdal Johansen: > > On 09-08-2011 15:53, Geoffrey Barton wrote: > >> > >> On 9 Aug 2011, at 14:14, John Clymer wrote: > >> > >>> I was thinking more of a generic controller class, including a > >>> memory.def (or whatever one wants to name it) file. That would be > >>> easiest as it would only effect the t_embed.pas file (and cpuinfo.pas > >>> file to add the generic type.) > >>> > >>> Haven't looked into possibly a compiler option (and may easily be > >>> more trouble than a command line option): > >>> {$ARM_FLASH_START } > >>> {$ARM_FLASH_LENGTH } > >>> {$ARM_SRAM_START } > >>> {$ARM_SRAM_LENGTH } > >>> > >>> But, I still think a static memory definition file would require the > >>> least amount of code changes. And would only effect only the ARM > >>> related files. > >> > >> The compiler option works well when you have conditional options for > >> different target builds using ifdefs, which I do I lot. It makes it > >> very easy to see if it is in the source file as it can be locked to > >> other options and you only need to select it in one place. > >> > >> A separate linker file starts to make FPC handle like any other > >> compiler :( instead of the joy to use it is :) > > I agree. Keeping the configurations in code is easier to manage, > > Yes. I think as well that everything should stick in the compiler. FPC > is open source, so no need for a convolution of compiler support and > external files. Full support of all devices will lead to a huge number > of interwinded include files in the rtl anyways. > > > compared to the spiderweb of magically named files of other embedded > > compilers > > > > I think that maybe creating an abstract class hierachy of chip families, > > instead o
Re: RE : [fpc-devel] serial under linux, SerOpen blocks
there must be a reason why minicom uses O_NDELAY (=O_NONBLOCK) in case O_NDELAY ist defined. Now i remember that i had the same problem several years ago with cat file >/dev/ttyUSB0, i think it was Fedora Core 3 or 4. I assume this does not only happen with a pl2303. #if defined(O_NDELAY) && defined(F_SETFL) portfd = open(dial_tty, O_RDWR|O_NDELAY|O_NOCTTY); if (portfd >= 0) { /* Cancel the O_NDELAY flag. */ n = fcntl(portfd, F_GETFL, 0); fcntl(portfd, F_SETFL, n & ~O_NDELAY); } #else if (portfd < 0) portfd = open(dial_tty, O_RDWR|O_NOCTTY); #endif On 08/18/2011 06:49 PM, Mark Morgan Lloyd wrote: Ludo Brands wrote: Some serial ports seem to have clocal unset, for some reason, which causes it to block on open (waiting for the modem status lines). Like you, I've never seen it with any of my serial ports, either. Might have to do with the defaulting to autobaud of some usbserial chips. ___ Apparently a bug in a recent usb serial kernel module pl2303: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/661321 Well spotted :-) I was going to speculate that it might be something to do with the Prolific driver- I think that the device I use most is FTDI. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Am 19.08.2011 05:28, schrieb John Clymer: > Currently, everything is in a handful of giant arrays. Just wondering > if it would be better to switch to a record structure for the controller > entries - rather than individual arrays. (Add in a variety of STM parts > and the other manufacturers, and there could easily be over 100 memory > configurations in the table.) Maybe it's indeed better to have an array of records, each record describing one controller. > > My suggestion would be that the register definitions come in an UNIT > file that only defines registers. The controller unit in the compiler > source would only provide the bare minimum necessary to bring the system > up and call PASCALMAIN. However, if it is deemed better to have the > entire register set defined inside the RTL - that would be fine too. Well, isn't it for a user easier just to pass the controller he uses on the command line and the compiler does the rest? Why bother with addional uses etc. if the compiler knows already anything? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 19 Aug 2011, at 09:19, Florian Klämpfl wrote: > Am 19.08.2011 05:28, schrieb John Clymer: >> Currently, everything is in a handful of giant arrays. Just wondering >> if it would be better to switch to a record structure for the controller >> entries - rather than individual arrays. (Add in a variety of STM parts >> and the other manufacturers, and there could easily be over 100 memory >> configurations in the table.) > > Maybe it's indeed better to have an array of records, each record > describing one controller. > >> >> My suggestion would be that the register definitions come in an UNIT >> file that only defines registers. The controller unit in the compiler >> source would only provide the bare minimum necessary to bring the system >> up and call PASCALMAIN. However, if it is deemed better to have the >> entire register set defined inside the RTL - that would be fine too. > > Well, isn't it for a user easier just to pass the controller he uses on > the command line and the compiler does the rest? Why bother with > addional uses etc. if the compiler knows already anything? because one is forever re-compiling the compiler when one switches to a device with a new peripheral, and if your main activity is not compiler development but product development one has to go back and find out how to do it each time. Better that the core stays the same. Geoffrey > ___ > 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] Arm Thumb2 - Stellaris status
Am 19.08.2011 10:33, schrieb Geoffrey Barton: > > because one is forever re-compiling the compiler when one switches to > a device with a new peripheral, and if your main activity is not > compiler development but product development one has to go back and > find out how to do it each time. Better that the core stays the > same. This is true, it makes things maybe easier for the first implementor, he hacks together some units and directives but it is harder for any latter user. He basically needs to do the same amount of work as the initial implementator: find out that he needs some directive, find the correct units etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 19 Aug 2011, at 09:55, Florian Klämpfl wrote: > Am 19.08.2011 10:33, schrieb Geoffrey Barton: >> >> because one is forever re-compiling the compiler when one switches to >> a device with a new peripheral, and if your main activity is not >> compiler development but product development one has to go back and >> find out how to do it each time. Better that the core stays the >> same. > > This is true, it makes things maybe easier for the first implementor, he > hacks together some units and directives but it is harder for any latter > user. He basically needs to do the same amount of work as the initial > implementator: find out that he needs some directive, find the correct > units etc. exactly so, IMHO! (and in my own experience). If all he needs to add are a few peripheral definitions and drivers and there have been provided some examples of structures which work well in practice for these, a new user can be doing useful work very quickly and contributing to the collective knowledge from day one. G > ___ > 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] Arm Thumb2 - Stellaris status
Am 19.08.2011 11:07, schrieb Geoffrey Barton: > > On 19 Aug 2011, at 09:55, Florian Klämpfl wrote: > >> Am 19.08.2011 10:33, schrieb Geoffrey Barton: >>> >>> because one is forever re-compiling the compiler when one >>> switches to a device with a new peripheral, and if your main >>> activity is not compiler development but product development one >>> has to go back and find out how to do it each time. Better that >>> the core stays the same. >> >> This is true, it makes things maybe easier for the first >> implementor, he hacks together some units and directives but it is >> harder for any latter user. He basically needs to do the same >> amount of work as the initial implementator: find out that he needs >> some directive, find the correct units etc. > > exactly so, IMHO! (and in my own experience). > > If all he needs to add are a few peripheral definitions and drivers > and there have been provided some examples of structures which work > well in practice for these, a new user can be doing useful work very > quickly and contributing to the collective knowledge from day one. What I mean is: if the first user of a controller does things properly (create startup and interface unit, extend t_embedded.pas), subsequent users of the same controller have much less work, they need only to pass the correct parameter to the compiler and not to fiddle with configuration files, directives etc. The compiler takes care of everything. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 19 Aug 2011, at 10:10, Florian Klämpfl wrote: > Am 19.08.2011 11:07, schrieb Geoffrey Barton: >> >> On 19 Aug 2011, at 09:55, Florian Klämpfl wrote: >> >>> Am 19.08.2011 10:33, schrieb Geoffrey Barton: because one is forever re-compiling the compiler when one switches to a device with a new peripheral, and if your main activity is not compiler development but product development one has to go back and find out how to do it each time. Better that the core stays the same. >>> >>> This is true, it makes things maybe easier for the first >>> implementor, he hacks together some units and directives but it is >>> harder for any latter user. He basically needs to do the same >>> amount of work as the initial implementator: find out that he needs >>> some directive, find the correct units etc. >> >> exactly so, IMHO! (and in my own experience). >> >> If all he needs to add are a few peripheral definitions and drivers >> and there have been provided some examples of structures which work >> well in practice for these, a new user can be doing useful work very >> quickly and contributing to the collective knowledge from day one. > > What I mean is: if the first user of a controller does things properly > (create startup and interface unit, extend t_embedded.pas), subsequent > users of the same controller have much less work, they need only to pass > the correct parameter to the compiler and not to fiddle with > configuration files, directives etc. The compiler takes care of everything. and I agree with you 100%. as the 'first user' though I had other pressures on me, such as having to prove that using FPC on Stellaris was viable so that I could avoid being forced into writing in C. I therefore concentrated on the one device I had on the evm; maybe thats what everybody does. Then one looks for the time to tidy things up, or for someone else to come along wanting to go the same route and needing a jump-start. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
So, consensus is to include the register definitions - then I will work on these. To get all the possible register structures for all possible peripherals will take some time. And naming conventions come into play as well. I prefer having my device registers defined in structures. Other people prefer non-structured "flat" definitions for the registers. i.e. PortA -> DDR PortA -> PIN vs. DDRA PINA The current stellaris has a start for structures, unless there are objections, I would continue with these. The actual names of the registers will be best to match the datasheet (otherwise, non-compiler writing / source reading people will need a manual [and somewhat lengthy one at that] to provide the correcting naming of each peripheral and register.) BUT - there is no standard for what the peripheral structure instances should be named - so again, this would need to be documented if the target audience is people that won't be tearing the compiler apart. [And again, more work...] John From: Geoffrey Barton To: FPC developers' list Sent: Fri, August 19, 2011 1:19:38 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status On 19 Aug 2011, at 10:10, Florian Klämpfl wrote: > Am 19.08.2011 11:07, schrieb Geoffrey Barton: >> >> On 19 Aug 2011, at 09:55, Florian Klämpfl wrote: >> >>> Am 19.08.2011 10:33, schrieb Geoffrey Barton: because one is forever re-compiling the compiler when one switches to a device with a new peripheral, and if your main activity is not compiler development but product development one has to go back and find out how to do it each time. Better that the core stays the same. >>> >>> This is true, it makes things maybe easier for the first >>> implementor, he hacks together some units and directives but it is >>> harder for any latter user. He basically needs to do the same >>> amount of work as the initial implementator: find out that he needs >>> some directive, find the correct units etc. >> >> exactly so, IMHO! (and in my own experience). >> >> If all he needs to add are a few peripheral definitions and drivers >> and there have been provided some examples of structures which work >> well in practice for these, a new user can be doing useful work very >> quickly and contributing to the collective knowledge from day one. > > What I mean is: if the first user of a controller does things properly > (create startup and interface unit, extend t_embedded.pas), subsequent > users of the same controller have much less work, they need only to pass > the correct parameter to the compiler and not to fiddle with > configuration files, directives etc. The compiler takes care of everything. and I agree with you 100%. as the 'first user' though I had other pressures on me, such as having to prove that using FPC on Stellaris was viable so that I could avoid being forced into writing in C. I therefore concentrated on the one device I had on the evm; maybe thats what everybody does. Then one looks for the time to tidy things up, or for someone else to come along wanting to go the same route and needing a jump-start. ___ 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] Arm Thumb2 - Stellaris status
Am 19.08.2011 12:02, schrieb John Clymer: > So, consensus is to include the register definitions - then I will work > on these. To get all the possible register structures for all possible > peripherals will take some time. And naming conventions come into play > as well. > > I prefer having my device registers defined in structures. Other people > prefer non-structured "flat" definitions for the registers. > > i.e. > > PortA -> DDR > PortA -> PIN > > vs. > > DDRA > PINA > > The current stellaris has a start for structures, unless there are > objections, I would continue with these. > > The actual names of the registers will be best to match the datasheet > (otherwise, non-compiler writing / source reading people will need a > manual [and somewhat lengthy one at that] to provide the correcting > naming of each peripheral and register.) BUT - there is no standard for > what the peripheral structure instances should be named - so again, this > would need to be documented if the target audience is people that won't > be tearing the compiler apart. [And again, more work...] Afaik there is a standard for the Cortex platform how to do it, google for "ARM Cortex Microcontroller Software Interface Standard" ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
On 08/17/2011 06:49 PM, David W Noon wrote: Perhaps the slower execution speed of CIL (.NET, Mono) byte code masks the context switching overheads and makes this practice look less inefficient. I doubt that this is the case. AFAIK, CIL code is not necessarily much slower than native code. (Of course it can be much slower, especially when garbage collection is necessary.) But when using a parallel loop "decently" i.e. for doing not too short unrelated calculations with only so many parallel threads as processors are available, this is supposed to grant a good speedup. AFAIK with prism the parallel loop automatically is broken into as many parallel threads as available processors, thus avoiding additional context switches. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
On 08/17/2011 06:03 PM, David W Noon wrote: I am (reasonably so, at least). Where is the parallel aspect? As I said I just did a quick search in the FAQ. Does C++11 also provide a more "automatic" parallel processing feature than just something similar to worker threads (Object Pascal TThread), maybe similar to Prism's "parallel loop" ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 08/17/2011 11:57 PM, Graeme Geldenhuys wrote: Why define a UI with co-ordinates, then sit with problems like overlapping components, components that don't scale, locked to a specific DPI etc. This is similar to HTML vs PDF. PDF always looks the same _if_ it can be displayed at all. HTML (hopefully) can be displayed everywhere but only in very rare cases really looks "right" (unless the designer imposed harsh restrictions). And printing HTML pages in fact is a nightmare. So maybe it's not possible to definitely choose one vs the other. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] overloaded SetFieldData/GetFieldData
Hi, I found this it fpc-pascal mailing list archive (I do not read this mailing list, so I do not catch this discussion) Because I think it is worth to continue, I move it into fpc-devel / ... I feel the definition />/ of SetFieldData/GetFieldData without a length/size parameter />/ and strings passed as pchar is causing all kind of problems: /I agree/ />/ 1) TStringField.SetAsString copies the string to a buffer />/ with size dsMaxStringSize so that datasets that don't figure />/ out the original length of the string can simply copy the />/ full Field.TDatasize (TBufDataset, TDbf, TMemDataset,...). /Yes/ />/ TWideStringField.SetAsString didn't which caused the crash />/ when the string is shorter than Field.Size. />/ TCustomSqliteDataset uses a StrNew(PChar(Buffer)); to get the />/ length of the string but fails sometimes (see 4). />/ 2) dsMaxStringSize isn't enforced for TStringField. Defining />/ a Field.size > dsMaxStringSize causes a crash in />/ TStringField.SetAsString. I haven't raised an issue on this, yet. / Yes, it is also reported by fcl-db test suite, see: http://bugs.freepascal.org/view.php?id=19940 / 3) some of the speed advantage of memory based datasets is />/ offset by moving full Field.Tdatasize bytes in both set and />/ get fielddata / / 4) pascal strings can contain #0 characters in the string. />/ When converting to pchar part of these strings is lost. />/ /Very good point. See also comments in http://bugs.freepascal.org/view.php?id=19930 / />/ What I propose is: />/ 1 to create overloaded versions of SetFieldData and />/ GetFieldData that include a length parameter, to change />/ TStringField.SetAsString and TWideStringField.SetAsWideString />/ to use these versions /Or also create procedure TField.SetData(Buffer: Pointer; DataSize : integer=0); which will do some checks like existing TField.SetData(Buffer: Pointer; NativeFormat : Boolean) and call new FDataSet.SetFieldData(Self, Buffer, NativeFormat, DataSize); This new TDataSet.SetFieldData will by default call existing "old" SetFieldData: procedure TDataSet.SetFieldData(Field: TField; Buffer: Pointer; NativeFormat: Boolean; DataSize:integer); begin SetFieldData(Field, Buffer, NativeFormat); end; So backward compatibilty will be retained. TDataSet descendants, which will want, they will override this new SetFieldData method and will take advantage of them. (in our case TBufDataSet will be adopted ) / and to migrate the different datasets />/ to use these new versions. This way existing (user) code />/ using SetFieldData/GetFieldData will still work (and the user />/ still being responsible for buffer overruns...) and datasets />/ can correctly save and retrieve strings while improving performance. />/ 2 change the bufdataset internal storage for ftstring and />/ ftwidestring fields to include the string length so that />/ stored strings can be retrieved in full when containing #0 />/ characters and without having to copy systematically datasize />/ bytes. / Yes, so ftString will be stored like ftvarBinary, which has first two bytes length and followed by "binary string" / However this will introduce an incompatible binary />/ format for TFpcBinaryDatapacketReader. Having a second />/ FpcBinaryIdent would allow for both formats to co-habitate. />/ />/ If need be the discussion can be moved to fpc-devel. /Yes ;-)))/ /And another theme not related to this subjects are Autoincrement fields, which are ATM read-only for all access (BTW see also http://bugs.freepascal.org/view.php?id=17624 ) Here I have idea introduce at some level (TDataSet or TBufDataSet) virtual function (for example GetNextAutoIncValue), which will be called just after append...post (may be in InternalPost if State=dsInsert) And descendants like TSQLQuery will be able override this method and provide their own mechanism for retrieving auto-generated values from SQL databases. Like MySQL: select last_insert_rowid(), PostgreSQL: select lastval(), MSSQL: select @@identity, etc. For other solution (introduce new property RefreshSQL ) read: http://bugs.freepascal.org/view.php?id=16076 ATM auto-increment fields are practicaly useless. Ofcourse this are only very raw ideas ... TIA -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 19 Aug 2011, at 11:11, Florian Klämpfl wrote: > Am 19.08.2011 12:02, schrieb John Clymer: >> So, consensus is to include the register definitions - then I will work >> on these. To get all the possible register structures for all possible >> peripherals will take some time. And naming conventions come into play >> as well. >> >> I prefer having my device registers defined in structures. Other people >> prefer non-structured "flat" definitions for the registers. >> >> i.e. >> >> PortA -> DDR >> PortA -> PIN surely porta.ddr >> >> vs. >> >> DDRA >> PINA >> >> The current stellaris has a start for structures, unless there are >> objections, I would continue with these. >> >> The actual names of the registers will be best to match the datasheet >> (otherwise, non-compiler writing / source reading people will need a >> manual [and somewhat lengthy one at that] to provide the correcting >> naming of each peripheral and register.) yes, it would be best to take them from the C definitions in 'stellarisware'. I shortened and changed some of them as they were unnecessarily flowery or obscure. >> BUT - there is no standard for >> what the peripheral structure instances should be named - so again, this >> would need to be documented if the target audience is people that won't >> be tearing the compiler apart. [And again, more work...] > > Afaik there is a standard for the Cortex platform how to do it, google > for "ARM Cortex Microcontroller Software Interface Standard" there is a generic doc on the arm.com site and a stellaris specific one on the TI site. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On Aug 19, 2011 7:13 AM, "Geoffrey Barton" wrote: > > > Afaik there is a standard for the Cortex platform how to do it, google > > for "ARM Cortex Microcontroller Software Interface Standard" > > there is a generic doc on the arm.com site and a stellaris specific one on the TI site. Following the CMSIS would definitely make development easier, but it comes with a tradeoff. The generic nature of it makes it very wordy and somewhat inefficient (sometimes you have to make several function calls to do what a single assign could do). If possible, it might be best to have the compiler expose the raw registers, and add CMSIS as a unit that can be included in your application source. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
On Fri, 19 Aug 2011 12:30:43 +0200, Michael Schnell wrote about Re: [fpc-devel] C++ gets language-internal concurrency support: >On 08/17/2011 06:49 PM, David W Noon wrote: >> Perhaps the slower execution speed of CIL (.NET, >> Mono) byte code masks the context switching overheads and makes this >> practice look less inefficient. > >I doubt that this is the case. AFAIK, CIL code is not necessarily much >slower than native code. (Of course it can be much slower, especially >when garbage collection is necessary.) That is not my experience. While CIL byte code interprets much faster than Java byte code, it is still discernibly slower than native object code. [Or perhaps my C# is not that good.] >But when using a parallel loop "decently" i.e. for doing not too short >unrelated calculations with only so many parallel threads as >processors are available, this is supposed to grant a good speedup. My experience with OpenMP is that it is difficult to write a loop body large enough that context switching does not overwhelm the benefits of parallelism. >AFAIK with prism the parallel loop automatically is broken into as >many parallel threads as available processors, thus avoiding >additional context switches. Threads are not tied to processors. This is especially true in "managed" languages, where threads usually have process scope and consequently all run on the same CPU. [I.e. a thread with process scope cannot have CPU affinity distinct from that of the main thread in the process, whereas a thread with system scope can run wherever the operating system's CPU dispatcher sends it, possibly constrained by that thread's own CPU affinity mask.] The reason the "managed" languages typically use process scoped threads is that the threads are dispatched by the language's thread manager, not the operating system. This gives the thread manager total control over the threads, but it does mean that each thread is simply "called" in its turn and so runs on the same CPU as the thread manager; any request that would block the thread forces a return to the thread manager, which gives another thread a run, etc. I might do some experiments in C# to see if the thread manager creates threads with process scope or system scope, as it might be a bit smarter than Java's "green threads". -- Regards, Dave [RLU #314465] === david.w.n...@ntlworld.com (David W Noon) === signature.asc Description: PGP signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
On 19 Aug 2011, at 14:15, David W Noon wrote: I might do some experiments in C# to see if the thread manager creates threads with process scope or system scope, as it might be a bit smarter than Java's "green threads". According to wikipedia, Java stopped using the green threads model after JDK 1.1. I'm pretty sure that all Java threads are native threads on today's implementations (at least on desktop and server platforms). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
On 08/19/2011 02:15 PM, David W Noon wrote: That is not my experience. While CIL byte code interprets much faster than Java byte code, it is still discernibly slower than native object code. Hmm. I don't have any personal experience with this, but from what I read, this idea with CIL is to split the normal compile procedure that does (1) code analysis, high level optimizing and creating an intermediate code that is independent of the original language and the target CPU and (2) low level optimization and target code generation and perform the second step on the target system when loading. So it does not _need_ do run slower (it _needs_ to load slower, though). But of course a really good "full" compiler might do a better optimizing job. Regarding code snippets that are worth to be done in parallel (e.g. calculating a cell in a Matrix Multiplication) should not be highly prone to speed degradation by CIL. [Or perhaps my C# is not that good.] I doubt that this is the case :) . -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
On 08/19/2011 02:15 PM, David W Noon wrote: My experience with OpenMP is that it is difficult to write a loop body large enough that context switching does not overwhelm the benefits of parallelism. Hmmm. If you do a multiplication of a 100*100 Matrix you could spawn 1 threads and this will result in a huge switching overhead. But if you have 10 cores and you aggregate the 1 tasks in 10 groups of 1000 calculations each, spawn 10 threads and have each go through a loop of calculating 1000 cells, I gather that (in a perfect world) no task switching overhead at all would be necessary (but at the beginning and the end of the complete calculation). If in Prism you do something like (pseudo-code draft): m := 100; n := 100 for parallel ij := 0 to m*n-1 do begin i := ij mod m; j := ij div m; calccell (i,j); end; I understand that Prism (or rather .NET) on a 10 core machine automatically would create 10 threads each doing 1000 cells. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
On 08/19/2011 02:15 PM, David W Noon wrote: Threads are not tied to processors. I do know that in Linux the scheduler tries to keep a thread in a core if possible (even after re-scheduling the thread after preemption). This greatly increases cache performance. This is especially true in "managed" languages, where threads usually have process scope and consequently all run on the same CPU. [I.e. a thread with process scope cannot have CPU affinity distinct from that of the main thread in the process, whereas a thread with system scope can run wherever the operating system's CPU dispatcher sends it, possibly constrained by that thread's own CPU affinity mask.] While I do understand what you mean, I never heard that defining CPU affinity in a way that a process only is allowed to use one core for all it's threads. If this is set, of course parallel tasks don't make any sense at all. I suppose that this can be set for special purposes, but I don't thinks that it's a standard setting (e.g. in Linux). As a growing "class" of programs are defined to take advantage from a multi-core System - and I suppose most do this by distributing cycle-hungry tasks towards multiple threads - I understand that the normal way of the OS is to allow for multiple CPUs for a single application. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ gets language-internal concurrency support
On 08/19/2011 02:15 PM, David W Noon wrote: I might do some experiments in C# to see if the thread manager creates threads with process scope or system scope, as it might be a bit smarter than Java's "green threads". I remember that there once was a version of the PThreadLib that used an internal userland scheduler for handling the threads. Here of course only one thread is visible to the OS and thus only one CPU is used. So the "green Thread" Model is available in C (and FPC), as well. I suppose this library is not much in use any more. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc fails to link against libc on some architectures due to multiarch
tags 636802 +patch thanks Note: jonas's reply was only posted to fpc-devel, not to the debian bug report , a copy can be found at http://lists.freepascal.org/lists/fpc-devel/2011-August/025444.html Jonas Maebe wrote: Is there a standard for multiarch library path locations and names? Multiarch seems to be a debian/ubuntu creation. Debian and ubuntu seem to be consistent at least on i386 and amd64. I'm not sure what the situation is with arm ports of ubuntu (note that multiarch triplets are supposed to represent an ABI so two arm ports with incompatible ABIs are supposed to have different multiarch triplets). If not, that sounds like configuration option that should be added by distribution-specific patches. I've attatched a patch to debian/rules to add the multiarch path to the configuration installed by the debian package. --- fpc-2.4.4/debian/rules 2011-07-04 22:41:08.0 +0100 +++ fpc-2.4.4.new/debian/rules 2011-08-18 08:35:48.0 +0100 @@ -62,6 +62,7 @@ DEB_UPSTREAM_VERSION:=$(shell echo $(DEB_VERSION) | cut -f 1 -d -) DEB_UPSTREAM_MAIN_VERSION:=$(shell echo ${DEB_UPSTREAM_VERSION} | sed -e 's/^\([0-9\.]*\).*/\1/') DEB_BUILD=$(lastword $(subst -, ,${DEB_VERSION})) +DEB_BUILD_MULTIARCH:=$(shell dpkg-architecture -qDEB_BUILD_MULTIARCH) ifndef PACKAGESUFFIX export PACKAGESUFFIX=-${DEB_UPSTREAM_MAIN_VERSION} endif @@ -205,6 +206,9 @@ # Install configuration files /bin/bash fpcsrc/compiler/utils/samplecfg \ /usr/lib/fpc/${DEB_UPSTREAM_VERSION} ${INSTALL_DIR}/etc + # Add multiarch path to /etc/fpc.cfg so executables linked against libc can be corectly linked + echo # multiarch library search path >> ${INSTALL_DIR}/etc/fpc.cfg + echo -Fl/usr/lib/$(DEB_BUILD_MULTIARCH) >> ${INSTALL_DIR}/etc/fpc.cfg ${MV} ${INSTALL_DIR}/etc/fpc.cfg ${INSTALL_DIR}/etc/fpc-${DEB_UPSTREAM_MAIN_VERSION}.cfg # Install RTL demos $(MAKE) -C demo sourceinstall $(INSTALLOPTS) INSTALL_SOURCEDIR=$(DOC_DIR)/fp-compiler/${DEB_UPSTREAM_MAIN_VERSION} ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] thumb2 code generation
Someone pointed me at this page: http://wiki.freepascal.org/TARGET_Embedded And I started adding a device (and perhaps more after that), starting with a cortex-m3 though which is thumb/thumb2 only. Following the instructions on the page work fine: fpc -Parm -Tembedded -Wplpc2124 tled1.pp Added my device as well as tried the two other cortex-m3 devices and fpc -Parm -Tembedded -Wpdevice test.pp I tried -Parm, -Pthumb, thumb2, cortex-m3 but it just keeps generating arm instructions. I can certainly target an arm processor first but would rather try a thumb/thumb2 first. Thanks, David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] thumb2 code generation
Actually I would prefer thumb first then thumb2 cpuinfo.pas does not have an architecture tied to thumb but the cortexm3 and armv7m can be easily moved to thumb temporarily or create say a cpu_cortexm3_thumb in the tcputype list, etc... David On 08/19/2011 11:00 PM, David Welch wrote: Someone pointed me at this page: http://wiki.freepascal.org/TARGET_Embedded And I started adding a device (and perhaps more after that), starting with a cortex-m3 though which is thumb/thumb2 only. Following the instructions on the page work fine: fpc -Parm -Tembedded -Wplpc2124 tled1.pp Added my device as well as tried the two other cortex-m3 devices and fpc -Parm -Tembedded -Wpdevice test.pp I tried -Parm, -Pthumb, thumb2, cortex-m3 but it just keeps generating arm instructions. I can certainly target an arm processor first but would rather try a thumb/thumb2 first. Thanks, David ___ 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] thumb2 code generation
Sorry, figured it out -Cpcortexm3 On 08/19/2011 11:05 PM, David Welch wrote: Actually I would prefer thumb first then thumb2 cpuinfo.pas does not have an architecture tied to thumb but the cortexm3 and armv7m can be easily moved to thumb temporarily or create say a cpu_cortexm3_thumb in the tcputype list, etc... David On 08/19/2011 11:00 PM, David Welch wrote: Someone pointed me at this page: http://wiki.freepascal.org/TARGET_Embedded And I started adding a device (and perhaps more after that), starting with a cortex-m3 though which is thumb/thumb2 only. Following the instructions on the page work fine: fpc -Parm -Tembedded -Wplpc2124 tled1.pp Added my device as well as tried the two other cortex-m3 devices and fpc -Parm -Tembedded -Wpdevice test.pp I tried -Parm, -Pthumb, thumb2, cortex-m3 but it just keeps generating arm instructions. I can certainly target an arm processor first but would rather try a thumb/thumb2 first. Thanks, David ___ 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 maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Also, just peeked at current line up of STM32 controllers, there are 150 different controllers available, consisting of 33 possible combinations of FLASH memory and SRAM size. I will try to get the controller specific parts boiled up into record structures this weekend, and get some added controllers installed into cpuinfo.pas. (And fix any compiler breakages from the change.) I have the SVN download - so generated diffs should be a bit easier (still learning SVN though...) Also, I read through the ARM docs regarding the "standard" library - and can setup registers based on the each vendors published "C" library so they match the ARM/vendor docs. However, as each controller in the line-up has only certain peripherals, is it the intention that EACH controller gets it's own controller file with memory definitions for peripherals ? That's 300+ unit files between STM32 and TI's Stellaris line-ups. OR - does one try to merge as many controllers into 1 memory definition as possible. i.e. ALL of stellaris could be defined for the maximal configuration of peripherals (as they have a standard mapping layout for peripherals i.e. ALL LM3 devices have UART0 at the exact same location - and all have the same register layout.) The caveat to this that one could compile code that won't actually run on a given device. OR - we could leave the peripheral definitions to the user. (Which I'm assuming is not the preferred route.) John From: Florian Klämpfl To: FPC developers' list Sent: Fri, August 19, 2011 12:19:05 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status Am 19.08.2011 05:28, schrieb John Clymer: > Currently, everything is in a handful of giant arrays. Just wondering > if it would be better to switch to a record structure for the controller > entries - rather than individual arrays. (Add in a variety of STM parts > and the other manufacturers, and there could easily be over 100 memory > configurations in the table.) Maybe it's indeed better to have an array of records, each record describing one controller. > > My suggestion would be that the register definitions come in an UNIT > file that only defines registers. The controller unit in the compiler > source would only provide the bare minimum necessary to bring the system > up and call PASCALMAIN. However, if it is deemed better to have the > entire register set defined inside the RTL - that would be fine too. Well, isn't it for a user easier just to pass the controller he uses on the command line and the compiler does the rest? Why bother with addional uses etc. if the compiler knows already anything? ___ 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