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 flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
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 of the current solution of a single large case statement, would
be a better solution in the long run
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 m...@periphon.net To: FPC developers' list fpc-devel@lists.freepascal.org 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 m...@periphon.net 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
