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 1 of 2  [1] 2  Next page →

#31379 — Forth philosophy

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 ?

2) What would be ways to apply Forth way of thinking to other languages ?

  - which Forth feature is most able to be of value for other language programmers ?

3) Was there ever an attempt to host / embed Forth within another compiler ?

  - the intent being to benefit from

     . the entire host library / platform stack
     . Forth dictionary code organizing approach

  - what would be the likely technical hurdles ?

[toc] | [next] | [standalone]

#31382

> 1) How would I explain, in the most compact way, the benefit of breaking down a program into words that do little ?

Smaller overall project size due to more aggressive factoring than other languages and thus more reuse.  Easier testing and verification not just because it's interactive but because the design of each word ought to be simple (ask yourself can you describe exactly what each word does in a sentence).

> 2) What would be ways to apply Forth way of thinking to other languages ?

Just follow similar principles.  Short, simple functions, with simple names.  Static compilation over dynamic instantiation.  Custom "systems" that accelerate development.  Don't program for too many contingencies.  Program in such a way that more easily accommodates inevitable change.

>   - which Forth feature is most able to be of value for other language programmers ?

Are you talking about programmers who write languages or programmers who use other languages?  

If the first: Too many to choose from.  Keeping it simple.  Avoiding fixed syntax rules.  Compile-time and run-time.  And now edit-time, as demonstrated by ColorForth.  Staying out of the programmer's way.  Data stack.

If the second: Interactive play and investigation into application problems.

> 3) Was there ever an attempt to host / embed Forth within another compiler ?

??? Not sure how that would be useful!

>   - the intent being to benefit from
> 
> 
> 
>      . the entire host library / platform stack
> 
>      . Forth dictionary code organizing approach
> 
> 
> 
>   - what would be the likely technical hurdles ?

Ohhhh.  :P

This in my mind is analogous to Lua's Host-Slave model.  

You need to AT LEAST provide API access to the slave Forth.

Then I'd say the next most important thing is data access.  This would be somewhat hairy, probably requiring you to manipulate wordlists for Forth and then provide some lowlevel routines for getting at data that Forth and the other language whatever that is can both access.

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

#31384

On 6/10/2014 10:23 AM, OneArb 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 ?

* Code density: A well-factored program has a minimum of duplicated 
code. Programs will be significantly smaller (how much, of course, 
depends on how well-factored), which can be especially significant in 
embedded systems, an area where Forth really excels.

* Code reliability: small, well-factored functions are easier to design, 
test, and maintain over time.

> 2) What would be ways to apply Forth way of thinking to other languages ?
>
>    - which Forth feature is most able to be of value for other language programmers ?

This interesting question was discussed at some length, along with other 
philosophical issues, in Thinking Forth 
http://www.amazon.com/dp/0976458705/?tag=mh0b-20&hvadid=3523683793&ref=pd_sl_iao0y4mv6_ee. 
Although it's rather dated, the principals it discusses are still valid.

> 3) Was there ever an attempt to host / embed Forth within another compiler ?
>
>    - the intent being to benefit from
>
>       . the entire host library / platform stack
>       . Forth dictionary code organizing approach
>
>    - what would be the likely technical hurdles ?
>

Not sure what you mean by this. Forth systems have been written in C, 
Java, and probably other languages. There are other versions that run 
under all the major OSs and can access their libraries. Of course, the 
more you rely on other languages and libraries the less benefit you 
derive from the aspects of Forth.

If you want to explore further, I recommend you do some Forth 
programming. My company, FORTH, Inc., offers free evaluation versions of 
our OS-resident product SwiftForth (Windows, Linux, OSX) and our 
cross-compiler line for embedded systems, SwiftX (supporting most common 
microcontrollers and hosted on Windows, Linux, OSX) at www.forth.com. 
Both are very well-documented and include a pdf of the Forth 
Programmer's Handbook, a contemporary technical manual applicable to all 
current standard Forths. You may also benefit from my book Forth 
Application Techniques 
http://www.amazon.com/Forth-Application-Techniques-Notebook-Edition/dp/1419685767/ref=pd_cp_b_2 
which is a detailed tutorial for Forth beginners.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#31386

