Hi, I have a custom designed board which is based on an ADSP2187L dsp, with a 512KB FLASH, a 128KB SRAM (20 ns cycle) and an FPGA running at 50 MHz. The dsp task is mainly processing commands and data from external links (space-wire) on a 200~500 us cycle. Since the actual software has been written in assembler and there are some concerns about its reliability, I was wondering whether it is worth while considering the possibility to move to a higher language like C, in order to gain in maintainability and readability without loosing too much on performances. Thanks. -- Alessandro Basili CERN, PH/UGC Electronic Engineer
adsp2187L: assembler or C? [cross-post]
Started by ●November 4, 2010
Reply by ●November 4, 20102010-11-04
Alessandro Basili wrote:> Hi, > I have a custom designed board which is based on an ADSP2187L dsp, with > a 512KB FLASH, a 128KB SRAM (20 ns cycle) and an FPGA running at 50 MHz.ADSP218x is a dinosaur with the address space of 16K words; what is all that external memory for? This DSP is inconvenient for C programming as it doesn't support stack frames and base-index addressing.> The dsp task is mainly processing commands and data from external links > (space-wire) on a 200~500 us cycle. > Since the actual software has been written in assembler and there are > some concerns about its reliability, I was wondering whether it is worth > while considering the possibility to move to a higher language like C, > in order to gain in maintainability and readability without loosing too > much on performances.Yes, you can program ADSP218x in C; VDSP toolset recommended. Yes, there will be significant overhead. It is impossible to tell if there is enough of speed without actually knowing the application. Why getting stuck with the 20 year old technology? Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●November 8, 20102010-11-08
On 11/4/2010 4:24 PM, Vladimir Vassilevsky wrote:> > > Alessandro Basili wrote: > >> Hi, >> I have a custom designed board which is based on an ADSP2187L dsp, >> with a 512KB FLASH, a 128KB SRAM (20 ns cycle) and an FPGA running at >> 50 MHz. > > > ADSP218x is a dinosaur with the address space of 16K words; what is all > that external memory for? This DSP is inconvenient for C programming as > it doesn't support stack frames and base-index addressing. >The main purpose of the DSP is basically data compressing in a physics detector readout system. We have some 300'000 12 bit ADC channels to read out at a frequency of ~2KHz out of which only few signals are meaningful. That's why we use the external memory to store the raw event and then we try to compress using cluster reconstruction with cuts on the adc distributions. B.t.w. what are "stack frames" and "base-index addressing"?> >> The dsp task is mainly processing commands and data from external >> links (space-wire) on a 200~500 us cycle. >> Since the actual software has been written in assembler and there are >> some concerns about its reliability, I was wondering whether it is >> worth while considering the possibility to move to a higher language >> like C, in order to gain in maintainability and readability without >> loosing too much on performances. > > Yes, you can program ADSP218x in C; VDSP toolset recommended. > Yes, there will be significant overhead.Maybe I can think about having the framework in C, while the specific compression algorithms (which will be the most critical ones) maybe still done with the assembler.> It is impossible to tell if there is enough of speed without actually > knowing the application.Indeed I believe there is no general answer. But I believe that simply "translating" from assembler to C will be a bad idea and I should maybe focus the possibility of restructuring the whole program.> Why getting stuck with the 20 year old technology? >The 20 y.o. technology was the one which didn't suffer radiation effects for a low earth orbit exposure. At least this was the claim when the choice was made (some 10 years ago already!).> > Vladimir Vassilevsky > DSP and Mixed Signal Design Consultant > http://www.abvolt.com
Reply by ●November 8, 20102010-11-08
In comp.dsp Alessandro Basili <alessandro.basili@cern.ch> wrote:> I have a custom designed board which is based on an ADSP2187L dsp, with > a 512KB FLASH, a 128KB SRAM (20 ns cycle) and an FPGA running at 50 MHz.(snip)> Since the actual software has been written in assembler and there are > some concerns about its reliability, I was wondering whether it is worth > while considering the possibility to move to a higher language like C, > in order to gain in maintainability and readability without loosing too > much on performances.Much embedded programming is done in C with inline assembler. With some compilers, you can switch back and forth in the middle of a function. Depending or the processor, keeping track of which registers to use may or may not be a problem, but in most cases it can be done and result in fast code. -- glen
Reply by ●November 8, 20102010-11-08
glen herrmannsfeldt wrote:> Much embedded programming is done in C with inline assembler.Inline assembler is bad style and a characteristic feature of lame programmers. It combines disadvantages of both C and assembler. If there is a need to use an assembler, make a separate module in assembler and call it from C as an external function.> With some compilers, you can switch back and forth in the middle > of a function. Depending or the processor, keeping track of > which registers to use may or may not be a problem, but in most > cases it can be done and result in fast code.The result is incomprehensible, unalterable, undebuggable and unportable write-only code. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●November 8, 20102010-11-08
In comp.dsp Vladimir Vassilevsky <nospam@nowhere.com> wrote: (snip, I wrote)>> Much embedded programming is done in C with inline assembler.> Inline assembler is bad style and a characteristic feature of lame > programmers. It combines disadvantages of both C and assembler.Except for the "lame" part, I agree.> If there is a need to use an assembler, make a separate module in > assembler and call it from C as an external function.Usually a good idea, though it depends on the function call overhead. Sometimes it isn't so bad to have only the function statement in C, with all the code in assembler. Or use #ifdef to select between the assembler code and equivalent C code. It is then portable, but possibly too slow.>> With some compilers, you can switch back and forth in the middle >> of a function. Depending or the processor, keeping track of >> which registers to use may or may not be a problem, but in most >> cases it can be done and result in fast code.> The result is incomprehensible, unalterable, undebuggable > and unportable write-only code.Well, assembler is pretty much unportable anyway. If you only write the inner loops in assembler then you get speed, with only a small amount of write-only code. Last I did it, was for a Z280. There are few enough registers that you pretty much don't have to worry about them. It was surprisingly easy to write and debug. A big advantage for the Z280 is the bank switching function call. The compiler gets that right, while keeping track of which bank the code is in. -- glen
Reply by ●November 8, 20102010-11-08
Alessandro Basili <alessandro.basili@cern.ch> writes:> Hi, > I have a custom designed board which is based on an ADSP2187L dsp, > with a 512KB FLASH, a 128KB SRAM (20 ns cycle) and an FPGA running at > 50 MHz. > > The dsp task is mainly processing commands and data from external > links (space-wire) on a 200~500 us cycle. > Since the actual software has been written in assembler and there are > some concerns about its reliability, I was wondering whether it is > worth while considering the possibility to move to a higher language > like C, in order to gain in maintainability and readability without > loosing too much on performances."Some concerns about its reliability" is pretty vague. Is it broken? "If it ain't broke, don't fix it." You want to spend time rewriting working software so it's more maintainable, even though you have no clear problem with it? This sounds like a horrible idea to me. -- Randy Yates % "So now it's getting late, Digital Signal Labs % and those who hesitate mailto://yates@ieee.org % got no one..." http://www.digitalsignallabs.com % 'Waterfall', *Face The Music*, ELO
Reply by ●November 8, 20102010-11-08
Vladimir Vassilevsky <nospam@nowhere.com> writes:> glen herrmannsfeldt wrote: > > >> Much embedded programming is done in C with inline assembler. > > Inline assembler is bad style and a characteristic feature of lame > programmers. It combines disadvantages of both C and assembler. > > If there is a need to use an assembler, make a separate module in > assembler and call it from C as an external function.Amen, brother! My philosophy exactly! -- Randy Yates % "Bird, on the wing, Digital Signal Labs % goes floating by mailto://yates@ieee.org % but there's a teardrop in his eye..." http://www.digitalsignallabs.com % 'One Summer Dream', *Face The Music*, ELO
Reply by ●November 8, 20102010-11-08
On Nov 8, 9:24=A0pm, Randy Yates <ya...@ieee.org> wrote:> Vladimir Vassilevsky <nos...@nowhere.com> writes: > > glen herrmannsfeldt wrote: > > >> Much embedded programming is done in C with inline assembler. > > > Inline assembler is bad style and a characteristic feature of lame > > programmers. It combines disadvantages of both C and assembler. > > > If there is a need to use an assembler, make a separate module in > > assembler and call it from C as an external function. > > Amen, brother! My philosophy exactly! > -- > Randy Yates =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% "Bird, on the wi=ng,> Digital Signal Labs =A0 =A0 =A0 =A0 =A0 =A0 =A0% =A0 goes floating by > mailto://ya...@ieee.org =A0 =A0 =A0 =A0 =A0% =A0 but there's a teardrop i=n his eye..."http://www.digitalsignallabs.com% 'One Summer Dream', *Face Th= e Music*, ELO That was how I did with a large application for the ADSP-2187 I developed 15 years ago which needed much faster floating point than the IEEE library routines provided in the main computation function. The company I worked for has just upgraded to a Blackfin.
Reply by ●November 8, 20102010-11-08
On 08/11/10 21:30, Vladimir Vassilevsky wrote:> > > glen herrmannsfeldt wrote: > > >> Much embedded programming is done in C with inline assembler. > > Inline assembler is bad style and a characteristic feature of lame > programmers. It combines disadvantages of both C and assembler. > > If there is a need to use an assembler, make a separate module in > assembler and call it from C as an external function. >I disagree. It's a matter of taste and style, of course. It is also a matter of the application and the target - for DSPs with typical DSP code, assembly can make a much bigger difference over C than for more common microprocessor code. Sometimes you can't avoid using assembly. A typical good reason is because you need access to low-level features that can't be expressed in C (such as registers that are accessible only with special instructions), for a few bits of startup code, as part of an interrupt routine (if your compiler does a poor job), or for handling key parts of an RTOS. Typical bad reasons is for speed-optimising code. Sometimes it /is/ important to get the best possible speed out of the system within a small section of the code. You may also be writing library code or other heavily-used code, where it can be worth the effort. But in a great many cases when people think they need to write code in assembly for speed, they are wrong - either it is not worth the cost (in terms of development time, maintainability, readability, correctness, robustness, portability, etc.), or the C compiler will actually do a good job if the programmer just learned to use it properly. So all in all, for most targets and most applications, you don't often need assembly when using modern tools. Since well-written high-level code is /generally/ clearer and more portable than even well-written assembly (though you can write bad code in any language), the preference should always be for using high level coding unless you have overriding reasons for using assembly. Then you have the choice - separate assembly modules, or inline assembly. If you are writing large sections of assembly code, then assembly modules makes sense. It is clearer to stick to a single language at a time, and use tools suitable for that language, and large "asm(...)" statements are as messy as large multi-line pre-processor macros. But if you are mixing C and assembly, and want to have minimal assembly, then inline assembly is the way to go, especially if you have good tools. There are some C compilers that can't deal well with inline assembly - they insist on it being restricted to "assembly functions" only, or they turn off all optimisations for functions that use inline assembly. Other compilers work very well with inline assembly - the compiler will handle register and/or stack allocation, and happily include the inline assembly in its optimisation flow. If you are using such a compiler (gcc is a well-known example, but there are commercial tools that work well too), then you will probably get the smallest and fastest code by using inline assembly and letting the compiler do its job. The actual assembly code itself can often be tucked away in "static inline" functions. Inline assembly lets you mix assembly with the C to get the /best/ of both worlds. As an example, I once re-wrote the C startup code used by a particular compiler, so that the startup code was in C instead of the original assembler. The original assembler code was quite well-written and clear, but it is difficult to write assembly that is general, clear, and efficient. You often can't write the code to take advantage of particular circumstances (such optimising based on the values of compile-time constants) without it being messy and full of conditional assembly. But the C compiler will do such optimisations fine. So my C code, along with a couple of lines of inline assembly to set the stack pointer, was much smaller and clearer in source code, and the target code was significantly smaller and faster. The code couldn't have been written in pure C, and the mix with inline assembler was a big improvement over the external assembly module.>> With some compilers, you can switch back and forth in the middle >> of a function. Depending or the processor, keeping track of >> which registers to use may or may not be a problem, but in most >> cases it can be done and result in fast code. > > The result is incomprehensible, unalterable, undebuggable and unportable > write-only code. >If you need to write code requiring a lot of register tracking, then I can see that inline assembly will be messy. But for a lot of uses, when done properly (both by the user, and by the toolchain vendor), inline assembly is much clearer and simpler than external assembly modules, and results in smaller and faster code.