> >
> > Rick Hohensee wrote:
> >
> > > Another thing I haven't seen mentioned in why Linux on a DSP is absurd is
> > > memory management. True multi-user requires hardware-supported
> > > sequestering of process memory access. That's why you need a 386+ or
> > > 68010+ for any real unix. This is how OSes, mostly unix, have effected the
> > > design of the predominant general-purpose CPU chips.
> > >
> > > Another tiny little issue is that gcc is designed for single-stack
> > > register machines. I don't recall gcc.info even bothering to say "oh yeah,
> > > Von Neumann architecture." DSPs are Harvard architecture, aren't they?
> > > As with stack machines, I'm guessing extending the gcc machine description
> > > for Harvard architecture is basically a complete re-write. A quick glance
> > > at man gcc doesn't show any DSP-specific options. What gcc can reasonably
> > > do is what RTL can reasonably do, Register Transfer Language, used to
> > > describe CPU targets. DSPs and Forth engines are not describable in
> > > current RTL.
> >
> > Versions of GCC exist for most major DSP architectures (apart from the low
> > end ones). The code isn't exactly production useful, but for a number of
> > prototyping activities doing a first pass of at least the non-critical parts
> > of the DSP code in C has RAD value.
>
> Oh. Perhaps the original poster would like to know where. My gcc is
> 2.7.2.3. Is this stuff in later ones?
The standard GCC distribution may not contain support for DSPs, but ask TI, AD,
Lucent, Motorola, etc. and they have versions with the necessary back ends for
most of their more advanced DSPs.
> Why not the low end ones, BTW? That seems contradictory, or are the higher
> end ones more like regular CPUs?
Same reason you don't get real C compilers for low end microcontrollers - the
architectures just too minimal to support full C. The tortuous code resulting
from even a simple C program will generally exceed the chip's limited resources.
There are special pseudo-C subset compilers for a number of low end
microcontrollers, but these chips really couldn't support GCC. A stripped down
GCC subset, with a few special not-quite-C features added, would be feasible, but
I have never seen such a thing.
The same is true for low end DSPs. No DSP fits C's needs very well, but the
limitations of a low end DSP are just too great to make GCC support realistic. On
more advanced DSPs C compilers produce some pretty weird code you wouldn't put in
a product. For rapid development of prototypes, test programs, etc. this awful
code does have some value. I sometimes wonder if a C compiler for a DSP is really
much more than a marketing gimmick.
> > What's all the garbage about RTL? Of course an RTL description of any DSP is
> > possible. An RTL description of any clocked digital system is possible. How
> > the hell do you think the silicon guys design the darned things?
> >
>
> gcc (RTL) is geared for single-stack machines. I'm not familiar with the
> general case of RTL. I would be surprised even in the general case if a
> "Register Transfer Language" was real useful for a stack machine. If you
> have some tips on how to describe a 2 or 3 stack machine in gcc RTL I'd be
> real interested, without the l-k cc:
Ah, sorry, this is me not reading the original post properly. Say RTL to me and I
think Register Transfer Level rather than Language. A register transfer level
description is, of course possible. A register transfer language description
must, in some way, also be possible, since working compilers exist. I've never
delved inside a DSP version of GCC. Maybe the have specially modified front ends,
as well as custom back ends. Perhaps that is why no DSP architectures seems to
have made it into the standard GCC tree.
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/