[fpc-devel] BlackFin

HI FP experts. Is there any decent chance that there is or that it's possible to create a cross compiler to run FP programs on an Analog Devices BlackFin CPU that runs the appropriate Linux distribution ? -Michael ___ fpc-devel maillist - [EMAIL P

[fpc-devel] Blackfin support

Hello, Does FPC capable of supporting blackfin(and others in it's family) CPU ? It seems that more and more embedded projects starting to use it. Ido http://ik.homelinux.org/ ___ fp

Re: [fpc-devel] BlackFin

Michael Schnell schrieb: > HI FP experts. > > Is there any decent chance that there is or that it's possible to create > a cross compiler to run FP programs on an Analog Devices BlackFin CPU > that runs the appropriate Linux distribution ? No. Not without pushing a port to it in some way. ___

Re: [fpc-devel] BlackFin

No. Not without pushing a port to it in some way. Thanks. And I suppose doing a port for that processor would be quite a lot of work, regarding the ASM code is very strange if you compare it to the code of 80x86, PPC or ARM. -Michael ___ fpc-de

Re: [fpc-devel] BlackFin

Michael Schnell schrieb: > >> No. Not without pushing a port to it in some way. >> > Thanks. And I suppose doing a port for that processor would be quite a > lot of work, Well, this depends how good one wants to make such a port ... > regarding the ASM code is very strange if you compare it

Re: [fpc-devel] BlackFin

Hi! > > regarding the ASM code is very strange if you compare it to > > the code of 80x86, PPC or ARM. > > As far as I have seen the BlackFin has two cores: an arm like risc core > and a dsp. The BlackFin and other Analog Devices DSPs have an uncommon assembler syntax. Contrary to well-known mne

Re: [fpc-devel] BlackFin

Florian, Thanks a lot for discussing this ! Well, this depends how good one wants to make such a port ... In this case the (first version of the) port does not need to be very "good" (in the sense of creating optimized code), but of course the compiler needs to produce correct code that perf

Re: [fpc-devel] BlackFin

r2 = r1 + r3, r4 = dm(i0,m1); /* addition and memory access */ Yep. In my answer to Florian I forgot that (other than ARM) the Blackfin can do a calculation and a memory access in a single instruction cycle. That explains the much better performance even with standard (non-DSP-alike) ta

Re: [fpc-devel] BlackFin

Hi! Am Montag, den 16.04.2007, 11:57 +0200 schrieb Michael Schnell: > > r2 = r1 + r3, r4 = dm(i0,m1); /* addition and memory access */ > > > Yep. In my answer to Florian I forgot that (other than ARM) the Blackfin > can do a calculation and a memory access in a single instruction cycle. >

Re: [fpc-devel] BlackFin

Michael Schnell schrieb: > Florian, Thanks a lot for discussing this ! >> Well, this depends how good one wants to make such a port ... >> > In this case the (first version of the) port does not need to be very > "good" (in the sense of creating optimized code), but of course the > compiler need

RE: [fpc-devel] BlackFin

> Michael Schnell schrieb: > > Florian, Thanks a lot for discussing this ! Big thanks from me too! > Coding the compiler part isn't that hard. I can do this, I > did the initial arm port within a few weeks. The more > annoying part is doing the debugging and find the things > being broke

RE: [fpc-devel] BlackFin

> > Big thanks from me too! > > > Coding the compiler part isn't that hard. I can do this, > I > did the initial arm port within a few weeks. The more > > annoying part is doing the debugging and find the things > > being broken. > > We have to start a research hardware project

RE: [fpc-devel] BlackFin

Hi! > Sorry, i forgot to mention a valuable source of information: > > http://www.bluetechnix.at/ Coincidental I'm (partly) working for this company and know their staff quite well. If you need any assistance or similar I'd be happy to help out. Bye Hansi ___

Re: [fpc-devel] BlackFin

We have to start a research hardware project end of may, and are also in the middle between choosing an ARM/FPC way or a blackfin/non fpc way. This discussions opens a new possibility, which I would gratly favour. Great to know that I am not the only one ! :-) -Michael __

Re: [fpc-devel] BlackFin

