lkml.org 
[lkml]   [1999]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: porting linux to DSP
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.

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?

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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.042 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site