On Tuesday, June 10, 2014 3:51:15 PM UTC-7, Elizabeth D Rather wrote:
> If you want to explore further, I recommend you do some Forth 
> programming. My company, FORTH, Inc., offers free evaluation versions of 
> our OS-resident product SwiftForth (Windows, Linux, OSX) and our 
> cross-compiler line for embedded systems, SwiftX (supporting most common 
> microcontrollers and hosted on Windows, Linux, OSX) at www.forth.com. 
> Both are very well-documented and include a pdf of the Forth 
> Programmer's Handbook, a contemporary technical manual applicable to all 
> current standard Forths. You may also benefit from my book Forth 
> Application Techniques 
> http://www.amazon.com/Forth-Application-Techniques-Notebook-Edition/dp/1419685767/ref=pd_cp_b_2 
> which is a detailed tutorial for Forth beginners.

Sell! Sell! Sell!

Actually, he is most likely a high-school student who was assigned to write a paper on an obscure topic (the teacher requires it to be an obscure topic so the Wikipedia article will be too short to provide adequate material to puff out the paper to the required number of pages). He won't spend any money at Forth Inc. --- you are going to have to catch bigger fish than this, to continue living in Hawaii.

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

#31397

OneArb 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.

Probably the best Macro-Assembler in the World for construction Application 
Specific Languages.
 
> 1) How would I explain, in the most compact way, the benefit of breaking
> down a program into words that do little ?

I use Forth as a "Component Oriented Development Environment" The benefit of 
decomposition into the smallest practical unit, that performs one action 
exceptionally well, is that it becomes easier to focus on its correctness of 
behaviour and fully understand all of its function. You can even take the 
testing to harsher modes in order to try and discover where its limits lie.

Much of Forth philosophy follows the teachings of Polya and Yourden (well 
worthwhile references to explore).
 
> 2) What would be ways to apply Forth way of thinking to other languages ?

I am sure others have done so to some extent or other with varying degrees 
of success. However, it can become expensive to do so for many of the Algol 
style languages and might not fit too well in some circumstances.
 
>   - which Forth feature is most able to be of value for other language
>   programmers ?

Functional Granularity and Coherence.
 
> 3) Was there ever an attempt to host / embed Forth within another compiler
> ?
> 
>   - the intent being to benefit from
> 
>      . the entire host library / platform stack
>      . Forth dictionary code organizing approach
> 
>   - what would be the likely technical hurdles ?

I will let others answer that last point. They will know far better than I.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#31413

On Wednesday, June 11, 2014 5:03:40 AM UTC-4, Paul E Bennett wrote:

> Much of Forth philosophy follows the teachings of Polya and Yourden (well 
> worthwhile references to explore).

What are the teachings of Polya and Yourden?

Google presented only one useful link: http://www.nobullwork.com/
This page does only show quotations, one of them is this:
Forth is a programmer amplifier. ~ Chuck Moore

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

#31419

visualforth@rocketmail.com wrote:

> On Wednesday, June 11, 2014 5:03:40 AM UTC-4, Paul E Bennett wrote:
> 
>> Much of Forth philosophy follows the teachings of Polya and Yourden (well
>> worthwhile references to explore).
> 
> What are the teachings of Polya and Yourden?
> 
> Google presented only one useful link: http://www.nobullwork.com/
> This page does only show quotations, one of them is this:
> Forth is a programmer amplifier. ~ Chuck Moore

The work by George Polya is now available as a pdf file.
<https://notendur.hi.is/hei2/teaching/Polya_HowToSolveIt.pdf>

For Edward Nash Yourdon, rather than list a whole raft of links I will just 
give you the Wikipedia entry about him. Several of his works are listed 
there.
<http://en.wikipedia.org/wiki/Edward_Yourdon>

Essentially, Polya gave a method for solving problems in a mathematically 
guided manner and is the basis for decent decomposition of a problem space 
towards discovering a solution space. 

Yourdon concentrated on aspects of what makes good software functions in 
Real Time Systems and underpins some of the rules for constructing Forth 
Words.


-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#31425

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.

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.

> 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.

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.  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.

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.

> 3) Was there ever an attempt to host / embed Forth within another  
> compiler ?
>

I'm not sure about within another compiler, but minimal Forths have
been implemented in a wide variety of projects: MUDs, Bitcoin
scripting etc.


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.

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.

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.


Rod Pemberton

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

#31427

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.

> 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".

>> 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.

> 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.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#31435

