Messages in this thread | | | Date | Tue, 27 Jul 1999 07:23:33 +0000 | From | Steve Underwood <> | Subject | Re: porting linux to DSP |
| |
Rick Hohensee wrote:
> > > > 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/
| |