If you're interested, start a wiki page with some information where to get docs, tools, info about calling conventions etc. Thanks for the encouragement ! Next month I'll see an FAE who just started supporting the BlackFin line. After that I hope I can see a bit clearer. -Michael __

Re: [fpc-devel] Blackfin support

On 07/09/2010 01:22 PM, ik wrote: Does FPC capable of supporting blackfin (and others in it's family) CPU ? It seems that more and more embedded projects starting to use it. No. In fact I did a (quite low priority) re

Re: [fpc-devel] Blackfin support

Hi Michael I too am planning to switch to 'sitara' AM3517 SBCs from at91sam9263. Hope there would be an effort to an fpc port to this board on linux-uclibc. regards Nataraj On Fri, Jul 9, 2010 at 5:19 PM, Michael Schnell wrote: > On 07/09/2010 01:22 PM, ik wrote: > > > Does FPC capable of s

Re: [fpc-devel] Blackfin support

On 07/09/2010 01:55 PM, Nataraj S Narayan wrote: Hi Michael I too am planning to switch to 'sitara' AM3517 SBCs from at91sam9263. Hope there would be an effort to an fpc port to this board on linux-uclibc. I understand that the Cortex A8 which powers the AM3x features the full 32 bit "ARM

Re: [fpc-devel] Blackfin support

I would be interested in knowing whether it would be feasible to create DSP backends for FPC. I recently had the experience of using a TMS320C26 which probably has to be programmed in assembler due to the limits of the instruction set. But I hear newer DSPs use instruction sets geared alot more

Re: [fpc-devel] Blackfin support

On 07/09/2010 02:36 PM, Jeppe Johansen wrote: Cortex A8 runs ARMv7A. All the Interlocked* functions in the ARM RTL already have implementations for ARMv6 instructions(ldrex/strex) which is pretty much what the architecture manual wrote as example code I do know this. But as at compile time the

Re: [fpc-devel] Blackfin support

BTW.: The v5 workaround code not only is less efficient (doing busy splinocks), it also creates potential deadlocks in certain cases (realtime priority), is not 100% secure and it might be that certain chips even fail handling the swap instruction atomicly and thus the code will not work at

Re: [fpc-devel] Blackfin support

Jeppe Johansen schrieb: > I would be interested in knowing whether it would be feasible to create > DSP backends for FPC. As usual: a matter of time. > I recently had the experience of using a TMS320C26 > which probably has to be programmed in assembler due to the limits of > the instruction set

Re: [fpc-devel] Blackfin support

Michael Schnell schrieb: > BTW.: > The v5 workaround code not only is less efficient (doing busy > splinocks), it also creates potential deadlocks in certain cases > (realtime priority), is not 100% secure and it might be that certain > chips even fail handling the swap instruction atomicly and th

Re: [fpc-devel] Blackfin support

On 07/09/2010 03:44 PM, Florian Klaempfl wrote: Maybe you should write a patch before you have to repeat this for the next ten years. As already said in the other thread I'll do this as soon as I will have the appropriate equipment to test it. Until that point of time I only can do research

Re: [fpc-devel] Blackfin support

Florian Klaempfl skrev: I recently had the experience of using a TMS320C26 which probably has to be programmed in assembler due to the limits of the instruction set. But I hear newer DSPs use instruction sets geared alot more towards highlevel compilers Michael: Cortex A8 runs ARMv7A. All the In

Re: [fpc-devel] Blackfin support

Jeppe Johansen schrieb: >> Yes, but the code is not selected dynamically: if one compiles for armv5 >> but runs it on a armv6+, the armv6 doesn't use the new instructions. > True, but do you think anyone does that? :) Most people know what end > hardware their programs will run on > > I don't thin

Re: [fpc-devel] Blackfin support

Florian Klaempfl schrieb: > Jeppe Johansen schrieb: >>> Yes, but the code is not selected dynamically: if one compiles for armv5 >>> but runs it on a armv6+, the armv6 doesn't use the new instructions. >> True, but do you think anyone does that? :) Most people know what end >> hardware their progra

Re: [fpc-devel] Blackfin support

On 07/09/2010 03:52 PM, Jeppe Johansen wrote: True, but do you think anyone does that? :) Most people know what end hardware their programs will run on in fact to work decently, the v5 version needs Kernel support (if an interrupt is issued while doing the atomic stuff) that only is possible

