Jerry: I know we are in agreement--I was just fleshing it out based on the chance that your original reply was not really what the OP was after--he did not reply to either of us, so he is either satisfied, totally confused, or disinterested. But, I have one question: what is "native forth"? I'm somewhat familiar with forth, but I thought it was a fairly high-level language. I'm also familiar with most of the processors you mentioned (all but the 6809, but I do know the 6833x, and played many games on my apple 2 with a 6802), but I don't recall any "native" languages--I'm assuming you mean a compiler/interpreter built into the processor. I've always used C or assembly, or a combination, but perhaps I have been missing out on something? Jim "Jerry Avins" <jya@ieee.org> wrote in message news:40171853$0$11450$61fed72c@news.rcn.com...> Jim Gort wrote: > > > Jerry: > > > > I'm going to play the devil's advocate here, mostly for fun, but also to > > make sure you don't convince somebody to through away their PC. > > > > First off, I don't think DSPs "simplify programs" or "run them faster".You> > could make an argument that ADI's algebraic assembly is "simpler" thanINTEL> > assembly, but that is a specific case. In fact, the trend in DSPs latelyhas> > been to actually increase the instruction word width, and increase the > > number of instructions, which does everything but simplify. Further,DSPs> > don't, in general, "run them faster". DSPs only run some programsfaster,> > and those are "DSP" intensive programs, and they only run them fasterw/r/t> > the processor clock frequency. Further, if you are writing in "C" (whichthe> > OP may be), the C compilers for DSP tend to be even more hideously > > inefficient than those for "PC" processor (reference previous thread onthe> > subject, and also the fact that almost all application code for the PC'sare> > written in C, whereas I'm 99% certain that your cellphone code waswritten> > in assembly). > > I meant, but didn't say, that DSPs simplify programs that process > digital signals. You surely agree that MACs (single cycle or not), > non-integer fixed-point and saturating arithmetic, and circular buffers > simplify those programs. Zero-overhead loops, multiple DMA engines, > simultaneously addressable memory banks, and the already mentioned > simplifications make them faster. DSPs are among the most efficient > processors measured in bit-MIPS/microwatt. > > Time-critical DSP programs are typically written in assembly, just as > time-critical portions of Pentium programs are. The major difference > lies in the fraction of such code. > > > General purpose processors, such as the INTEL line, were designed to bebest> > at applications where the data bandwidth and arithmetic requirementswere> > minimal--such as a word processor or spreadsheet. DSPs were designed tobe> > best at data bandwidth and arithmetic intensive applications, such asDSP. I> > don't think that, unless you specify the appplication, you can say thatone> > is "simpler" or runs "faster" (even after equating for processor clock).The> > fact is, many DSPs now-adays are used for applications that are only > > somewhat DSP-intensive, and the desktop-type processors run at a muchfaster> > clockrate. > > > > You made a very good argument implying the performance/power tradeoff,which> > is really at the heart of why anyone would use a DSP. Also, othersrepliers> > have referenced the the real-time aspect, which is not inherent to theDSP> > itself, but is assuming that you will run a lean-and-mean (or no) OS onthe> > DSP, and compare that to the one running on the desktop. Also, one thingnot> > mentioned yet, the DSPs are designed so that the external hardwarerequired> > to make them work in a system is minimal. > > Well, so is the external hardware needed with most microcontrollers of > any sort. There, the major difference is between embedded and richly > endowed systems. In many ways, a DSP has more in common with the $0.80, > 4-bit processor in my kitchen scale than with the behemoth I write this > on. > > > I think therin lies the true reason for DSP processors to (currently) doDSP> > "It is a low-power, low-cost (mostly in lack of need for supporting > > hardware), small (again, in lack of need for supporting hardware)processor> > optimized to signal processing (high data bandwidth, high compute) > > applications, for which a variety of 3rd parties have writtenlean-and-mean> > "real-time" OS's for". Comments welcome. > > That's a good summary. > > > However, back to the OP. I think you should have assumed that, since heis> > wondering why he needs a DSP to do a certain task instead of the PC, he > > probably has a situation where there is a DSP tethered (plug-in board, > > FireWire, etc.) to the PC he is using, or that he as an experimentalsetup> > where some predecessor has decided to use an embedded DSP rather than > > A/D-PC-D/A. I don't think he is wondering why he can't replace his cell > > phone with a PC--that has already been done with "talk" programs overthe> > internet. And, to his question, I would say: > > > > a) Yes, I've done it before. Mostly because I determined the application > > really did not need the low-power, low-cost, or processing poweraddition> > provided by the DSP (that is, a DSP board with A/D and D/A tethered tothe> > PC), yet there was only one person at the company I was consulting forthat> > actually knew the DSP code, and thus everything had to go through him > > (laughable job security), so I transferred what the DSP was doing to the > > host PC, and made it work just fine. However, note that this was only > > possible because the application did not require "real-time" (defined byone> > very profitable company as <50ms or so) continuous response betweeninput> > and output. > > > > b) Make sure you completely understand the "real-time" requirements ofyour> > system before attempting to move it to a bloated OS, or make sure you > > completely understand the concert of chips needed to support theprocessor> > in the PC before attempting to move it to your realtime system,whichever is> > the case for you. > > > > My 2c, and I hope it brings discussion. > > I've done a lot of work using Z-80s, 6809s. 68HC11s, and 80186s, all > using either native Forth or straight assembler. My programs ran faster > than those under the popular OSs of the day, and more to the point, with > less latency. What's more, without an OS to surprise me with > unanticipated "favors", they were up and running sooner. As for > discussion, me too. > > Jerry > > > -- > Engineering is the art of making what you want from things you can get. > ����������������������������������������������������������������������� >
Substituing PC for DSP
Started by ●January 27, 2004
Reply by ●January 29, 20042004-01-29
Reply by ●January 30, 20042004-01-30
Jim Gort wrote:> Jerry: > > I know we are in agreement--I was just fleshing it out based on the chance > that your original reply was not really what the OP was after--he did not > reply to either of us, so he is either satisfied, totally confused, or > disinterested. > > But, I have one question: what is "native forth"? I'm somewhat familiar with > forth, but I thought it was a fairly high-level language. I'm also familiar > with most of the processors you mentioned (all but the 6809, but I do know > the 6833x, and played many games on my apple 2 with a 6802), but I don't > recall any "native" languages--I'm assuming you mean a compiler/interpreter > built into the processor. I've always used C or assembly, or a combination, > but perhaps I have been missing out on something? > > Jim >... I meant only Forth running without an operating system. The BIOS ROM contains the console- and sector-level disc-access routines, and Forth does the rest. That's known as "running on bare iron" to some members of embedded fraternity. The TRS80 and early PCs used BASIC that way. Small C can run the same way, but not usually with disk support. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●January 30, 20042004-01-30
In article <ztkSb.180143$I06.1916593@attbi_s01>, Jim Gort <jgort@comcast.net> wrote:>But, I have one question: what is "native forth"? I'm somewhat familiar >with forth, but I thought it was a fairly high-level language.There have been a few processor chips which have implemented Forth primatives (as opcodes instead of direct or indirect addresses) directly in hardware. Harris and Novix are a couple of the vendors who have tried this. Forth itself is actually a fairly small low-level language (when compared to Java, et.al., and except to Forth fanatics) consisting of a macro toolkit from which one can homebrew ones own application specific high-level language. IMHO. YMMV. -- Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/ #include <canonical.disclaimer> // only my own opinions, etc.
Reply by ●January 30, 20042004-01-30
Worse than that, it is an assembler for a stack-based machine. You program the stack registers directly. "Ronald H. Nicholson Jr." <rhn@mauve.rahul.net> wrote in message news:bve13v$ltd$1@blue.rahul.net...> Forth itself is actually a fairly small low-level language (when compared > to Java, et.al., and except to Forth fanatics) consisting of a macro > toolkit from which one can homebrew ones own application specific > high-level language.
Reply by ●January 30, 20042004-01-30
Airy R. Bean wrote:> Worse than that, it is an assembler for > a stack-based machine. You program > the stack registers directly. > > > > "Ronald H. Nicholson Jr." <rhn@mauve.rahul.net> wrote in message > news:bve13v$ltd$1@blue.rahul.net... > >>Forth itself is actually a fairly small low-level language (when compared >>to Java, et.al., and except to Forth fanatics) consisting of a macro >>toolkit from which one can homebrew ones own application specific >>high-level language.Although most Forth systems include an assembler, not all do. Forth uses two stacks, one for return addresses, the other for data. "Program the stack registers directly" doesn't map onto real hardware or Forth's virtual-machine model. I don't know what Airy supposes it to mean. Many modern Forths compile to native code for the target platform. Such Forths are about as fast as C because the data stack makes it unnecessary to build, then dismantle, a stack frame whenever a new routine is called. It is interactive, so new routines can be tested in isolation from the keyboard with a framework ot stubs, and so it is relatively bug free in the hands of an experienced programmer. It usually compiles to about a third the size of the same function written in C, at only a slight speed hit. I like it. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●January 31, 20042004-01-31
Jerry Avins wrote:> prizark wrote: > > > Hi guys, > > > > We use DSP for a multitude of purposes and do all the stuff in > > their discrete form but why do we need the entire microprocessor core > > in the DSP itself rather use high resolution ADC and acquire all the > > data into the PC do all the computations we ever wanted to do and then > > send it out via DAC (assuming portability is not an issue and only for > > experimental purposes). Did anyone tried or did anything like this, if > > so please share your experiences. > > > > > > Thank You, > > Prizark > > DSPs have features in their architecture that simplify programs and run > them faster. If you wanted to replace the processor in a cell phone with > one in a PC, you would need a wheelbarrow and a very long extension > cord. Most DSPs use less power than a Pentium's fan, and some run on the > power used by a single LED. You have at least two DSPs in your PC: one > in the modem, another in the sound card (connected to that DAC). > > Jerry > -- > Engineering is the art of making what you want from things you can get.and maybe the Graphics card and certainly the Graphics accelerator card. Tom> > �����������������������������������������������������������������������
Reply by ●January 31, 20042004-01-31
Forth is the assembler for the two-stack machine that is being emulated. The software architecture for the KDF-9 was published long before Forth came along, and the primitive operations in Forth are strikingly similar to those in the KDF-9 instruction set. The two-stack machine of Forth is strikingly similar to the hardware of the KDF-9 "Jerry Avins" <jya@ieee.org> wrote in message news:401adadc$0$2658$61fed72c@news.rcn.com...> Airy R. Bean wrote: > > > Worse than that, it is an assembler for > > a stack-based machine. You program > > the stack registers directly. > Although most Forth systems include an assembler, not all do. Forth uses > two stacks, one for return addresses, the other for data. "Program the > stack registers directly" doesn't map onto real hardware or Forth's > virtual-machine model. I don't know what Airy supposes it to mean.
Reply by ●January 31, 20042004-01-31
Airy R. Bean wrote:> Forth is the assembler for the two-stack machine that > is being emulated. > > The software architecture for the KDF-9 was published long > before Forth came along, and the primitive operations in > Forth are strikingly similar to those in the KDF-9 instruction set. > The two-stack machine of Forth is strikingly similar to the > hardware of the KDF-9 > > "Jerry Avins" <jya@ieee.org> wrote in message > news:401adadc$0$2658$61fed72c@news.rcn.com... > >>Airy R. Bean wrote: >> >> >>>Worse than that, it is an assembler for >>>a stack-based machine. You program >>>the stack registers directly. >> >>Although most Forth systems include an assembler, not all do. Forth uses >>two stacks, one for return addresses, the other for data. "Program the >>stack registers directly" doesn't map onto real hardware or Forth's >>virtual-machine model. I don't know what Airy supposes it to mean.C is widely used a a "portable assembler" by people who write compilers for other languages. How a language is used doesn't define what it is. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●January 31, 20042004-01-31
Tom wrote:> > Jerry Avins wrote: > > >>prizark wrote: >> >> >>>Hi guys, >>> >>> We use DSP for a multitude of purposes and do all the stuff in >>>their discrete form but why do we need the entire microprocessor core >>>in the DSP itself rather use high resolution ADC and acquire all the >>>data into the PC do all the computations we ever wanted to do and then >>>send it out via DAC (assuming portability is not an issue and only for >>>experimental purposes). Did anyone tried or did anything like this, if >>>so please share your experiences. >>> >>> >>>Thank You, >>>Prizark >> >>DSPs have features in their architecture that simplify programs and run >>them faster. If you wanted to replace the processor in a cell phone with >>one in a PC, you would need a wheelbarrow and a very long extension >>cord. Most DSPs use less power than a Pentium's fan, and some run on the >>power used by a single LED. You have at least two DSPs in your PC: one >>in the modem, another in the sound card (connected to that DAC). >> >>Jerry >>-- >>Engineering is the art of making what you want from things you can get. > > > and maybe the Graphics card and certainly the Graphics accelerator card. > > TomI'm glad I wrote "at least". There are processor cores in the disk controller ASICs, but I don't know if they're DSPs. What features of a DSP suggest it for the graphics system? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●January 31, 20042004-01-31
there is a lot difference betwn dsp & pc PCs are basically designed for data processing they fail when u deal with real time signals as there are many considerations to be taken into account . For real time, reults must be computed b4 a deadline and proram executes for indefinite duration DSP requirements ---------------- --> emphasis is on mathematical operations rather than data manipulation Design is optimized for DSP algorithms which implement FIR filter, FFT generator etc. -->dominant mathematical operation is MAC, on seperate inputs in parallel. --> high bandwidth memory and i/o controller --> low power operation for embedded appln. there's lot about the architecture of DSP processors It uses Harvard architecture rather than Von neuman which is used in PCs in which both data and instructions r stored in same memory and processor adress this memory thru single set of address and data lines But harvard architecture uses seperate data and program memories seperate address and data buses to access each as u might be knowing MAC is the most commonly used operation in the DSP this operation requires 4 instruction cycles in neuman architecture. Now u can see whether ur deadine be met with PC or DSP. And there is lot more about pipelining,etc.
