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

Groups > comp.lang.forth > #31379 > unrolled thread

Forth philosophy

Back to article view | Back to comp.lang.forth

Contents

  Forth philosophy OneArb <o1neeno1@gmail.com> - 2014-06-10 13:23 -0700
    Re: Forth philosophy Roger Levy <roger.levy@gmail.com> - 2014-06-10 14:45 -0700
    Re: Forth philosophy Elizabeth D Rather <erather@forth.com> - 2014-06-10 12:51 -1000
      Re: Forth philosophy hughaguilar96@yahoo.com - 2014-06-10 16:14 -0700
    Re: Forth philosophy Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-11 10:03 +0100
      Re: Forth philosophy visualforth@rocketmail.com - 2014-06-11 11:11 -0700
        Re: Forth philosophy Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-11 21:57 +0100
    Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-11 19:30 -0400
      Re: Forth philosophy "Elizabeth D. Rather" <erather@forth.com> - 2014-06-11 14:26 -1000
        Re: Forth philosophy rickman <gnuarm@gmail.com> - 2014-06-12 00:24 -0400
          Re: Forth philosophy "Elizabeth D. Rather" <erather@forth.com> - 2014-06-11 18:58 -1000
            Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-12 07:33 -0400
              Re: Forth philosophy AKK <akk@nospam.org> - 2014-06-12 20:39 +0200
                Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-12 23:15 -0400
                Re: Forth philosophy anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-13 17:29 +0000
                  Re: Forth philosophy AKK <akk@nospam.org> - 2014-06-14 12:26 +0200
                    Re: Forth philosophy anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-14 10:59 +0000
                      Re: Forth philosophy Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-14 07:39 -0500
                        Optimizing C compilers vs. assembly language for Forth interpreters (was: Forth philosophy) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-14 14:40 +0000
                          Re: Optimizing C compilers vs. assembly language for Forth interpreters Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-14 11:25 -0500
                            Re: Optimizing C compilers vs. assembly language for Forth interpreters Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-15 23:55 +0200
                        Re: Forth philosophy albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-14 19:45 +0000
                          Re: Forth philosophy Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-15 13:18 -0500
                      Re: Forth philosophy AKK <akk@nospam.org> - 2014-06-16 21:14 +0200
                        Re: Forth philosophy Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-16 22:41 +0200
                          Re: Forth philosophy AKK <akk@nospam.org> - 2014-06-17 13:32 +0200
                            Re: Forth philosophy Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-17 15:02 +0200
                        Re: Forth philosophy mhx@iae.nl - 2014-06-16 13:41 -0700
          Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-12 07:33 -0400
          Re: Forth philosophy barrym95838@yahoo.com - 2014-06-13 21:48 -0700
            Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-14 01:01 -0400
        Re: Forth philosophy Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-12 03:02 -0500
        Re: Forth philosophy albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-12 10:43 +0000
        Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-12 07:32 -0400

Page 2 of 2 — ← Prev page 1 [2]

#31570 — Re: Optimizing C compilers vs. assembly language for Forth interpreters

Andrew Haley wrote:

> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Actually it does not require expensive optimizations to get the branch
>> prediction accuracy of switch threading up to the accuracy we see with
>> well-implemented threaded-code:
> 
> Sure, but that is a very different matter: there's a lot more to
> optimizing a big interpreter than branch prediction, important though
> it is.

Yes, the other critical thing is register allocation.  This is another place 
where GCC and LLVM have troubles, at least on awful register starved 
architectures like x86.  The way to allocate registers for an interpreter is 
to have life range splitting, and then choose the most frequently used 
variables to live in registers across those switch jump boundaries, and be 
temporarily spilled out in those operations which need more registers or 
call functions where the registers might be globbered (several registers are 
caller-save, and in GCC out of scope for allocating as registers once you 
have a single call to something inside your VM).

The trouble with unfolding the switch statement nowadays also happens on 
computed gotos in GCC: Instead of leaving the gotos where they are, GCC 
folds them into one single central dispatcher goto, then tries to do very 
time-consuming and counter-productive analysis on it (which we disable with 
a switch, because the resulting code doesn't even run!), and the replicates 
the code again, but at that point is unable to optimize a few moves away.

GCC 2.95.2 compiled

jmp -4(IP)

and GCC 4.x compiles

movl -4(IP),%somereg
movl %somereg,%anotherreg
jmp %anotherreg

This is so obviously going wrong that the best thing to fix this problem 
would be to simply don't try to analyze control flow over computed gotos: It 
doesn't help, it produces code that doesn't and can't run (at least during 
the 3.x timeframe, when we fell over that problem), and even when you 
disable that fuckup, it still produces something that is considerably worse 
than it could be by applying much simpler rules.