On 6/11/2014 8:26 PM, Elizabeth D. Rather wrote:
> On 6/11/14 1:30 PM, Rod Pemberton wrote:
>>
>> 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.

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.

I thought about that one for a long time.  Like a typical Forth program, 
the sort you would see from Chuck himself, it was actually a very highly 
distilled statement of the nature of Forth debugging.  It was in a 
sense, a haiku on Forth programming, terse, yet full of meaning.

I miss Jeff.


>> 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.

-- 

Rick

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

#31436

On 6/11/14 6:24 PM, rickman wrote:
> On 6/11/2014 8:26 PM, Elizabeth D. Rather wrote:
>> On 6/11/14 1:30 PM, Rod Pemberton wrote:
>>>
>>> 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.
>
> 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.
>
> I thought about that one for a long time.  Like a typical Forth program,
> the sort you would see from Chuck himself, it was actually a very highly
> distilled statement of the nature of Forth debugging.  It was in a
> sense, a haiku on Forth programming, terse, yet full of meaning.
>
> I miss Jeff.

Well, I disagree with Jeff on this one. Sure, if you always counted 
correctly you wouldn't make stack errors. But although I have worked 
with some really outstanding Forth programmers, I find that they always 
check for stack errors (signaled by either a "stack empty" message or 
something left on the stack when there shouldn't be). It is basic Forth 
practice to always check the stack after loading your code or executing 
something.

>>> 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'm sure the fact that he wrote his Forth in C influenced his 
opinion. Some of the code he showed us here is pretty tortured, partly 
because he didn't have Forth programming background but mostly because 
of requirements imposed by C.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#31450

On Thu, 12 Jun 2014 00:58:01 -0400, Elizabeth D. Rather  
<erather@forth.com> wrote:
> On 6/11/14 6:24 PM, rickman wrote:

>> 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'm sure the fact that he wrote his Forth in C influenced his
> opinion.

I don't see why.  As I've stated many times to Hugh who doesn't bother
to remember this either, I've not used the classic method of implementing
Forth in C: switch().  My implementation uses ITC with an interpreter
in C.  It's virtually identical to implementing a Forth in assembly.
I.e., if I had implemented it in assembly, it wouldn't be different,
or not much.

> Some of the code he showed us here is pretty tortured, [...]

I think that's a mischaracterization.

First, it's wasn't C code that was posted and "tortured" as I think
you've implied here ...

Second, the one "tortured" Forth example was due to a failed attempt
to relocate a few high-level Forth words to be defined much earlier
in the dictionary.

Once the failed optimization was backed out and removed, the resulting
Forth code was identical to what I had months before.

The failed optimization wouldn't have even been possible if it had
been revealed that my Forth was missing an certain implementation
detail.  The issue for that was discussed in depth here some months
earlier, which you might've considered to be "tortured" too.

> [...] partly because he didn't have Forth programming background [...]

I don't believe that has anything to do with it.  Lack of any serious
documentation on Forth implementation details has been a far bigger
hindrance, IMO.

As you should recall, everything I've implemented passes Hayes core tests
(about 2/3rds), except one: nul terminated strings, which can be fixed
with the addition of a single byte.  I know one of my loop constructs is
broken, but I must leave that for the future.  +LOOP has no way to obtain
an "overflow bit" from C ...  Many of the high-level definitions match
widely available definitions for well known Forth words.  Some of this
was by happenstance, i.e., only one way or one best way or simple, and
others were because I searched c.l.f. for standardized, commonly known,
and widely used definitions for compatibility.  As you may recall, I've
also tested a bunch of Forths for compatibility of functionality on
different issues.

My stack words are a bit odd at the moment because I was defining them
in Forth to reduce C dependence and using some lower-level primitives
to do so.  But, they can be backed out and reverted quickly and in the
future.

> [...] but mostly because of requirements imposed by C.

So far, there are only a few serious issues with C, IMO.  One issue affects
the layout of primitives in the dictionary, but only the primitives since
they're setup in C.  Most of my primitives, currently, are non-Forth words,
but a few are Forth words, so this doesn't generally create any problem.
Another issue restricts what values can be placed in the CFA, i.e., must
call a C function and can't arbitrarily just jump into any Forth word.
Those are the only two serious issues that I recall.


Rod Pemberton

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

#31459

Am 12.06.2014 13:33, schrieb Rod Pemberton:
> I don't see why.  As I've stated many times to Hugh who doesn't bother
> to remember this either, I've not used the classic method of implementing
> Forth in C: switch().  My implementation uses ITC with an interpreter
> in C.  It's virtually identical to implementing a Forth in assembly.
> I.e., if I had implemented it in assembly, it wouldn't be different,
> or not much.

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.

How did you then handcraft a better 'virtual-identical-to-assembler' 
Forth instructions compiler in C?

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

#31469

On Thu, 12 Jun 2014 14:39:14 -0400, AKK <akk@nospam.org> wrote:
> Am 12.06.2014 13:33, schrieb Rod Pemberton:

>> [snip]
> How did you then handcraft a better 'virtual-identical-to-assembler'
> Forth instructions compiler in C?

Top Secret!  Seriously, I'm not giving all that away, at least not yet.
I'll describe alot of what I've done.

The inner/address interpreter is coded in C with a few procedures for:
NEXT ENTER EXIT .  ENTER is sometimes called DOCOL and EXIT is sometimes
called SEMIS .  NEXT adjusts the working pointer W and instruction
pointer IP and calls the CFA.  ENTER saves the IP on the return stack,
and sets the new IP to W+1.  EXIT pops the old IP from the return stack.
DOCON DOVAR DODOES etc work the same way as historical Forth does too.
EXECUTE is slightly different.  Using NEXT in C to EXECUTE would cause
a stack leak in C.  So, a modified version without the leak is used.
It has two stacks, dictionary space, etc too.

The inner/address interpreter starts by calling COLD which calls QUERY
which calls 'interpreter', the text/outer interpreter, which calls
'compiler' when needed.  Originally, 'interpret' called 'interpreter'
and 'compiler'.  I'm not sure if I need to revert to that in the future.
The ordering of the logic was suggested by Andrew Haley (IIRC), and
is reverse of the way fig-Forth etc do things.  Those Forth words are
coded in C (not inline assembly), i.e., 'pre-compiled'.  If you looked
at the emitted assembly for the C code, the layout will be identical
to a Forth coded in assembly, except for placement of the dictionary
header, for the primitives, in some cases.

Currently, most of the Forth dictionary is coded in Forth which is
compiled at run-time by the text/outer intpreter.  So, their layout
is correct.  The Forth interpreter lays down bytes and addresses
(not offsets).  So, the C data layout issues affect only the low-level
primitives since they're "pre-compiled" in C, i.e., hand-coded, just
like a word in assembly.  But, C can't completely control the layout
of data in an object file.  Linker script commands are required to do
that, but I don't use any of them.  I was going for purely ANSI C.

Basically, C can *almost* generate any data layout you desire,
as long as you know where and when and how to override the type system.
This is due in large part because all C objects must map onto an array
of characters.  Although, you can't completely control ordering of
multiple C objects.  Nor can you control the alignment of those objects
and in-between padding.  But, you can control the ordering of objects
within single C objects, except for bit fields due to padding.

The method I'm currently using can't control the placement of the
dictionary header for primitives.  This means there is an additional
operation in certain words to access the body of the Forth word.
Another method, which I haven't attempted yet, should be able to
correctly place all data for primitives, body and header, except for
the name field.  The name field in that case would need a type system
override, i.e., cast in C, that isn't allowed by C.  If that method
works, it would only require an additional fetch for the name field,
or perhaps some lower-lower-level nameless primitives, as if defined
by :NONAME...  That would minimize the differences, probably about as
far a C could go, but it's possible that this option is less desirable
than the other.  I won't know until it's attempted.  So, yes, there
are some trivial differences in data layout from other Forths.

Hopefully, that was informative, but yet a bit too cryptic for now.

:-)


