| Author |
Message |
Alex Colvin
Guest
|
Posted:
Tue Oct 25, 2005 6:23 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
| Quote: | Forth-style model, separating the return stack from the data stack
allows much shallower stacks than a C-style stack frame requires.
|
i don't see how this affects the space needed for a stack.
it's just partitioned.
| Quote: | Does C require a combine stack? It is a common implementation, but
I don't believe it is required.
|
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 |
|
| Back to top |
|
 |
Alex McDonald
Guest
|
Posted:
Tue Oct 25, 2005 7:55 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
Alex Colvin wrote:
| Quote: | as for FORTH, doesn't it require two memory fetches for each interpreter
cycle?
|
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"
http://www.zetetics.com/bj/papers/moving1.htm
--
Regards
Alex McDonald |
|
| Back to top |
|
 |
Stephen Fuld
Guest
|
Posted:
Tue Oct 25, 2005 9:27 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
"Bruce McFarling" <agila61@netscape.net> wrote in message
news:1130239063.822716.7910@o13g2000cwo.googlegroups.com...
| Quote: |
glen herrmannsfeldt wrote:
Bruce McFarling wrote:
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.
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.
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.
|
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 |
|
| Back to top |
|
 |
Del Cecchi
Guest
|
Posted:
Tue Oct 25, 2005 10:05 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
MitchAlsup@aol.com wrote:
| Quote: | A Man Crying Alone In The Wilderness wrote:
Which one do you believe requires less chip internal hardware wires?
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).
I have been shouting news of the VLIW SMP MPP FORTH formula to
Washington and has been published, since 1996, all around the St. Paul
and Minneapolis Minnesota area.
And you have sold how many chips in this time ?? versus ~2 Billion from
our side.
However, IBM/Intel continues to shout anti-news.
And make vast sums of money...to satisfied customers...
|
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.” |
|
| Back to top |
|
 |
Anton Ertl
Guest
|
Posted:
Wed Oct 26, 2005 12:15 am Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
Alex McDonald <alex_mcd@btopenworld.com> writes:
| Quote: | Alex Colvin wrote:
as for FORTH, doesn't it require two memory fetches for each interpreter
cycle?
It depends.
ITC (indirect threaded); yes, it's an indirect jump
DTC (direct threaded); no, it's a direct jump
|
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/ |
|
| Back to top |
|
 |
glen herrmannsfeldt
Guest
|
Posted:
Wed Oct 26, 2005 1:27 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
Alex Colvin wrote:
(someone wrote)
| Quote: | Does C require a combine stack? It is a common implementation, but
I don't believe it is required.
no. in fact, the return address can be passed in a register.
|
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 |
|
| Back to top |
|
 |
glen herrmannsfeldt
Guest
|
Posted:
Wed Oct 26, 2005 1:30 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
David Hopwood wrote:
| Quote: | [newsgroups trimmed]
|
(snip regarding split stacks)
| Quote: | 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.
Varargs calls can use a different (less efficient) calling convention.
|
I said "tends to" for that reason, though I believe it is rare.
As far as I know, K&R C didn't allow the different calling convention,
as the declaration requirements were not as strong.
In any case, the mechanism must exist, at least for declared varargs
routines.
-- glen |
|
| Back to top |
|
 |
glen herrmannsfeldt
Guest
|
Posted:
Wed Oct 26, 2005 1:33 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
Frithiof Andreas Jensen wrote:
(snip)
| Quote: | 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.
|
(snip)
| Quote: | 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
Powerful PHB> 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).
|
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 |
|
| Back to top |
|
 |
Bruce McFarling
Guest
|
Posted:
Wed Oct 26, 2005 1:57 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
Frithiof Andreas Jensen wrote:
| Quote: | "Bruce McFarling" <agila61@netscape.net> wrote in message
news:1130240959.459045.260080@z14g2000cwz.googlegroups.com...
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.
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.
|
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. |
|
| Back to top |
|
 |
Frithiof Andreas Jensen
Guest
|
Posted:
Wed Oct 26, 2005 2:02 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:0KadnStF05zvosLeRVn-tg@comcast.com...
| Quote: | Frithiof Andreas Jensen wrote:
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.
|
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 ;-) |
|
| Back to top |
|
 |
Rich Grise
Guest
|
Posted:
Wed Oct 26, 2005 9:16 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
On Wed, 26 Oct 2005 01:27:10 -0700, glen herrmannsfeldt wrote:
| Quote: | Alex Colvin wrote:
(someone wrote)
Does C require a combine stack? It is a common implementation, but
I don't believe it is required.
no. in fact, the return address can be passed in a register.
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.
|
I don't see why not. Just write the compiler so that a data push
pushes onto the data stack, and a call pushes on to the address
stack. You could either have the caller clean up the stack(s) or
do it in the called routine, just before it returns. I'd use
method (a), because you don't have to remember stuff from one
page to another. ;-)
Cheers!
Rich |
|
| Back to top |
|
 |
Rich Grise
Guest
|
Posted:
Wed Oct 26, 2005 10:26 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
On Tue, 25 Oct 2005 18:23:41 +0000, Alex Colvin wrote:
| Quote: | Forth-style model, separating the return stack from the data stack
allows much shallower stacks than a C-style stack frame requires.
i don't see how this affects the space needed for a stack.
it's just partitioned.
Does C require a combine stack? It is a common implementation, but
I don't believe it is required.
no. in fact, the return address can be passed in a register.
|
Not if you want reentrant code.
Cheers!
Rich |
|
| Back to top |
|
 |
Keith Williams
Guest
|
Posted:
Wed Oct 26, 2005 11:17 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
In article <pan.2005.10.26.17.27.43.715424@example.net>,
rich@example.net says...
| Quote: | On Tue, 25 Oct 2005 18:23:41 +0000, Alex Colvin wrote:
Forth-style model, separating the return stack from the data stack
allows much shallower stacks than a C-style stack frame requires.
i don't see how this affects the space needed for a stack.
it's just partitioned.
Does C require a combine stack? It is a common implementation, but
I don't believe it is required.
no. in fact, the return address can be passed in a register.
Not if you want reentrant code.
|
Addresses are passed in registers all the time and there is no
inherent limitation on reentrancy. IBM /360 and PowerPC pass
return addresses in registers (S/360 in GPRs and PPC in SRRs) and
funny enough, they allow reentrant code too. The caller simply
saves the return address before making another call (like any other
registers).
--
Keith |
|
| Back to top |
|
 |
Bruce McFarling
Guest
|
Posted:
Thu Oct 27, 2005 2:24 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
Rich Grise wrote:
| Quote: | I don't see why not. Just write the compiler so that a data push
pushes onto the data stack, and a call pushes on to the address
stack. You could either have the caller clean up the stack(s) or
do it in the called routine, just before it returns. I'd use
method (a), because you don't have to remember stuff from one
page to another. ;-)
|
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 |
|
| Back to top |
|
 |
Winfield Hill
Guest
|
Posted:
Thu Oct 27, 2005 3:21 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
Bruce McFarling wrote...
| Quote: |
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
|
stack noise?
--
Thanks,
- Win |
|
| Back to top |
|
 |
|
|
|
|