> i work with dsp's and embedded linux (but not together :) i thought i
> could add some facts to the thread.
>
> > > I am thinking whether linux can be ported to a DSP chip. I would like to
> > > know if it is possible, given that it doesn't have a cache and not a huge
> > > amount of memory etc. If anybody thinks it is possible, can you please tell
> > > me where to start and how to go about doing it?
>
> first, dsp's have extremely varying architecture. the guys here who says
> gcc is bad news for dsp's probably think of the first generations, which
> were accumulator based (one "data" register, a couple of index registers
> and a bunch of adress registers) or in other ways had very few regs.
> obviously this doesn't match well with c, which likes at least a couple of
> general purpose regs. example: motorola 56k. there are other reasons why
> you wouldn't want to use c for producing _math_ code on them, but that's
> another story (fixed point dsp arithmetic is hard to understand for a
> compiler etc).
Have you looked at the code the C compiler for the 56000 or 56100 families
produce? The 56000 has split memories, which the compiler isn't too happy with.
Neither architecture has an orthogonal general purpose instruction set, because
that's not what DSPs are made for. The bottom line is large, slow code that's of
limited practical value. As you said, the C compiler doesn't understand how to
make use of the special DSP qualities of these chips. Since its those very
qualities you are normally using the chip for the, using C makes limited sense.
Now, if you are trying to use a 56K part as a general purpose processor you are
really on to a looser. When I was at Motorola considerable effort was spent trying
to graft more general purpose functionality onto these architectures, so they
could function without a support microcontroller. They failed. Its like mixing oil
and water.
> there are a lot of dsp's out there that has a perfectly normal register
> architecture, cache and blaha. they are like simple normal processors but
> with a very fast multiplicator/accumulator. granted, some of them might
> not have support for very large external ram's, which is a problem for
> linux (you need at least 2 megs, i'd say. including the kernel). examples
> are the texas c3x/c4x (which there exist a very nice gcc port to) and AD
> sharc (dont know the amount of external ram off-hand...)
The TI C3x and C4x are a bit more general purpose on the floating point side, but
the integer section of these chips is still very much a DSP addressing support
unit. The Sharc has considerable similarities. Their C compilers only produce
reasonable code in limited contexts. The clumsy code generation would probably
expand the minimum 2M requirement for Linux by a factor of several, and the result
would be _slow_. Think what a simple bit mask and test turns into on most DSP
chips. OK, some newer chips have fixed that, but how do you get around all
calculations being performed with the same register length? How to do overcome
everything being word aligned? How do you get around the limited, but highly
customised, addressing schemes? Even if the C compiler generated reasonable DSP
like code, it could do nothing to make a compilation of Linux look sane.
> second, as for the linux part, dsp's don't have MMU's, but the linux
> kernel runs perfectly well without an mmu in an embedded context. you just
> can't expect all the memory management features to work. with MM support
> stripped off, you can use the linux kernel as any other task switcher, and
> get as a bonus the VFS, filesystems and networking stacks, which was what
> the original poster expected of the system.
An MMU is not a core requirement. Security suffers badly without one, but there
are already embedded Linux projects for Linux, where people are prepared to accept
these limitations. For embedded use it may often be OK.
> i wouldn't say it's easy to port linux to a dsp. but it's certainly
> doable, given that the c compiler works well enough you have enough memory
> in the system. i've booted linux running on 512kb sram, but that didn't
> leave much room for other things that's why i recommended 2 mb dram above
> :)
I could port Linux to an 8 bit microcontroller. It would take some hardware
support to do masses of memory bank switching, to extend the chip's addressing
capabilities, and it would run like molasses doesn't. Is it doable? Yes. Does it
make any sense? No.
> third, regarding the speed vs pentium issue. a low-end pentium always
> costs around $75 doesn't it ? (they remove the models when they can't make
> money on them :) a standard dsp costs between $2 and $15, and will not
> match a celerons raw (non-disturbed) FPU performance, but it does cost
> quite a bit less. a $5 DSP (like texas new c31/150) does 75 million
> multiplications and accumulations per second. a celeron has to do those
> ops after each other, reducing the lead somewhat.
Some of the latest DSP families, like the TI 6000 are turning the whole compiler
thing around. They have made an architecture that's so hard to program in assembly
language they have bet the future on highly customised compiler technology. I
believe TI bought one of the smaller companies working on compilers for EPIC, and
used their C compiler as the basis for the 6000's programming environment. They
have made sure the architecture and the compiler fit together, and work well - so
long as you use a particular subset/style of C. I believe the TigerSharc is
similar. These things are priced higher than a Celeron, but less than a Pentium
II, and are capable of some pretty hot performance. They still don't have what it
takes to run Linux well, though.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/