But as I tried to release Gforth 0.7.3 through the official GNU way on 
Friday (something I've avoided on 0.7.1 and 0.7.2), and am still failing to 
get the required Permit A 38 (it is actually easier to run a complete server 
which allows me to publish my software than getting the GNU project to push 
two files into the gforth dictionary), it seems to be built into the way 
most humans think: way too complicated.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#31541

In article <2_SdnT25uJH53wHOnZ2dnUVZ_rednZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> AKK <akk@nospam.org> writes:
>>>
>>>But as you know, the efficiency of the giant switch dispatch method
>>>for VMs is widely discussed, mostly in the context of CPU cache
>>>stallment caused by target address misprediction. But today's
>>>professional C compilers (say Clang, gcc, Intel's) do such a lot for
>>>optimizing this through clever jump table generation, loop
>>>enrollment, alignments etc, that the effort to dig into handcrafted
>>>assembler constructs or such practically never pays off any more.
>>
>> I have read similar claims about the optimization capabilities of
>> "optimizing" compilers a lot over the last decades, and they were
>> typically just fantasy.
>
>I agree.  Optimizing a gigantic switch statement is hard, and typical
>compilers will simply abandon the more expensive passes that execute
>in nonlinear time.  I've never seen an optimizing compiler for a
>high-level language that can emit code which gets close to a
>hand-written interpreter.  Also, there are some things that are
>difficult to express in most high-level languages but simple in
>assembly language, e.g. JSR threading.

Even as early in the 80's I had a c-code routine (that was pretty
complicated, and the heart of comparing formatted text) of a few pages.
That was VAX VMS. I inspected the assembler code, and could not find
anything to improve. Had I written it in assembler, I would've used
macro's in a defensive manner, resulting in less efficient code.

This was one of the cases in my career where speed really mattered.
The PDP code to replace, run for days on some jobs.
The VAX code turned out to be completely I/O bound.

A more recent example was the solution for an Euler problem, a novice
submitted. The code was naive, but the optimisation of gcc made it
run as fast as could be expected from less naive coding.

>
>Andrew.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#31557

Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> In article <2_SdnT25uJH53wHOnZ2dnUVZ_rednZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>>Optimizing a gigantic switch statement is hard, and typical
>>compilers will simply abandon the more expensive passes that execute
>>in nonlinear time.  I've never seen an optimizing compiler for a
>>high-level language that can emit code which gets close to a
>>hand-written interpreter.  Also, there are some things that are
>>difficult to express in most high-level languages but simple in
>>assembly language, e.g. JSR threading.
> 
> Even as early in the 80's I had a c-code routine (that was pretty
> complicated, and the heart of comparing formatted text) of a few
> pages.  That was VAX VMS. I inspected the assembler code, and could
> not find anything to improve. Had I written it in assembler, I
> would've used macro's in a defensive manner, resulting in less
> efficient code.
> 
> This was one of the cases in my career where speed really mattered.
> The PDP code to replace, run for days on some jobs.
> The VAX code turned out to be completely I/O bound.
> 
> A more recent example was the solution for an Euler problem, a
> novice submitted. The code was naive, but the optimisation of gcc
> made it run as fast as could be expected from less naive coding.

Oh, yes, that's definitely true in many cases.  Threaded-code
interpreters, though, seem to be a very problematic case for
optimizers.  In particular, finding a near-optimal solution for global
register allocation of a huge routine with maybe a hundred basic
blocks is very difficult.

Andrew.

[toc] | [prev] | [next] | [standalone]

#31598