Re: [fpc-devel] Blackfin support

Florian Klaempfl wrote on Fri, 09 Jul 2010: Florian Klaempfl schrieb: Well, you can always assemble for ARMv6 but use only ARMv5 instructions when running on ARMv5. This is what the rtl does with the PLD instruction in system.move: a system.move procedure with PLD is only used when the CPU supp

Re: [fpc-devel] Blackfin support

Michael Schnell schrieb: In fact I did a (quite low priority) research on how to port FPC to a new CPU such as NIOS and Blackfin and found that it of course is doable somehow. While NIOS seems to look more doable, as it's quite similar to MIPS (and ARM), Blackfin has a much more complex instru

Re: [fpc-devel] Blackfin support

Jeppe Johansen schrieb: I would be interested in knowing whether it would be feasible to create DSP backends for FPC. I recently had the experience of using a TMS320C26 which probably has to be programmed in assembler due to the limits of the instruction set. But I hear newer DSPs use instruct

Re: [fpc-devel] Blackfin support

Hans-Peter Diettrich schrieb: Jeppe Johansen schrieb: I would be interested in knowing whether it would be feasible to create DSP backends for FPC. I recently had the experience of using a TMS320C26 which probably has to be programmed in assembler due to the limits of the instruction set. But

Re: [fpc-devel] Blackfin support

On 07/10/2010 12:40 PM, Hans-Peter Diettrich wrote: Let me know if you (or somebody else) has more concrete plans on the integration of a new CPU. I remember some discussions about doing a MIPS / PIC32 port recently I just stripped down the machine files for a no_cpu machine (all fakes), wi

Re: [fpc-devel] Blackfin support

Michael Schnell schrieb: I just stripped down the machine files for a no_cpu machine (all fakes), with some documentation about the required units etc. Is this based on what we already have for X86, ARM, etc, or does it "fork" to another set of ARC implementations ? If "fork", is it intended

Re: [fpc-devel] Blackfin support

Hans-Peter Diettrich schrieb: > But since some abstract links already exist (class type > variables for machine specific descendants), these links could be > exchanged at runtime, One problem are all the used constants describing the target architecture. We discussed multiple back-ends in one com

Re: [fpc-devel] Blackfin support

Florian Klaempfl schrieb: Hans-Peter Diettrich schrieb: But since some abstract links already exist (class type variables for machine specific descendants), these links could be exchanged at runtime, One problem are all the used constants describing the target architecture. We discussed multi

Re: [fpc-devel] Blackfin support

On 07/13/2010 01:46 AM, Hans-Peter Diettrich wrote: That's questionable, depending on the real bottlenecks in compiler operation. I suspect that disk I/O is the narrowest bottleneck, I doubt this. The disk-cache does a decent work here. gcc can do this very effectively on a higher layer, as for

Re: [fpc-devel] Blackfin support

On 07/12/2010 05:54 PM, Hans-Peter Diettrich wrote: M68K machine, which in turn seems to have inherited from the ARM. I suppose: vice versa :). .., but it doesn't allow to support multiple machine back-ends in one program. Do you think it would be an advantage to support multiple archs in a s

Re: [fpc-devel] Blackfin support

Hans-Peter Diettrich schrieb: >> For me, a much higher priority when doing rewrites might be >> multithreading nf the compiler itself. > > That's questionable, depending on the real bottlenecks in compiler > operation. I suspect that disk I/O is the narrowest bottleneck, that can > not be widened

Re: [fpc-devel] Blackfin support

In our previous episode, Hans-Peter Diettrich said: > > For me, a much higher priority when doing rewrites might be > > multithreading nf the compiler itself. > > That's questionable, depending on the real bottlenecks in compiler > operation. I suspect that disk I/O is the narrowest bottleneck, t

Re: [fpc-devel] Blackfin support

Marco van de Voort schrieb: > In our previous episode, Hans-Peter Diettrich said: >>> For me, a much higher priority when doing rewrites might be >>> multithreading nf the compiler itself. >> That's questionable, depending on the real bottlenecks in compiler >> operation. I suspect that disk I/O i

