In article , A Man Crying Alone In The Wilderness wrote: [....]
In both seismic data processing and the SETI project, parallel computing can be done up to the limit of your budget for all practical purposes. Some years back I was at a trade show and saw a computer with 32K processors in it.
Cute sales lady: ... and this machine has over 32 thousand processors. Me: Oh, what kind of processor are they. CSL : ... um ... um ... little bitty ones
-- -- kensmith@rahul.net forging knowledge
The register based machine. The reasons is that registers can be decoded from a small index (like 4-bits) while a stack has to be indexed by lots of bits (like address-bits).
And you have sold how many chips in this time ?? versus ~2 Billion from our side.
And make vast sums of money...to satisfied customers...
Best. Booth. Babe. Story. EVAR!
A stack does not have to be indexed in a stack machine processor. The machine language primitives work directly on the stack. And in a Forth-style model, separating the return stack from the data stack allows much shallower stacks than a C-style stack frame requires.
The "reduced hardware" in hardware Forth machines is also due to the ability to work with a kind of "ultra-RISC" machine, where very few and very simple primitives are used to support a general purpose high level language. In one group of hardware Forth chips, instructions are 5 bit opcodes packed four at a time into a 20 bit word.
One approach to implementing a Forth machine is to use a FPGA, where the small number of machine instructions required frees up on-chip resources that can be used to provide internal data and return stacks.
A side effect, though, of a virtual machine model that can be implemented by hobbyists either in software or in hardware is that sometimes the experienced professionals are hard to hear over top of enthusiastic amateurs. I note this as an observation over more than a decade in which I myself have been naught but an enthusiastic amateur.
(snip)
Does C require a combine stack? It is a common implementation, but I don't believe it is required.
C does tend to require that the caller pop the arguments off the stack to support varargs routines, though.
-- glen
You'll notice that I was too canny to step into that one. I did not say "a stack frame, as required by C", but "a C-style stack frame". I am not even going to speculate what would be involved in a C-compiler that was based on a split stack virtual machine and took advantage of that to reduce total stack space requirements.
Not that I'm complaining about the C-style stack frame. I reckon that's the data structure that is responsible for the ,S address modes in the
65816, which is part of what makes it so much better as a Forth microcontroller core than the old 65C02 ever was.
I remembered that many years ago, a british company, may be called "Sinclair", announce a breakthrough in chip design, I think it is also RISC-based.
But we all know, what wins in the martket place usually tends to be the one with best marekting, not the one with best technology, for example, Microsoft Windows ...
David =====================================
It depends on the market. In a fast growth mass market, that's normally true.
But if the machine is implemented on an FPGA, then you get the manufacturing economies of scale courtesy of Xilinx or one of their peers, and its easier to scale down into a small niche.
Why would I - or anyone else - even care when the Important Question is: "Does Half Life run on it"??
I have lived in Minnesota pretty much all my life, and worked in the computer field for a pretty long time. I never heard of this doof and his vliw/forth/smp/bullcrap formula. If he has been publishing in the MSP area it has been with small circulation.
(crosspost trimmed)
-- Del Cecchi "This post is my own and doesn?t necessarily represent IBM?s positions, strategies or opinions.?
Hrmph:
A long undisclosable history of disasters with implementing real stuff in FPGA's, ASIC's and various dedicated CPU's tend to "prove" the opposite: There *is* no economy to be had - the tools are bleeding-edge-to-the-point-of-being-useless - and by the time it finally "works", the "product" is either abandoned or at least carries a "Last Buy" toxic sticker. Sorry.
The sales people will of course hate those projects too, because of the perpetual brokenness of the alledged product they cannot not show any early demos to customers and rack up airmiles, so a lynch mob will gather to kill the runt should it ever actually emerge.
In my experience, plain, stupid and wasteful COTS hardware and tools will beat the custom devices in delivering actual product *80 times out of 100*. And, IMO, The Real Reason(tm) for taking the FPGA/ASIC route is that just happen to have a lot of idle hardware design "talent" and said PHB do not want to shrink the empire (but rather prefer to shrink the entire next years budget with the inevitable writeoff).
PS:
During all this time the previously rejected COTS CPU solution has of course doubled in speed and halved it's price to well below whatever the FPGA/ASIC "solution" was touted to cost ....
PS2:
After about two years the memory of pain and disaster has faded sufficiently and the cycle repeats itself.
I don't know about what would be involved either, but wouldn't separating the return address stack from the data stack help to prevent some security flaws as it would be harder to use an "oversize" piece of data to overwrite the return address and force execution of rogue code?
-- - Stephen Fuld e-mail address disguised to prevent spam
i don't see how this affects the space needed for a stack. it's just partitioned.
no. in fact, the return address can be passed in a register.
as for FORTH, doesn't it require two memory fetches for each interpreter cycle?
-- mac the naïf
It depends.
ITC (indirect threaded); yes, it's an indirect jump DTC (direct threaded); no, it's a direct jump STC (subroutine threaded); no, it's a call/return Optimising Forth compiler; no "interpreter cycle"
-- Regards Alex McDonald
It's also an indirect jump, but there is only one memory fetch in the NEXT (virtual machine instruction dispatch).
Here's direct threaded NEXT for a few architectures:
i386: ( $804B190 ) add ebx , # 4 \\ $83 $C3 $4 ( $804B193 ) jmp dword ptr -4 [ebx] \\ $FF $63 $FC
Alpha: ( $120003440 ) 22 0 15 ldq, ( $120003444 ) 15 8 15 addq#, ( $120003448 ) 31 22 0 jmp,
PPC: addi r31,r31,4 lwz r29,-4(r31) mtctr r29 bctr
Followups set to comp.arch, comp.lang.forth
- anton
-- M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html New standard: http://www.complang.tuwien.ac.at/forth/ansforth/forth200x.html EuroForth 2005: http://www.complang.tuwien.ac.at/anton/euroforth2005/
(someone wrote)
Well, that isn't quite fair. If that routine wants to call another it has to save that register somewhere, which could be on the same stack as data/arguments.
I believe, though, that it can be a separate stack.
-- glen
(snip)
(snip)
It may even be more than 80 out of 100, but that still leaves a small niche market there. I don't believe it is quite 100 out of 100.
-- glen
It sounds to me like it "proves" that there is no such thing as a silver bullet, and every time somebody succeeds in selling something as being a silver bullet, the industry rediscovers that there is no silver bullet. I've watched the industry from the outside for a couple of decades, and have seen more than a few silver bullets in that time.
Normally those silver bullets are sold on the basis of some real world successes, and its not until everyone tries the new one-size-fits-all solution that people come to understand the limits on the success of the approach. Some of them just fold, but a lot of them become specialised tools and settle back down into their own market niche.
Now, if the main incentive to go for an AS design is a corporate concern for intellectual property, tha's just one more example of the hunt for financial advantage undermining the hunt for technical success. And THAT game is so old that there was a guy who wrote about it before 1900, and called it "pecuniary advantage" versus "the spirit of workmanship".
ME, I'm not likely to be designing anything new in an FPGA. But for the hobbyists that implement Forth chips in FPGA, good on 'em.
Certainly -
Fr example: NVIDIA and ATI are some the most successful "applicators" of custom chips, spewing them out in the millions; however installing one of their products is forever a pain, which sort of illustrates the challenge in getting a mere few thousands to work ;-)
Its not the seperation of stacks that reduces the average stack usage, its the framing of data when a function calls a function that calls a function. With normal C code, the compiler would have to work out when data needs to be copied, and when it can be used directly "as is" from a calling function one or more levels up. In Forth, that "copy or consume" decision is programmed explicitly, and is responsible for much of the "stack noise" in the low level words that tends to dissappear in higher level words
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.