Am 14.06.2014 12:59, schrieb Anton Ertl:
> AKK <akk@nospam.org> writes:
>> Am 13.06.2014 19:29, schrieb Anton Ertl:
>>> AKK <akk@nospam.org> writes:
>>>> I know that you know that modern compilers can be incredibly 'ingenious'
>>>> in generating code from switch() statements. The VM litterature is full
>>>> of it. Also the old wisdom 'computed goto's are better' has become
>>>> folkloristic meanwhile.
>>>
>>> Are you serious?  If you are, please cite references to the VM
>>> literature you are referring to.
>>>
>>> - anton
>>>
>>
>> Sorry for my slightly misleading formulation. It was not referring to
>> abandon computed goto's or labels-as-values (I will not look up the
>> correct term now).
>>
>> But as you know, the efficiency of the giant switch dispatch method for
>> VMs is widely discussed, mostly in the context of CPU cache stallment
>> caused by target address misprediction. But today's professional C
>> compilers (say Clang, gcc, Intel's) do such a lot for optimizing this
>> through clever jump table generation, loop enrollment, alignments etc,
>> that the effort to dig into handcrafted assembler constructs or such
>> practically never pays off any more.
>
> I have read similar claims about the optimization capabilities of
> "optimizing" compilers a lot over the last decades, and they were
> typically just fantasy.  In this case, my experience is that gcc does
> not do anything to optimize switch threading even to the extent that
> is possible, and that the people among the gcc maintainers that work
> on such things have at most a cargo culture understanding of the
> relevant parts of computer architecture, in particular indirect branch
> prediction (as demonstrated in their answers to bug reports).  Maybe
> this has changed in the meantime, but I doubt it.
>
> And given that you do not support your claim that "the VM literature
> is full of it" with references even when asked to, I won't invest any
> work in checking your claims (and in any case, you fail to specify
> which compiler versions you are referring to, so your claim cannot be
> falsified and is therefore unscientific).
>
>> Worse: using non-standard C constructs may bite you deeply later, when
>> you have to change compilers or target systems.
>
> What happened in practice is that it bit us when the gcc maintainers
> changed.
>
> - anton
>

IMO you seem too narrowly focussed on runtime speed. Of course one can 
always wring a dry towel drier. But at which costs and for what? With 
"being bitten later" I meant the unwelcome expensive necessity to having 
to change the C or assembler code later, because of altoo clever early 
optimisation.

[toc] | [prev] | [next] | [standalone]

#31599

AKK wrote:
> IMO you seem too narrowly focussed on runtime speed. Of course one can
> always wring a dry towel drier. But at which costs and for what? With
> "being bitten later" I meant the unwelcome expensive necessity to having
> to change the C or assembler code later, because of altoo clever early
> optimisation.

A documented extension of a particular compiler is not a "premature 
optimization".  The problem we have is that the current GCC team doesn't 
think that C should be a portable assembler; they rather think it should be 
a language that is specified by the C standard, ignoring that the 
unspecified parts of the C standards are to be filled in with life by the 
implementers, and RMS did that.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#31607

Am 16.06.2014 22:41, schrieb Bernd Paysan:
> AKK wrote:
>> IMO you seem too narrowly focussed on runtime speed. Of course one can
>> always wring a dry towel drier. But at which costs and for what? With
>> "being bitten later" I meant the unwelcome expensive necessity to having
>> to change the C or assembler code later, because of altoo clever early
>> optimisation.
>
> A documented extension of a particular compiler is not a "premature
> optimization".  The problem we have is that the current GCC team doesn't
> think that C should be a portable assembler; they rather think it should be
> a language that is specified by the C standard, ignoring that the
> unspecified parts of the C standards are to be filled in with life by the
> implementers, and RMS did that.
>

The same argument applies to STANDARD Forth too.  ;-)

[toc] | [prev] | [next] | [standalone]

#31609

AKK wrote:

> Am 16.06.2014 22:41, schrieb Bernd Paysan:
>> A documented extension of a particular compiler is not a "premature
>> optimization".  The problem we have is that the current GCC team doesn't
>> think that C should be a portable assembler; they rather think it should
>> be a language that is specified by the C standard, ignoring that the
>> unspecified parts of the C standards are to be filled in with life by the
>> implementers, and RMS did that.
> 
> The same argument applies to STANDARD Forth too.  ;-)

Of course.  And we, the Gforth team, treat all extensions as something we 
will support in future, too.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#31600

On Monday, June 16, 2014 9:14:22 PM UTC+2, AKK wrote:
> Am 14.06.2014 12:59, schrieb Anton Ertl:
[..]
> IMO you seem too narrowly focussed on runtime speed. Of course one can 
> always wring a dry towel drier. But at which costs and for what? With 
> "being bitten later" I meant the unwelcome expensive necessity to having 
> to change the C or assembler code later, because of altoo clever early 
> optimisation.

I would never have been attracted to Forth if it were slow.
There are great advantages to even slow Forth (like simplicity
in the face of new challenges), but these are not demonstrated 
in easily available programs or on common/bare systems, and 
beginners would quite probably not recognize them.