Re: [fpc-devel] Blackfin support

Michael Schnell schrieb: That's questionable, depending on the real bottlenecks in compiler operation. I suspect that disk I/O is the narrowest bottleneck, I doubt this. The disk-cache does a decent work here. gcc can do this very effectively on a higher layer, as for each source file gcc is

Re: [fpc-devel] Blackfin support

On 07/13/2010 02:49 PM, Hans-Peter Diettrich wrote: But when FPC processes every source unit in a project only once, the file cache is not very helpful. Obviously, a sufficiently huge cache can avoid any disk I/O bottleneck when doing the 2nd+ build. -Michael

Re: [fpc-devel] Blackfin support

Michael Schnell schrieb: M68K machine, which in turn seems to have inherited from the ARM. I suppose: vice versa :). At least I found files with comments from/for ARM. .., but it doesn't allow to support multiple machine back-ends in one program. Do you think it would be an advantage to sup

Re: [fpc-devel] Blackfin support

Florian Klaempfl schrieb: Memory throughput is a bottleneck, I/O not really. So multithreading has a real advantage on NUMA systems and systems where different cores have dedicated caches. One or two years ago, I did some experiments with asynchronous assembler calls and it already improved sign

Re: [fpc-devel] Blackfin support

Marco van de Voort schrieb: In our previous episode, Hans-Peter Diettrich said: For me, a much higher priority when doing rewrites might be multithreading nf the compiler itself. That's questionable, depending on the real bottlenecks in compiler operation. I suspect that disk I/O is the narrowe

Re: [fpc-devel] Blackfin support

In our previous episode, Hans-Peter Diettrich said: > > No that has to be solved by a bigger granularity (compiling more units in > > one go). That avoids ppu reloading and limits directory searching (there is > > a cache iirc) freeing up more bandwidth for source loading. > > ACK. The compiler s

Re: [fpc-devel] Blackfin support

Michael Schnell schrieb: On 07/13/2010 02:49 PM, Hans-Peter Diettrich wrote: But when FPC processes every source unit in a project only once, the file cache is not very helpful. Obviously, a sufficiently huge cache can avoid any disk I/O bottleneck when doing the 2nd+ build. Then the system

Re: [fpc-devel] Blackfin support