Rod Pemberton

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

#31494

AKK <akk@nospam.org> writes:
>Am 12.06.2014 13:33, schrieb Rod Pemberton:
>> I don't see why.  As I've stated many times to Hugh who doesn't bother
>> to remember this either, I've not used the classic method of implementing
>> Forth in C: switch().  My implementation uses ITC with an interpreter
>> in C.  It's virtually identical to implementing a Forth in assembly.
>> I.e., if I had implemented it in assembly, it wouldn't be different,
>> or not much.
>
>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
-- 
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.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#31523

Am 13.06.2014 19:29, schrieb Anton Ertl:
> AKK <akk@nospam.org> writes:
>> Am 12.06.2014 13:33, schrieb Rod Pemberton:
>>> I don't see why.  As I've stated many times to Hugh who doesn't bother
>>> to remember this either, I've not used the classic method of implementing
>>> Forth in C: switch().  My implementation uses ITC with an interpreter
>>> in C.  It's virtually identical to implementing a Forth in assembly.
>>> I.e., if I had implemented it in assembly, it wouldn't be different,
>>> or not much.
>>
>> 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.

Worse: using non-standard C constructs may bite you deeply later, when 
you have to change compilers or target systems.

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

#31527

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
-- 
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.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#31528

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.

Andrew.

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