-marcel

[toc] | [prev] | [next] | [standalone]

#31449

On Thu, 12 Jun 2014 00:24:59 -0400, rickman <gnuarm@gmail.com> wrote:
> On 6/11/2014 8:26 PM, Elizabeth D. Rather wrote:
>> On 6/11/14 1:30 PM, Rod Pemberton wrote:

>>> Also, reducing everything to the simplest concept also interferes
>>> with developing and testing of more complex ideas.  The ability to
>>> grasp the entire problem or implementation at once can be obfuscated
>>> by using small pieces.  It's much better to see the entire problem,
>>> in one place, at once, not a whole bunch of jumbled little pieces
>>> that have to be put together, correctly.
>>
>> Again, this is not my experience. I am not aware that Mr. Pemberton has
>> ever worked on any substantial Forth applications (in addition to
>> writing his own Forth, with some guidance here), or spent time learning
>> Forth programming and debugging strategies. Although I am presently
>> retired, I worked on major commercial Forth applications for over 30
>> years, some of which continued in use for decades.
>
> I agree.  Sometimes I wonder if Rod really believes the things he says
> or if he is just free associating and then working to defend his
> statement like playing a game of go.
>

Well, I used to think comments of disbelief and contradiction
here was just argumentative people playing the "devil's advocate,"
but the frequency of such comments here is just too excessive.
I've since learned that almost everyone here who makes such a
comment has usually never programmed in any language other than
Forth and generally has little to no computer science background.
So, today, I tend to ignore such comments.  I just mention this
for your future reference.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#31513

On Wednesday, June 11, 2014 9:24:59 PM UTC-7, rickman wrote:
> 
> Every time someone mentions detecting stack over/underflows I think
> of Jeff Fox.  Back when I was still struggling with why I should try
> to use Forth the lack of tools (in the context of the typical C
> methodology) was being discussed including stack error detection.
> Jeff made the point that it wasn't needed as long as the programmer
> could count...  I think his words were something like, "Stack errors
> just mean that you can't count".  I'm not actually quoting him, I
> searched and could only find my posts para-phrasing him.  In fact I
> seem to do this on a regular basis, lol.
> 
[snip] 
> 
> I miss Jeff.
> 
[snip]
> 
> Rick

I have just recently discovered a few of Jeff's essays and posts here
 in c.l.f. and elsewhere ... very entertaining and informative.

Is Jeff no longer among us?

Mike

[toc] | [prev] | [next] | [standalone]

#31514

On Sat, 14 Jun 2014 00:48:02 -0400, <barrym95838@yahoo.com> wrote:

> I have just recently discovered a few of Jeff's essays and posts here
>  in c.l.f. and elsewhere ... very entertaining and informative.
>
> Is Jeff no longer among us?
>

https://groups.google.com/d/msg/comp.lang.forth/YiJjysy6NbU/8z4c5Owa7MAJ

RP

[toc] | [prev] | [next] | [standalone]

#31440

Elizabeth D. Rather <erather@forth.com> wrote:
> On 6/11/14 1:30 PM, Rod Pemberton wrote:
> 
>>> 2) What would be ways to apply Forth way of thinking to other languages ?
>>
>> I've answered this one in the past.  There is minimal benefit in other
>> languages.
> 
> The book Thinking Forth, which I recommended above, contains an
> entire section in which programmers in several fields recount how
> using Forth has benefited them in projects using other languages.

I'm sure that's true.  I've come across elegant designs and thought
"That's very Forth", and later discovered that the author had been a
Forth programmer.

Andrew.

[toc] | [prev] | [next] | [standalone]

#31445

In article <0JCdneuVOuwhbgXOnZ2dnUVZ_oadnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 6/11/14 1:30 PM, Rod Pemberton wrote:
>> On Tue, 10 Jun 2014 16:23:25 -0400, OneArb <o1neeno1@gmail.com> wrote:
>>
>>> I have been puzzled about Forth and a sideline supporter.
>>>
>>> While trying to use objects, I ran into,  performance questions, the
>>> inability to create granular objects, maintenance complexity.
>>>
>>> My quest for a solution led to Forth.
>>>
>>> 1) How would I explain, in the most compact way, the benefit of
>>> breaking down a program into words that do little ?
>>
>> In Forth, there is a benefit because Forth has no syntax errors or
>> compiler warnings.  There is nothing to tell you about incorrectness.
>> I.e., you can only detect errors in Forth by thoroughly testing every
>> bit of code you coded, which is easiest if they are small pieces.
>> There is nothing to warn you about boundary cases, integer overflow,
>> unused code, or the mis-use of an integer as an address.
>
>This is simply not true of any Forth I have ever worked on. It is
>certainly true that Forth has limited syntax and no enforcement of data
>types, but that doesn't mean there's no checking. Virtually every Forth
>will report stack underflow, which identifies a large number of errors
>(including incomplete structures), attempts to access non-existent
>memory, or undefined words, along with a variety of other
>easily-detectable faults.

