LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Sponsors
  • Mirrors
  • Logos
  • Contact us
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Cores > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: pai.ramanath at gmail.com<pai.ramanath@g...>
    Date: Thu Mar 30 08:42:06 CEST 2006
    Subject: [oc] Parallel Array Processor Project
    Top

    ----- Original Message -----
    From: Joachim
    Strömbergson<Joachim.Strombergson@I...>
    To:
    Date: Tue Aug 17 09:21:15 CEST 2004
    Subject: [oc] Parallel Array Processor Project

    > Aloha!
    >
    > markus@r... wrote:
    > > Have anyone programmed DSPs with C (or other higher level
    > language)?
    > > In my other project, a DSP-based guitar effect box, I'm
    > programming
    > > Motorola DSP56303. It's very hard to try to express variable
    > allocation
    > > from different kinds of memories (internal/external, X/Y/P/L)
    > and it's very
    > > hard to write a good C compiler for these. And trying to write
    > an OS:
    > > very unpleasant job, indeed.
    > Yes I have. I would say that quite a lot (most?) DSP programming is
    > done in C,
    > albeit with more or less lots of pragmas and calls to (inlined)
    > library
    > functions sprinkled whithin the code. DSP codes are much more
    > regular with the
    > bulk of the execution located in specific kernels. The kernels
    > however might
    > be written in optimized assembler for the specific architecture.
    > Programming DSPs can be quite a challenge, both due to
    > non-orthogonal
    > instruction sets and (for example TIs 6000 series) VLIW and
    > multiple core
    > architectures.
    > TI, AMD, AD etc spends lots of money developing good compilers for
    > their
    > architectures.
    > > There were one idea I haven't even think about - constructing
    > a stack-
    > > based PSM. The author has rejected this because it's not very
    > > straightforward to program, but that doesn't matter in this
    > project.
    > Stack based cores for embedded multiprocessor applications are a
    > very fine
    > idea. There have been some work done on this, but I have few
    > references for
    > you. One thing to consider is how to implement/include the
    > communication
    > semantics. You could do this by adding a communication co-processor
    > that
    > extends the instruction set with port semantics. Doing this
    > pushes/exposes the
    > syncronization to the user and removes lots of burden for the HW
    > implementation.
    > > The compiler could be easily modified to output reverse polish
    > program
    > > for the cell. In fact, it's easier to do this than make the
    > compiler to
    > > output programs for register-based PSMs.
    > You mean you have a pcode generator? ;-)
    > > The stack-based PSM would have a very dense instruction set
    > and it
    > > would be versatile with small efforts.
    > Yep!
    > --
    > Med vänlig hälsning, Yours
    > Joachim Strömbergson - Alltid i harmonisk svängning.
    > VP, Research & Development
    >
    > -------------------------------------------------------------------
    ---
    > InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG /
    > Sweden
    > Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02
    > E-mail: joachim.strombergson@i... Home:
    > www.informasic.com
    >
    > -------------------------------------------------------------------
    ---
    >
    >

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.