#31531 — Optimizing C compilers vs. assembly language for Forth interpreters (was: Forth philosophy)

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>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.

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: for an interpreter like

for (;;) {
  switch (*ip++) {
    case add: ...; break;
    ...
  }
}

replicate the code from the break to the switch, so that each VM
instruction gets its own copy of the dispatch code (in particular its
own copy of the indirect branch).  Of course, if you also want to
optimize interpreters like that of Python that has a gazillion ifs on
that path, it's a little difficult to decide when to replicate and
when not.

The other difficulty is that such a replication does not fit into the
current framework of GCC or LLVM (or both): A student implemented that
as a project on one of these compilers, and found that he could not do
that during ordinary optimization, because it would break assumptions
that the other optimization passes make; instead, he has to put it at
the very end, which had its own problems.

But even with such an optimization, switch still has the table lookup
overhead over direct or indirect threaded code, and that cannot be
optimized away.

>I've never seen an optimizing compiler for a
>high-level language that can emit code which gets close to a
>hand-written interpreter.

I have seen GCC for GNU C (ok, maybe not a high-level language), which
emitted code which was faster than Win32Forth and LMI's NT Forth which
were written in assembly language.  See figure 6 of
<http://www.complang.tuwien.ac.at/papers/ertl&maierhofer95.ps.gz>

My explanation for the disappointing results for the systems written
in assembly language was that they used lods, which was slower on the
486 (on which the measurements were made) than just having a mov and
an add instruction.

>Also, there are some things that are
>difficult to express in most high-level languages but simple in
>assembly language, e.g. JSR threading.

Yes.  A student of mine wrote a Postscript interpreter in C#.  It was
very instructive to see all the things he could not do in that
language and how he worked around them.  E.g., in a low-level language
I would have used tagged cells (including tagged addresses).  You
cannot do that in C#, so he used objects.  Given that Postscript is a
high-level language and one tends to talk about Postscript objects,
one might think that this is would not impose too much overhead, but
that turned out to be wrong.  Implementing stacks was also interesting.

- 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.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

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

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>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.
> 
> 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.

> The other difficulty is that such a replication does not fit into the
> current framework of GCC or LLVM (or both): A student implemented that
> as a project on one of these compilers, and found that he could not do
> that during ordinary optimization, because it would break assumptions
> that the other optimization passes make; instead, he has to put it at
> the very end, which had its own problems.

Right.  That's a common problem with optimizing compilers: every pass
wants to be last.

> But even with such an optimization, switch still has the table lookup
> overhead over direct or indirect threaded code, and that cannot be
> optimized away.

Indeed.

>>I've never seen an optimizing compiler for a high-level language
>>that can emit code which gets close to a hand-written interpreter.
> 
> I have seen GCC for GNU C (ok, maybe not a high-level language), which
> emitted code which was faster than Win32Forth and LMI's NT Forth which
> were written in assembly language.  See figure 6 of
> <http://www.complang.tuwien.ac.at/papers/ertl&maierhofer95.ps.gz>

Well, I suppose I am assuming an equal level of skill and diligence.
It depends who wrote the assembly language.  Is this really comparing
like with like, though?  Indirect-threaded code, versus direct-
threaded, maybe?  I vaguely remember some x86 Forths had a horrible
NEXT.

> My explanation for the disappointing results for the systems written
> in assembly language was that they used lods, which was slower on the
> 486 (on which the measurements were made) than just having a mov and
> an add instruction.

x86 has always been a tricky target for anyone writing assembly
language: something fast in one generation becomes (relatively) slow
in the next.

Andrew.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web