Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #21531

Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!)

Show all headers | View raw

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:ncqdnQzsE--Rsf7MnZ2dnUVZ_qKdnZ2d@supernews.com...

> I don't remember saying Hobbit was ideal.

You didn't.

> I said "The only CPU I know that was really designed for
> efficient execution of C is the AT&T Hobbit, previously known as
> CRISP."  This statement is true.  General-purpose RISC designs
> can run C fast because they are fast brute force computing
> engines, not because they are particuarly optimized for C.
>

Your statements indicate that C needs additional architecture
features for optimum performance.  I just don't see that as being
the situation.  SmallC is a prime example of not needing
additional features for C.  It uses two registers and a stack.
I've mentioned this previously on c.l.f., but not to you directly.
Of course, you could argue it's not optimal since it's code is
slow as compared to that from an optimizing C compiler, but where
exactly does the "not optimal for C" monicker end?  Does it end
with registers? some sort of C machine model? or compiler
features: register scheduling? integer optimization? tail call
optimization?  You can always add another "needed" feature in the
it's "not optimal enough yet for C" category.

As stated elsewhere, I saw nothing in the CRISP documents that I
thought was an improvement for C.  C and B was fitted by it's
creators onto a variety of computing platforms, many of which are
very similar, if not identical, to modern processors.  What didn't
work well in B or C was changed or removed.  I.e., C was optimized
for a variety of processors.  And, C doesn't need much for a
decent, minimal implementation to be implemented, just like Forth.


Rod Pemberton

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-05 16:45 -0400
  Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-06 03:00 -0500
  Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-08 16:11 +0000
    Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-08 15:43 -0500
      Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-08 23:49 -0400
        Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-09 04:02 -0500
      Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-09 07:03 +0000
        Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-09 04:04 -0500
    Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-04-08 14:34 -0700
      Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-09 00:02 +0200
      Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-09 07:06 +0000

csiph-web