1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

adsp2187L: assembler or C? [cross-post]

Discussion in 'Embedded' started by Alessandro Basili, Nov 4, 2010.

  1. 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, Nov 4, 2010
    #1
    1. Advertisements

  2. 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"?
    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.
    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.
    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!).
     
    Alessandro Basili, Nov 8, 2010
    #2
    1. Advertisements

  3. 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
     
    glen herrmannsfeldt, Nov 8, 2010
    #3
  4. (snip, I wrote)
    Except for the "lame" part, I agree.
    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.
    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
     
    glen herrmannsfeldt, Nov 8, 2010
    #4
  5. Alessandro Basili

    Leon Guest

    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.
     
    Leon, Nov 8, 2010
    #5
  6. The last few assembly routines I wrote were to use the IA32 RDTSC
    instruction. It conveniently returns the 64 bit result in EDX:EAX,
    the usual return registers for (long long) on IA32. The executable
    instructions are RDTSC and RET.
    Yes, those are the cases where inline assembler works best, but
    also, as mentioned, is ugly, non-portable, etc. You can write
    just the inner loop, maybe only a few instructions, in assembler
    with the rest in C.
    Last I wrote inline assembler was in Dynamic C for the Rabbit 3000,
    which is pretty much a Z180. Unlike the Z80, code has a 24 bit
    addressing space, with special call and ret instructions to change
    the high bits. With inline assembler, the C compiler keeps track
    of the addressing.
    For the Z180 there isn't much optimization.
    For the Z180, there aren't many registers, and some have special
    uses, so there really isn't much of a problem with registers tracking.

    -- glen
     
    glen herrmannsfeldt, Nov 9, 2010
    #6
  7. There is another complication, though, relating to pipelining
    and RDTSC. In your example, you want Part A to run before RDTSC,
    and Part B to run after. Without the jump, it is more likely that
    the processor will be able to execute RDTSC out of order, such that
    the timing doesn't do what you expect.
    Most of the time I try to time a whole loop, such that register
    use isn't so much of a problem. Not quite long enough to time
    with millisecond TOD clocks, though.
    At least for IA32, I have been told that many compilers have
    a built-in inlined bswap() such that you don't need to write one.

    (snip)
    (snip)

    -- glen
     
    glen herrmannsfeldt, Nov 9, 2010
    #7
  8. Yes. There could also be a task switch in between, which should
    result in a very large increment in the count. I have never seen
    that in my uses of RDTSC. I once even did it from Java using JNI
    and it seemed to work just fine.
    For IA32 the closest I find is SFENCE, Store Fence, which guarantees
    that all previous stores are complete before following stores are done.
    (My words after reading the description.)

    (snip)
    Usually averaged over a long loop it is close enough, at least for
    a specific generation of processors. Also, RDTSC reduces the problem
    of variable clock rates, counting clock cycles instead of real time.
    Yes, I usually don't do that until it really needs to be done.

    -- glen
     
    glen herrmannsfeldt, Nov 10, 2010
    #8
  9. Alessandro Basili

    Al Clark Guest



    As someone who has written a considerable amount of 218x code, the short
    answer is FORGET USING THE C COMPILER! The ADSP-218x architecture predates
    the emergence of C as a universal language. The registers are not
    orthogonal, the number of pointers is limited, etc.

    The good news is that 218x assembly is very easy to read and understand and
    looks more like C than traditional assembly. It is not a difficult
    processor.

    I agree with Vladimir that it is essentially obsolete. The only reason I
    see to use it is if you have a large existing code base.

    You could use a new ADSP-21489 or ADSP-21479 fixed/floating point DSP for
    less money, easier programing in C or assembly, and substantially more
    performance. I mention SHARC because the assembly language has a similar,
    but actually easier structure and could be ported to C as desired.

    You could also use any number of Blackfin targets. These are just the ADI
    choices. There are many other possibilities as well.

    Al Clark
    www.danvillesignal.com
     
    Al Clark, Nov 12, 2010
    #9
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.