A large class of errors is accompagnied by a stack mismatch.
There is always a overall loop in a solution of my euler problems.
If I stick !CSP and ?CSP in there, I catch most of the errors
during tweaking, speeding up the program.

>
>> Also, reducing everything to the simplest concept also interferes
>> with developing and testing of more complex ideas.  The ability to
>> grasp the entire problem or implementation at once can be obfuscated
>> by using small pieces.  It's much better to see the entire problem,
>> in one place, at once, not a whole bunch of jumbled little pieces
>> that have to be put together, correctly.
>
>Again, this is not my experience. I am not aware that Mr. Pemberton has
>ever worked on any substantial Forth applications (in addition to
>writing his own Forth, with some guidance here), or spent time learning
>Forth programming and debugging strategies. Although I am presently
>retired, I worked on major commercial Forth applications for over 30
>years, some of which continued in use for decades.
>
>The process of designing and implementing a project certainly involves
>starting with a grasp of the entire project, from the top down. One
>identifies major subsets (which, for a very large project, can be
>assigned to different programming teams) and works out the structure of
>the database, if any (and for a large project there usually is). Most
>importantly, the interfaces between the subsystems must be designed.
>Indeed, the design phases are not substantially different from the
>design of any other significant application.

>
>Implementation can begin at both ends. If there is custom hardware
>involved (most of my experience has been with embedded systems) drivers
>have to be written and tested. Concurrently, work can begin on the
>top-level structures and user interface with sample or simulated data.
>
>It is very easy in Forth to develop and test low-level drivers,
>particularly with knowledge of how they will be managed or the data
>stored and used. The inherent interactivity of Forth, as well as the
>ability to structure drivers in tiny routines of only a line or two,
>makes these things not only very easy to test but also very robust.
>
>At the other end, the ability to model user interfaces and other issues
>at higher levels and test them incrementally and interactively is a huge
>benefit.
>
>Throughout the project, the fact that individual functions at all levels
>have been isolated, coded, tested, and then reused many times makes the
>entire project far more robust than the more common practice of
>"programming by copy/paste".

In general this is an excellent overview. May I take that to the fore:
" functions ... reused many times ... " . A reused function is not better
tested that just module tested, its specification is likely to be good,
not only in the sense of correct, but in the sense of sensible.

>
>>> 2) What would be ways to apply Forth way of thinking to other languages ?
>>>
>>
>> I've answered this one in the past.  There is minimal benefit in other
>> languages.
>
>The book Thinking Forth, which I recommended above, contains an entire
>section in which programmers in several fields recount how using Forth
>has benefited them in projects using other languages.
>
>> E.g., breaking C down into a bunch of small procedures which do little
>> to nothing per procedure call results in a huge mess of nested procedure
>> calls.  This adds call overhead.  The prolog(ue) or epilog(ue) of a
>> procedure adds a half-dozen or more instructions each.  Most of the
>> overhead can be optimized away, but not all of it.
>
>There is a lot of procedure call overhead in C. Forth, on the other
>hand, has been designed from the outset to minimize such overhead. Of
>the two most common Forth implementation strategies, both (in a good
>implementation) have very low overhead:
>
>* In the "classical" indirect threaded model, it can take as few as one
>or two machine instructions to call a word. No instructions are required
>for managing parameter passing, since parameters are already on the
>stack and the results will be left there. And the implementations I am
>familiar with don't even save and restore registers in most cases, since
>register allocation is designed to minimize the need. For example, you
>may have certain registers allocate for stack pointers, and the
>accumulator(s) always left free for use without saving and restoring.
>
>* In more modern compile-to-code Forths with optimizing compilers, small
>primitives may be incorporated in optimized inline code, and for larger
>routines there is literally only the call/return instructions.
>
>So, what you end up with is a large number of 'words' each of which is
>extremely easy to test interactively, and which can be reused
>extensively with minimal overhead. The result is a very compact and very
>reliable program.