Marco van de Voort schrieb: One must keep in mind though that he probably measures on a *nix, and there is a reason why on Windows the make cycle takes twice the time on Windows. One of these issues are memory mapped files, that can speed up file access a lot (I've been told), perhaps because

Re: [fpc-devel] Blackfin support

In our previous episode, Hans-Peter Diettrich said: > > One must keep in mind though that he probably measures on a *nix, and there > > is a reason why on Windows the make cycle takes twice the time on Windows. > > One of these issues are memory mapped files, that can speed up file > access a lot

Re: [fpc-devel] Blackfin support

On 07/13/2010 11:18 PM, Hans-Peter Diettrich wrote: When we rely on an OS file chache, we can read all files entirely into memory, instead of using buffered I/O. Loading the complete file instead of parts of it would do unnecessary memory copies. In fact I suppose using file mapping instead o

Re: [fpc-devel] Blackfin support

On 07/13/2010 05:19 PM, Hans-Peter Diettrich wrote: It may be a good idea to implement different models, that either read entire files... "read" -> "map" -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/

Re: [fpc-devel] Blackfin support

On 07/14/2010 12:00 AM, Hans-Peter Diettrich wrote: One of these issues are memory mapped files, that can speed up file access a lot (I've been told), perhaps because it maps directly to the system file cache? AFAIK File Mapping is used a lot and very successfully with Linux, but it _is_ avail

Re: [fpc-devel] Blackfin support

In our previous episode, Michael Schnell said: > On 07/14/2010 12:00 AM, Hans-Peter Diettrich wrote: > > One of these issues are memory mapped files, that can speed up file > > access a lot (I've been told), perhaps because it maps directly to the > > system file cache? > AFAIK File Mapping is

Re: [fpc-devel] Blackfin support

Michael Schnell schrieb: One of these issues are memory mapped files, that can speed up file access a lot (I've been told), perhaps because it maps directly to the system file cache? AFAIK File Mapping is used a lot and very successfully with Linux, but it _is_ available with NTFS. I've hear

Re: [fpc-devel] Blackfin support

Marco van de Voort schrieb: In our previous episode, Michael Schnell said: On 07/14/2010 12:00 AM, Hans-Peter Diettrich wrote: One of these issues are memory mapped files, that can speed up file access a lot (I've been told), perhaps because it maps directly to the system file cache? AFAIK F

Re: [fpc-devel] Blackfin support

Michael Schnell schrieb: On 07/13/2010 11:18 PM, Hans-Peter Diettrich wrote: When we rely on an OS file chache, we can read all files entirely into memory, instead of using buffered I/O. Loading the complete file instead of parts of it would do unnecessary memory copies. How that? Of course

Re: [fpc-devel] Blackfin support

In our previous episode, Hans-Peter Diettrich said: > > > > Probably if you go linearly, the readahead is already near efficient. > > Windows offers certain file attributes for that purpose, that notify the > OS of intended (strictly) sequential file reads - what would allow to > read-ahead mor

Re: [fpc-devel] Blackfin support

In our previous episode, Hans-Peter Diettrich said: > > And Delphi (Windows!) users reported noticeable performance boosts > (factor 3+), even if nobody ever came up with non-trivial example code, > including fallbacks for restricted (32 bit) address space. Yeah, and no wonder, most probably be

Re: [fpc-devel] Blackfin support

Marco van de Voort schrieb: I don't think we ever going to give an up front carte blanche for a massive rewrite to go into trunk. That is simply not sane. ACK. I'm more concerned about work that is blacklisted for some reason. A subsmission will always be judged on performance and maintainab

Re: [fpc-devel] Blackfin support

In our previous episode, Hans-Peter Diettrich said: > > I don't think we ever going to give an up front carte blanche for a massive > > rewrite to go into trunk. That is simply not sane. > > ACK. I'm more concerned about work that is blacklisted for some reason. One reason the more to phase and m

Re: [fpc-devel] Blackfin support

Hans-Peter Diettrich schrieb: > I see the biggest benefit in many possible optimization in the scanner > and parser, which can be implemented *only if* an entire file resides in > memory. Include files, macro expansion and generics make such optimizations hard. ___

Re: [fpc-devel] Blackfin support

Hans-Peter Diettrich schrieb: > Marco van de Voort schrieb: > >> I don't think we ever going to give an up front carte blanche for a >> massive >> rewrite to go into trunk. That is simply not sane. > > ACK. I'm more concerned about work that is blacklisted for some reason. Rewriting the compiler

Re: [fpc-devel] Blackfin support

Florian Klaempfl schrieb: Hans-Peter Diettrich schrieb: I see the biggest benefit in many possible optimization in the scanner and parser, which can be implemented *only if* an entire file resides in memory. Include files, macro expansion and generics make such optimizations hard. Not neces

Re: [fpc-devel] Blackfin support

Hans-Peter Diettrich wrote: Not necessarily. When all currently used files reside in memory, every (recorded) token can contain an pointer (or offset) into the file buffer. This may reduce the number of required string copies (not yet fully researched). You normally shouldn't ever need to

Re: [fpc-devel] Blackfin support

Sergei Gorelkin schrieb: Not necessarily. When all currently used files reside in memory, every (recorded) token can contain an pointer (or offset) into the file buffer. This may reduce the number of required string copies (not yet fully researched). You normally shouldn't ever need to proc

Re: [fpc-devel] Blackfin support

On Wed, 2010-07-14 at 19:19 +0200, Marco van de Voort wrote: > Core is not unreasonable (*), > (*) well except me obviously, but I won't be reviewing compiler submissions, > so it is easier for me to say this all. Sorry for the useless post, but this is just funny. ;) Joost. __

Re: [fpc-devel] Blackfin support

On 20 July 2010 09:51, Joost van der Sluis wrote: > On Wed, 2010-07-14 at 19:19 +0200, Marco van de Voort wrote: >> Core is not unreasonable (*), > >> (*) well except me obviously, but I won't be reviewing compiler submissions, >> so it is easier for me to say this all. > > Sorry for the useless po