And then there is the speed of modern processors. Euler problems are
notoriously performance-hungry, Yet I go by with a slow indirect
threaded Forth.

>
>> You'd have to use
>> a bunch of special compiler features to inlign many of the procedures
>> to reduce the effect of the extra, unneeded nesting that resulted from
>> "factoring" in C.  So, applying Forth's "factoring" concept to C would
>> hinder C.  In C, testing a procedure is easy, but testing small pieces
>> of code as separate procedures which call each other is time consuming.
>
>Yes, of course it would hinder C, because C is designed to optimize
>different things.
>
>> Of course, I'm not a fan of "Bottom's Up" design, but "Top Down".
>> I've seen all sorts of bad code with "Bottom's Up" programmers in C.
>> Forth is inherently a "Bottom's Up" language.
>
>The procedure is top-down design, bottom-up implementation and testing.
>Works great. Throughout my career, it was typical for us to complete
>significant projects in roughly a quarter of the time they had been
>estimated to take using C.
>
>...
>>
>> Ms. Rather mentioned code density.  Increased code density is fine when it
>> has a purpose.  It's not an advantage in it's own right.  There must be a
>> reason for using it.  Otherwise, it doesn't provide any advantage.  You
>> have to be careful when people tout things as facts or rules without them
>> explaining why it is a fact or rule.  I.e., people forget about the
>> reasons and the constraints.
>
>Yes. There is definitely a reason: code developed in this way is easier
>to test thoroughly, leading to a more reliable and more easily
>maintained result. The reduced size is also a significant advantage in
>many embedded projects.
>
>> For CISC processors, code density reduced the amount of memory needed when
>> computer memory was expensive.  The same is true of Forth.  Interpreted
>> Forths have a higher code density which reduced the need for memory on
>> early machines that only had a few KB of memory.
>>
>> However, code density for a modern Forth means that Forth is interpreted.
>> Interpreters are slow.  They re-implement a processor in software, when
>> a processor in hardware is already available to you.  So, a high code
>> density today usually means slower.
>
>Fortunately, professional-grade modern Forths use optimizing compilers.
>The result is not only faster code than the indirect threaded model, it
>becomes even more compact.
>
>> IMO, compiled Forths won't see much if any increase in code density
>> after compilation.  And, if they do, their more compact code is likely
>> to result in a slower implementation.  In part, the increase in code
>> density comes in exchange for a less efficient algorithm.  In part,
>> the increase in code density comes in exchange for shorter, but less
>> efficient processor instructions.  When code is compiled, code density
>> is only important if memory is expensive or constrained, which it isn't
>> in modern machines.  Shorter machine instructions, today, do less work
>> with MISC, RISC, and RISC-like post-CISC CISC instruction sets.  Speed
>> is about doing the most work per time unit.  I.e., code density is of
>> no value to compiled Forth.
>
>When FORTH, Inc. went to optimizing compilers, programs on 16-bit and
>32-bit processors were a factor of 4 faster and nearly 50% smaller. On
>8-bit microcontrollers, they were significantly faster and about the
>same size.

Sorry but I hated to snip any of this.

It makes me think of the "anti-duehring" of Friedric Engels.
Duehring has long been forgotten. The only reason his name lives
on is that Engels took offense to his teachings and wrote an
excellent explanation of Marxist philosophy, by shattering his
arguments.

>
>Cheers,
>Elizabeth


Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#31448

On Wed, 11 Jun 2014 20:26:35 -0400, Elizabeth D. Rather  
<erather@forth.com> wrote:
> On 6/11/14 1:30 PM, Rod Pemberton wrote:

>> [snip]
> [snip]

I've responded to some of these statements previously, and indicated
why I believe they're incorrect.

> Fortunately, professional-grade modern Forths use optimizing compilers.  
> The result is not only faster code than the indirect threaded model, it  
> becomes even more compact.
> [...]
> When FORTH, Inc. went to optimizing compilers, programs on 16-bit and  
> 32-bit processors were a factor of 4 faster and nearly 50% smaller. On  
> 8-bit microcontrollers, they were significantly faster and about the  
> same size.
>

This is general ITC Forth solution compared to the same general compiled
Forth solution.  It's not compiled Forth for a general Forth solution as
compared to the most efficient routine implementable in highly optimized C.


Rod Pemberton

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web