Forthers: The Last of the Algorithm Developers
bio...@erols.com
that people who use Forth are wired differently than the general
software development crowd. Forthers are like refugees from a distant
time where people actually took pleasure from doing the job right. They
are in many ways like software craftsmen/craftswomen. Today all people
are worried about is patterns and re-use. There is little or no
emphasis on algorithm development/optimization or formal proofs. What
good is re-use if one is re-using crappy software? Where did all of the
great software minds go?
Mark
Walter Rottenkolber
bio...@erols.com wrote in message <3887356E...@erols.com>...
You have just made Chuck Moore's day!
He has often preached that you should not fear reinventing the wheel; to
modify code rather than work around a defect in library code. For this
reason Forth was designed to make prototyping easy, and checking out
different code variations to solve a problem can actually be fun. Of course,
this is easier to do if you have some control over your workday destiny.
Walter Rottenkolber
Marcel Hendrix
> After spending some time here on c.l.f., I have come to the conclusion
> that people who use Forth are wired differently than the general
> software development crowd. Forthers are like refugees from a distant
I read comp.lang.fortran for a few weeks and I find a comparable crowd
there, for a large number of the threads also circulating in clf.
> time where people actually took pleasure from doing the job right. They
> are in many ways like software craftsmen/craftswomen. Today all people
"Doing the job right" is impossibly vague. The circumstances and boundary
conditions of a job must be discussed.
Take for instance the recent thread-thread. The technically best solution to
the search/lookup problem is very well known, as it is a classical problem.
Using the perfect-hash algorithm, a targetcompiler can find kernel words
with exactly one simple operation (not even a string compare). I would say
this solves the problem, but many schemes were discussed (re-invented), all
clearly inferior, on average 10 to 1000 times worse (a hashtable per
wordlist!, linear searching in unbalanced divided-up wordlists! ... ).
You also can find threads where people worry about "best" and "better"
implementations of algorithms while showing that they are using badly
out-of-date/crummy/toy/proof-of-concept/training-wheels/idiosyncratic
Forths. Upgrading to one of the recent (commercial?) Forths would give them
factors of 10 or more improvement in size and speed, for negligeable cost
(if engineering time were calculated).
And then the much touted FSL: it is written in high-level Forth and thus
on very good systems between 2 and 10 times slower than linking to
external well-tested libraries (which any serious Forth is capable of).
I can think up good engineering reasons for *not* doing the theoretical best
thing possible. It involves weighing other factors [than I did above to make
my point] in the equation that leads up to "best". But, as I said, this is
almost never made explicit, and sometimes met with hostility if tried.
> are worried about is patterns and re-use. There is little or no
> emphasis on algorithm development/optimization or formal proofs. What
> good is re-use if one is re-using crappy software?
To a large degree your observation can be explained by the fact that the
Forth literature is largely unavailable to those that would benefit from it
most (i.e. newbies). Then, if you get the literature, you will find obscure
dialects that are sometimes so remote from current practice that the code is
unusable or unreadable. All this leads to the reinvent-it-yourself style.
> Where did all of the great software minds go?
Evidently (because you have to ask), they're either writing software you
have no need for and thus do not notice [yet], or they write it for systems
that you don't use [yet]. I do not believe great minds write software just
for the kick of writing software. They write it because they want to "play"
with some piece of hardware, or fight the dark forces, or sumthin'.
-marcel
John Passaniti
<bio...@erols.com> wrote in message news:3887356E...@erols.com...
> After spending some time here on c.l.f., I have
> come to the conclusion that people who use
> Forth are wired differently than the general
> software development crowd. Forthers are like
> took pleasure from doing the job right. They
> are in many ways like software craftsmen/craftswomen.
> and re-use. There is little or no emphasis on algorithm
> development/optimization or formal proofs. What
> good is re-use if one is re-using crappy software?
While I'm sure comp.lang.forth fans will enjoy the self-congratulatory
stroking you're providing, I think you need to get out more. I read plenty
of the literature and participate in discussion groups of the pattern
community, and I don't find their emphasis to be counter to what you have
said. The patterns community simply looks to catalog recurring themes, and
to offer them not as a "drop in" solution, but something to be considered.
Patterns are nothing more than an attempt to document common practice in a
methodical way. Patterns aren't a crutch or a substitute for good design--
and I know of nobody in the patterns community that suggests it is.
Forth people, in my experience, are often over-concerned with optimization.
My favorite example was a guy I worked with who spent a week hand-crafting
a very clever routine in Forth. In the end, it was a model of elegance and
ran insanely fast. Of course, it was meaningless-- the routine was called
less than 1% of the time in the program's execution, so his effort didn't
make much sense when you look at the overall system. I'm not suggesting
Forthers all are stuck doing "microoptimization" and unable to see the
forest for the trees, but often in comp.lang.forth I just shake my head
when people argue over efficiency without considering the overall system.
Watch for it-- it's fun. Periodically, someone will post some code. Then,
others will decend on it and identify more efficient ways of doing it. But
look closer-- most of the optimizations made assume that runtime speed is
the dimension that should be optimized. You often won't see people ask the
question, "I could make this smaller or faster-- which is more important to
you." Or more telling, you often won't see the question, "how often does
this routine run, and how important is it to the overall system's design."
As for formal proofs, I know of only one person in this newsgroup who has
even mentioned Forth and formal proofs in the same sentence. I certainly
don't see a lot of effort towards formal proofs. I see generic themes of
"make the software simple so it is easy to prove" all the time, but that's
a far cry from formal proofs.
Where did all the great software minds go? As Madge might say, "you're
soaking in it." There is far more going on in the world of software than
just in comp.lang.forth. I take particular delight in often studying other
programming langauges so that I can understand other ways to view problems
and their solutions. Do that for a while, and you'll see that there is so
much going on that is useful, interesting, and worthwhile that you'll not
have time to keep up with it all. Forth is an important and valuable
language and philsophy for the design of software, but it certainly isn't
the only one.
The greatest minds in software today are not the ones who are stuck in
their own paradigms, milking it for all it is worth. The greatest minds
today are those who can see past their own boundaries and assimilate the
best ideas from others.
Mark A. Flacy
John>
John> Forth people, in my experience, are often over-concerned with
John> optimization. My favorite example was a guy I worked with who spent
John> a week hand-crafting a very clever routine in Forth. In the end, it
John> was a model of elegance and ran insanely fast. Of course, it was
John> meaningless-- the routine was called less than 1% of the time in the
How are you measuring "less than 1% of the time?" If he *hadn't* made his
routine run "insanely fast", wouldn't the percentage of runtime that his
routine used be higher?
John> program's execution, so his effort didn't make much sense when you
John> look at the overall system. I'm not suggesting Forthers all are
John> stuck doing "microoptimization" and unable to see the forest for the
John> trees, but often in comp.lang.forth I just shake my head when people
John> argue over efficiency without considering the overall system.
John>
John> Watch for it-- it's fun. Periodically, someone will post some code.
John> Then, others will decend on it and identify more efficient ways of
John> doing it. But look closer-- most of the optimizations made assume
John> that runtime speed is the dimension that should be optimized. You
John> often won't see people ask the question, "I could make this smaller
John> or faster-- which is more important to you." Or more telling, you
John> often won't see the question, "how often does this routine run, and
John> how important is it to the overall system's design."
One would assume that the poster posted code important to him/her. You can
also argue that the group norm in c.l.f is to optimize posted code for
runtime versus size. If you want something different, you ask for it.
After all, if the answers aren't what the original poster wanted, the
original poster ought to clarify what he/she wanted.
Leo Wong
bio...@erols.com wrote:
> After spending some time here on c.l.f., I have come to the conclusion
> that people who use Forth are wired differently than the general
> software development crowd. Forthers are like refugees from a distant
> time where people actually took pleasure from doing the job right.
> They are in many ways like software craftsmen/craftswomen.
You must have passed over my code, which are all quick sketches. I
have a fear of finality.
> Today all people are worried about is patterns and re-use.
Don't know about his computer programmer progeny, but Christopher
Alexander himself is well worth reading. For a taste, see:
"A City is Not a Tree"
http://rudi.herts.ac.uk:80/ej/udq/59/b_evans.html
Here's a table from that page:
Issue Tree Lattice
Movement: segregation shared streets
Traffic: concentrate disperse
Land use: zoned mixed
Street pattern: enclaves connectivity
(Forth is Not a Tree; think of a programming methodology that is like
a tree.)
Alexander's huge new book The Nature of Order (Oxford UP, Fall 2000?)
goes beyond (or perhaps: goes within) patterns.
See:
http://www.math.utsa.edu/sphere/salingar/Chris.text.html
To make you feel better about non-Forthers, here's a quote from
James O. Coplien:
> The GoF pattern catalog is nice, but it is a "dead end" of sorts
> because it stops short at "patterns" and doesn't delve into the
> concept of pattern languages. The individual patterns are the primary
> emphasis, with some mention made of how they might
> relate to a few other patterns. Pattern languages go much further,
> dealing with rich interactions between patterns to indirectly
> generate solutions for more fundamental problems, much larger than
> any one pattern can address by itself.
http://www.enteract.com/~bradapp/docs/NoNoO.html
--
Leo Wong he...@albany.net
http://www.albany.net/~hello/
Sent via Deja.com http://www.deja.com/
Before you buy.
John Passaniti
Mark A. Flacy <fl...@nortelnetworks.com> wrote in message
news:yw0raelz...@ctexi2d6.us.nortel.com...
> How are you measuring "less than 1% of the time?" If he
> *hadn't* made his routine run "insanely fast", wouldn't the
> percentage of runtime that his routine used be higher?
The percentage was taken *before* his optimization, not after. As for how
I measured it, I'm a visual kind of guy, so I set a port pin on entry to
the routine, reset it on exit, and hooked it up to an oscilloscope. Plus,
it's cool to play with the knobs.
> One would assume that the poster posted code important to
> him/her. You can also argue that the group norm in c.l.f is
> to optimize posted code for runtime versus size. If you want
> something different, you ask for it.
>
> After all, if the answers aren't what the original poster wanted,
> the original poster ought to clarify what he/she wanted.
My point still stands. The "group norm" is to optimize for execution time
verses code size, verses data size, verses power, source code size, verses
any other dimension you can measure efficiency (such as time spent
programming). The "group norm" doesn't appear to be to ask what is a
fundamental engineering question-- what kind of efficiency is important.
As I mentioned in the past, I used to interview potential employees where I
worked. Part of that interview was to issue a short technical skills quiz.
One of the questions showed a simple algorithm that I purposefully make
inefficient along every dimension I could. I then asked the candidate to
suggest ways to optimize the algorithm. The "cowboy coders" dived right in
and usually assumed efficiency meant execution time or code size. The more
thoughtful people realized the question was ambiguous and started to ask me
questions, such as how much memory does the system have, what percentage of
the overall system depends on the algorithm, etc. One person surprised me
and said that the algorithm was already optimal-- given a set of
conditions-- and then proceeded to list those conditions.
What was especially interesting about this was that during the interview, I
would also ask them to characterize their work experience. Would they call
themselves a "programmer," a "software engineer/designer," or some other
term. Nearly universally, those who called themselves "programmers" were
the ones who later answered the optimization question along a specific
dimension. The ones who called themselves "software engineers" were the
ones who asked me questions back.
I should add that none of this was a qualifier for being hired when I did
interviews. There were many more factors than just this. I just always
found it interesting.
Jean-Francois Brouillet
<jp...@rochester.rr.com> wrote:
[a very well exposed rebutal to the idea that Forthers are unknown
geniuses that the whole world is not clever enough to be waiting for,
much less recognize as even fringe computer scientists]
Too bad that c.l.f has only _one_ John Passaniti as regular
contributor :-(
I certainly don't have enough depth to even dream of fulfilling the
role of a second, but I will nonetheless add a few points that have
driven me mad, here in c.l.f, in the past few years:
A language is only what you use it for. A language has features that
make it more easy to express some kind of ideas than other languages
which, in turn, are more adapted to other kind of thoughts.
Reducing the whole world to one language or one thought is certainly
not going to help mankind in any way. But that's what most Forthers
do. [You all know the story about the hammer and the nail]
Specifically, and as an example, there have been rants about not
using EVALUATE which is probably the most misguided piece of advice
ever given in c.l.f, and the reason is simple:
Together with EXECUTE, EVALUATE are the only TWO reasons why
I still stick to Forth, because that`s the very feature that
allows _runtime_ selection of behavior.
But Forthers, by and large, are _not_ interested in _runtime_
behaviors; hence this ill given advice. What they will overload
you with at length (and usually, ad nauseam), is how they can,
at compile time, make code more efficient at runtime. But this
not, and by far, the same thing as dynamic behavior, which is
the whole point of EXECUTE/EVALUATE.
Forthers are in a closed world, consisting of them, their
machine, and THE program they are working on at the time they
speak. Nothing can come from the outside, either as a dynamic
behavior (see above) or as a source of ideas for the precise
problem they are working on.
This has driven me so mad, that I usually now resist in
participating, because there's no point in telling things to
people who _don't want to hear_ (much less listen)
Yes, I do use Forth.
No, I'm _not_ a Forther
Yes, I love good algorithms when they make sense
No, nit-picking is not "ma tasse de thé"
Yes, Forth has a great, unrealized _potential_
No, Forthers are _not_ going to change the world, any time soon
Yes, I feel appaled by the image Forthers give of Forth
No, this won't prevent me from either using Forth, or any other
language/tool more adapted to the task at hand
Yes, crappy code does exist, even in Forth
No, patterns are not a collection of poorly designed libraries
Yes, patterns are _one_ approach to _design reuse_ as opposed to
code reuse.
--
Jean-Francois Brouillet <ve...@cybercable.fr>
David N. Williams
>
> [...]
>
> Don't know about his computer programmer progeny, but Christopher
> Alexander himself is well worth reading. For a taste, see:
>
> "A City is Not a Tree"
> http://rudi.herts.ac.uk:80/ej/udq/59/b_evans.html
>
>
> See:
>
> http://www.math.utsa.edu/sphere/salingar/Chris.text.html
>
> [...]
>
> http://www.enteract.com/~bradapp/docs/NoNoO.html
What a feast! Thanks, Leo.
--David
_ _________________________________________________________________
(_\(__
_|__) David N. Williams Phone: 1-(734)-764-5236
__|___ University of Michigan Fax: 1-(734)-763-2213
\ |:-) Physics Department Email: David.N....@umich.edu
\| Ann Arbor, MI 48109-1120 Office: 3421 Randall Laboratory
Marcel Hendrix
Jean-Francois Brouillet <ve...@cybercable.fr> wrote:
>In article <GLTh4.1429$VD4....@typhoon.nyroc.rr.com> , "John Passaniti"
><jp...@rochester.rr.com> wrote:
>
>[a very well exposed rebutal to the idea that Forthers are unknown
> geniuses that the whole world is not clever enough to be waiting for,
> much less recognize as even fringe computer scientists]
I would say John is fighting windmills.
>
>Yes, I do use Forth.
>No, I'm _not_ a Forther
>Yes, I love good algorithms when they make sense
>No, nit-picking is not "ma tasse de thé"
>Yes, Forth has a great, unrealized _potential_
>No, Forthers are _not_ going to change the world, any time soon
>Yes, I feel appaled by the image Forthers give of Forth
>No, this won't prevent me from either using Forth, or any other
>language/tool more adapted to the task at hand
>Yes, crappy code does exist, even in Forth
Well how about this: I agree with you. This tells me you have left out a few
important things :-)
>No, patterns are not a collection of poorly designed libraries
>Yes, patterns are _one_ approach to _design reuse_ as opposed to
>code reuse.
This is too vague for me.
Additional observation: There is (almost) no contributor to clf who doesn't
have a certain (mild) obsession, something they will defend against all
odds. This is something one really doesn't see anywhere else (in regular
fora). Well, progress (or extinction :-) *by definition* won't come from a
perfectly normal, 100% average, sensible population.
-marcel
bio...@erols.com
>
> While I'm sure comp.lang.forth fans will enjoy the self-congratulatory
> stroking you're providing, I think you need to get out more. I read plenty
> of the literature and participate in discussion groups of the pattern
> community, and I don't find their emphasis to be counter to what you have
> said. The patterns community simply looks to catalog recurring themes, and
> to offer them not as a "drop in" solution, but something to be considered.
> Patterns are nothing more than an attempt to document common practice in a
> methodical way. Patterns aren't a crutch or a substitute for good design--
> and I know of nobody in the patterns community that suggests it is.
>
First, left me start off by saying that I am not a professional Forth
developer; so, my view of the Forth community is from that of an
outsider. Secondly, as a senior software architect, who has been
designing and developing commercial, operating-system-level products in
C++ for number of years, I know what it is like living in the "patterns"
and "OOA/OOD" world! :-)
In the C++ community, there has been so much emphasis on training people
about how to re-use designs and code that we are starting to forget how
to invent. People are no longer interested in finding a better way to
solve a problem. Instead, we have people looking at the best pattern in
which to fit a problem. We have people hacking bad old code to fit new
problems. This orientation has led us to the point where we now have
code that runs as fast on Pentium III 500 as it did in an 80286, and has
tons of bugs.
Mark
Mark Humphries
[snip]
> In the C++ community, there has been so much emphasis on training
> people about how to re-use designs and code that we are starting to
> forget how to invent. People are no longer interested in finding a
> better way to solve a problem. Instead, we have people looking at
> the best pattern in which to fit a problem. We have people hacking
> bad old code to fit new problems. This orientation has led us to the
> point where we now have code that runs as fast on Pentium III 500 as
> it did in an 80286, and has tons of bugs.
Well said!
Cheers,
Mark W. Humphries
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
John Passaniti
<bio...@erols.com> wrote in message news:388A38D2...@erols.com...
> In the C++ community, there has been so much
> emphasis on training people about how to re-use
> designs and code that we are starting to forget how
> to invent. People are no longer interested in finding
> a better way to solve a problem. Instead, we have
> people looking at the best pattern in which to fit a
> problem. We have people hacking bad old code to
> fit new problems. This orientation has led us to the
> point where we now have code that runs as fast on
> Pentium III 500 as it did in an 80286, and has
> tons of bugs.
And somehow Forth or the Forth community cures all this? Are we to believe
that just because Chuck Moore espouses a build everything from scratch
mindset that this is actually common in the Forth community? Do you have
some objective means to demonstrate that the Forth community really is
still "inventing," and not just reinventing what others have already done?
I don't see much innovation myself in this community-- at least not now in
2000. You might have made a case for that in the 70's and 80's, but now?
I see a handful of *individuals* who are doing innovative things, but your
message paints the entire community with a very wide brush. Supposedly we
Forthers are the "last of the algorithm developers," ignoring completely
that the world is much larger than Forth, and there is plenty happening
outside.
There are indeed folks who mechanically put code together. And I find
absolutely nothing wrong with that. Not every program necessarily calls
for innovation. Sometimes, a mechanistic process to develop software is
exactly what is needed. And sometimes the use of such processes enables
ordinary people to do extraordinary things.
But there are also programmers who are taking the same frameworks that
others are using (such as STL) and doing really unique and innovative
things-- extending it far beyond what people expected of it. It's a
classic case that it isn't the tool (or language) that makes the
difference, but what people do with it.
Likewise, while there are people who use patterns as you describe, there is
also a vibrant community of pattern advocates who are doing wonderful and
innovative things. Visit the Portland Pattern Repository
(http://www.c2.com/cgi/wiki?WelcomeVisitors) to see a small example of a
community that treats patterns as a starting point, not as a end point.
Let me sum up my feelings with this:
There are people who lament the day that desktop publishing became
available. They argued that such tools would lead to a diminishing of the
art and science behind typography, graphic design, and printing. And in a
sense, they were right-- the sheer amount of crap that people now produce
using desktop publishing tools is depressing. But that's not to say that
prior to desktop publishing every piece of printed matter was a work of art
to be held up with reverence. And that's also not to say that desktop
publishing tools haven't allowed ordinary people who didn't have the
backgrounds and training to produce useful and worthwhile things. Also, in
the hands of a skilled person, desktop publishing tools become an amplifier
for expression.
The parallels to software development should be obvious.
Jean-Francois Brouillet
wrote:
> In article <86c7lp$jrl$1...@news4.isdnet.net>,
> Jean-Francois Brouillet <ve...@cybercable.fr> wrote:
>>In article <GLTh4.1429$VD4....@typhoon.nyroc.rr.com> , "John Passaniti"
>><jp...@rochester.rr.com> wrote:
>>
>>[a very well exposed rebutal to the idea that Forthers are unknown
>> geniuses that the whole world is not clever enough to be waiting for,
>> much less recognize as even fringe computer scientists]
>
> I would say John is fighting windmills.
If, by ``windmills'' you mean: ``the Forthers at large'' (and who
else is John fighting with?) I'm not too sure whether you just made
new friends out of your fellow forthers or not. But if this really
what you meant, then I have to agree with you ;-)
>
>>
>>Yes, I do use Forth.
>>No, I'm _not_ a Forther
>>Yes, I love good algorithms when they make sense
>>No, nit-picking is not "ma tasse de thé"
>>Yes, Forth has a great, unrealized _potential_
>>No, Forthers are _not_ going to change the world, any time soon
>>Yes, I feel appaled by the image Forthers give of Forth
>>No, this won't prevent me from either using Forth, or any other
>>language/tool more adapted to the task at hand
>>Yes, crappy code does exist, even in Forth
>
> Well how about this: I agree with you. This tells me you have left out a few
> important things :-)
>
Because we _have to_ disagree somewhere ?
You know, one of the most telling things about some contributors is
all in their sigs, all nonsense ranging from "elegance is for taylors",
"late answers are wrong answers" or "if you want it done right, do it
yourself"...
But I do take note that you _yourself_ don't have such a childish
epitaph. ( <-- and I think I just used the right word :-)
>>No, patterns are not a collection of poorly designed libraries
>>Yes, patterns are _one_ approach to _design reuse_ as opposed to
>>code reuse.
>
> This is too vague for me.
>
Pattern do capture the thought process when applied to a given
domain. Patterns can be ``instantiated'' in any language, and
the quality of the instantiation only depends on the skills of
the user, and don't tell _anything_ on the given pattern itself.
Moreover, patterns _can_ be misapplied (by anyone, including
newbies) for the simple reason that programming is hard, and
designing even harder.
That's precisely because it is so hard, that having some piece
of advice or guidance from people who have followed similar routes
is an invaluable tool, both for that one current problem you're
trying to solve, and for your personal ``bag of tricks'' that
you carry around from project to project.
Patterns are _only_ the documentation of a design that applies
to many kinds of otherwise dissimilar problem domains, by capturing
what is _common_ in the _solution_
Exemples abound (but if you've not read the GOF book, their name will
be of little significance to you), and the key to their use is that
they can be gathered in a kind of catalog/directory where you can look
them up, on demand. Finding the pattern(s) that apply to your current
problem does _not_ give you free code to copy and paste, but rather,
the conceptual framework in which _you_ can instantiate it(them) to
solve your issues.
Another sad thing, is that many (most?) people _have_ used patterns
for years, but without having a name either for the process of
reapplying an existing design to (part of a) new problem, and
without having a name to identify that particluar design they were
reusing. The whole thing was just called "experience".
That's too bad because, even if they are all "Monsieur Jourdain" (who
used prose for years without acknoledging consciously that this was
no poetry), they lack the common vocabulary that allow pattern
practitionners to _communicate_ with each other. Obviously, Forthers
are not very good at that, either ;-(
Here's a list of patterns I have used over the years, even if I've known
of their names only 5 years ago or so.
Composite, Singleton, Bridge, Adaptor, Listener.
There does exist a few dozen more, and a dozen or so appear every year.
> Additional observation: There is (almost) no contributor to clf who doesn't
> have a certain (mild) obsession, something they will defend against all
> odds. This is something one really doesn't see anywhere else (in regular
> fora).
It's true because I'm an obsessive kind of guy ;-)
But does it mean that all "C"-ers are also the same, since *I* _do_
participate (rarely, I must admit) in c.l.c ?
Or that the Wintrolls who polluate most *.mac.* hierarchies give
a relevant and accurate view of what a Mac or a Windows machine are?
Obsession is not reason ;-)
> Well, progress (or extinction :-) *by definition* won't come from a
> perfectly normal, 100% average, sensible population.
>
It sounds like one of Georges Bernard Shaw most quoted aphorism ...
> -marcel
>
--
Jean-Francois Brouillet <ve...@cybercable.fr>
Marcel Hendrix
> In article <86ce9b$rj3$1...@news.IAEhv.nl> , m...@iaehv.iae.nl (Marcel Hendrix) wrote:
>> In article <86c7lp$jrl$1...@news4.isdnet.net>,
>> Jean-Francois Brouillet <ve...@cybercable.fr> wrote:
>>>In article <GLTh4.1429$VD4....@typhoon.nyroc.rr.com> , "John Passaniti"
>>><jp...@rochester.rr.com> wrote:
>>>
>>>[a very well exposed rebutal to the idea that Forthers are unknown
>>> geniuses that the whole world is not clever enough to be waiting for,
>>> much less recognize as even fringe computer scientists]
>>
>> I would say John is fighting windmills.
> If, by ``windmills'' you mean: ``the Forthers at large'' (and who
> else is John fighting with?) I'm not too sure whether you just made
> new friends out of your fellow forthers or not. But if this really
> what you meant, then I have to agree with you ;-)
You know your Shaw better than your Cervantes :-)
[..]
>> Well how about this: I agree with you. This tells me you have left out a few
>> important things :-)
> Because we _have to_ disagree somewhere ?
Based on your previous postings, posting-style and information linked
from your postings: Yes.
[ remarks about tag lines ]
This is an extremely childish attack. I hope people'll give you the benefit
of the doubt. You get this reply only because of the following:
>>>No, patterns are not a collection of poorly designed libraries
>>>Yes, patterns are _one_ approach to _design reuse_ as opposed to
>>>code reuse.
>>
>> This is too vague for me.
> Pattern do capture the thought process when applied to a given
> domain. Patterns can be ``instantiated'' in any language, and
> the quality of the instantiation only depends on the skills of
> the user, and don't tell _anything_ on the given pattern itself.
[etc]
You got me interested. Hmmm, note that people don't need to have a degree in
mechanical engineering and computational fluid-dynamics to be able to ride a
bike ... But I'll look into it if I still have the pointers.
[..]
-marcel
Jerry Avins
>
...
>
> You know, one of the most telling things about some contributors is
> all in their sigs, all nonsense ranging from "elegance is for taylors",
> "late answers are wrong answers" or "if you want it done right, do it
> yourself"...
> But I do take note that you _yourself_ don't have such a childish
> epitaph. ( <-- and I think I just used the right word :-)
>
>
> --
> Jean-Francois Brouillet <ve...@cybercable.fr>
Epitaph: n 1. a commemorative inscription on a tomb or mortuary
monument. 2. a brief poem or other writing in praise of a deceased
person. from Gr epi- over + taph(os) tomb.
Right word? Probably not.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Andrew Haley
: If, by ``windmills'' you mean: ``the Forthers at large'' (and who
: else is John fighting with?)
That's easy; now, as ever, he is fighting strawmen of his own making.
Andrew.
Jonah Thomas
>"Jean-Francois Brouillet" <ve...@cybercable.fr> wrote Re: Forthers: The Last of the Algorithm Developers
>>> I would say John is fighting windmills.
>> If, by ``windmills'' you mean: ``the Forthers at large'' (and who
>> else is John fighting with?) I'm not too sure whether you just made
>> new friends out of your fellow forthers or not. But if this really
>> what you meant, then I have to agree with you ;-)
>You know your Shaw better than your Cervantes :-)
I think he's trying to say we aren't giants. 8-)
>[..]
>[ remarks about tag lines ]
>This is an extremely childish attack. I hope people'll give you the benefit
>of the doubt. You get this reply only because of the following:
The tone of the group has dropped remarkably recently. It used to be
when people got involved in this sort of thing it was always with John.
Jerry Avins
>
> Jean-Francois Brouillet (ve...@cybercable.fr) wrote:
>
> : If, by ``windmills'' you mean: ``the Forthers at large'' (and who
> : else is John fighting with?)
>
>
> Andrew.
You're probably right about that, but he makes a lot of sense in in the
process.
m_l...@my-deja.com
but also improving his English. You should say what this thing is
called.
Netscape calls it "signature".
Jerry Avins wrote:
>
> Jean-Francois Brouillet wrote:
> >
> ...
> >
> > You know, one of the most telling things about some contributors is
> > all in their sigs, all nonsense ranging from "elegance is for taylors",
> > "late answers are wrong answers" or "if you want it done right, do it
> > yourself"...
> > But I do take note that you _yourself_ don't have such a childish
> > epitaph. ( <-- and I think I just used the right word :-)
> >
> ...
> >
> > --
> > Jean-Francois Brouillet <ve...@cybercable.fr>
>
> Epitaph: n 1. a commemorative inscription on a tomb or mortuary
> monument. 2. a brief poem or other writing in praise of a deceased
> person. from Gr epi- over + taph(os) tomb.
>
> Right word? Probably not.
>
Jean-Francois Brouillet
wrote:
[...]
> You know your Shaw better than your Cervantes :-)
Probably. I also made a reference to Molière, but you didn't
notice. That's what being a froggie probably is. That said,
Don Quichotte _is_ remembered for the foolish idealist he was
whereas none of his ennemies will ever be. (remembered, for
anything worth remembering, that is.)
>> Because we _have to_ disagree somewhere ?
>
> Based on your previous postings, posting-style and information linked
> from your postings: Yes.
And also because it looks better than a "Me too" ?!? kind of reply :-/
>
> [ remarks about tag lines ]
>
> This is an extremely childish attack.
I'm not too certain where the childish-ness is. Obviously, this
can't be said of people who makes fools of themselves by showing
the whole world how their whole (mis)conception of life can be
reduced to five words ?!? [And yes, Jerry, that's what an epitaph is]
> I hope people'll give you the benefit
> of the doubt.
I'm not sure I'm interested.
> You get this reply only because of the following:
[...]
> You got me interested.
If might rants have half-open one's eye, even of a single individual
then, maybe, I somehow succeeded :-)
> Hmmm, note that people don't need to have a degree in
> mechanical engineering and computational fluid-dynamics to be able to ride a
> bike ...
Can't understand that and how it relates (or not) to patterns.
> But I'll look into it if I still have the pointers.
>
Not that they are so hard to find :-]
> [..]
Wil Baden
> After spending some time here on c.l.f., I have come to the
> conclusion that people who use Forth are wired differently
> than the general software development crowd. Forthers are
> like refugees from a distant time where people actually took
> pleasure from doing the job right. They are in many ways like
> software craftsmen/craftswomen. Today all people are worried
> about is patterns and re-use. There is little or no emphasis
> on algorithm development/optimization or formal proofs. What
> good is re-use if one is re-using crappy software? Where did
> all of the great software minds go?
Based on 1960s programming technology, Forth is an economical
language for use with constrained resources. Four to ten
times slower than native code, when that's not fast enough, it
can easily incorporate native code through its argument
conventions. Excellent for embedded systems, microprocessors,
controlling FPGAs, _etc_., it is used in Open Firmware as a
minimal portable facility to configure extensive custom
environments.
Because of its extreme simplicity, it is convenient for
studying elaboration of source code.
It is also useful as a foundation for text manipulation.
Forth works best with functions of at most two arguments. With
more than that, calculations may be complicated, inefficient,
and difficult to understand, especially without auxiliary
variables.
Originally Forth was multiuser and multitasking. Multiuser is
no longer appropriate. Multitasking is still important in
embedded systems, but non-commercial implementations for use
on personal computers usually do not include it.
Recent attempts to adopt Forthish architecture to hardware are
appalling: an extravagant number of registers, with limited
access to them; and a data format incompatible with the rest
of the world.
(
--
Wil Baden Costa Mesa, California WilB...@Netcom.com
)
Jean-Francois Brouillet
<m_l...@my-deja.com> wrote:
> Jerry, here in c.l.f Jean-Francois is not only talking to the world,
> but also improving his English. You should say what this thing is
> called.
> Netscape calls it "signature".
Thanks for pointing out the non-obvious to me ;-)
Mais je suis certain que si la prochaine fois je continue
à répondre en Français, exclusivement, cela aidera beaucoup
la divulgation des idées, ainsi que la chasse aux imbécilités
abysalles qui peuvent émailler, par temps souvent maussade,
les discours autrement abscons qui fleurissent ici
comme la petite vérole sur le bas clergé.
Il est certain que le communication se trouve renforcée
lorsque les locuteurs utilisent des langues différentes:
ainsi, je suis sûr d'avoir raison contre ceux qui ne
peuvent comprendre ce que j'écris.
C'est d'aileurs une grande victoire de la modernité qui me
permet d'étaler ici mon ignorance, sachant pertinemment
que "BabelFish" vous permettra d'en saisir toutes les subtilités.
À Mauvais Entendeur,
--
Jean-Francois Brouillet <ve...@cybercable.fr>
Jerry Avins
Netscape calls it a signature, but that doesn't strictly apply to the
way I and some others use it. That use is is well called a "motto". I
took the easy way out by ignoring that, but you goaded me to action:
Motto: n. pl. -toes, -tos. 1. A maxim adopted as an expression of one's
guiding principle. 2. a sentence, phrase, or word attached to or
inscribed on anything as appropriate to it.
That the appended text is indeed refereed to as a "sig" by most
(including me) is an indication that no established word covers all
uses. "Sig" it shall be, but it distresses me to think of it as short
for "signature" despite its derivation. Now, would you like another
treatise, or should we let it drop?
Jerry
P.S. to Jean-Francois: It hardly seems that your English needs
improvement.
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
"m_l...@my-deja.com" wrote:
>
> Jerry, here in c.l.f Jean-Francois is not only talking to the world,
> but also improving his English. You should say what this thing is
> called.
> Netscape calls it "signature".
>
Jonah Thomas
>... Excellent for embedded systems, microprocessors,
>controlling FPGAs, _etc_., it is used in Open Firmware as a
>minimal portable facility to configure extensive custom
>environments.
Would you mind saying that "portable minimal facility"?
I think it sounds better that way.
Jerry Avins
>
> bio...@erols.com wrote:
>
> > After spending some time here on c.l.f., I have come to the
> > conclusion that people who use Forth are wired differently
> > than the general software development crowd. Forthers are
> > like refugees from a distant time where people actually took
> > pleasure from doing the job right. They are in many ways like
> > software craftsmen/craftswomen. Today all people are worried
> > about is patterns and re-use. There is little or no emphasis
> > on algorithm development/optimization or formal proofs. What
> > good is re-use if one is re-using crappy software? Where did
> > all of the great software minds go?
>
> Based on 1960s programming technology, Forth is an economical
> language for use with constrained resources. Four to ten
> times slower than native code, when that's not fast enough, it
> can easily incorporate native code through its argument
> controlling FPGAs, _etc_., it is used in Open Firmware as a
> minimal portable facility to configure extensive custom
> environments.
>
> studying elaboration of source code.
>
> It is also useful as a foundation for text manipulation.
>
> Forth works best with functions of at most two arguments. With
> more than that, calculations may be complicated, inefficient,
> and difficult to understand, especially without auxiliary
> variables.
>
> Originally Forth was multiuser and multitasking. Multiuser is
> no longer appropriate. Multitasking is still important in
> embedded systems, but non-commercial implementations for use
> on personal computers usually do not include it.
>
> Recent attempts to adopt Forthish architecture to hardware are
> appalling: an extravagant number of registers, with limited
> access to them; and a data format incompatible with the rest
> of the world.
>
> (
> --
> Wil Baden Costa Mesa, California WilB...@Netcom.com
> )
In some embedded systems, it's hard to make a strict distinction between
multiuser and multitasking, just as it's sometimes hard to distinguish
embedded from stand-alone systems. With that quibble behind us, I like
the above for it's calm understatement.
Jerry Avins
Whatever I might have written to have caused this, I wish I hadn't!
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Jean-Francois Brouillet wrote:
>
> In article <388BD399...@my-deja.com> , "m_l...@my-deja.com"
> <m_l...@my-deja.com> wrote:
>
> > Jerry, here in c.l.f Jean-Francois is not only talking to the world,
> > but also improving his English. You should say what this thing is
> > called.
> > Netscape calls it "signature".
>
> Thanks for pointing out the non-obvious to me ;-)
>
> Mais je suis certain que si la prochaine fois je continue
> à répondre en Français, exclusivement, cela aidera beaucoup
> la divulgation des idées, ainsi que la chasse aux imbécilités
> abysalles qui peuvent émailler, par temps souvent maussade,
> les discours autrement abscons qui fleurissent ici
> comme la petite vérole sur le bas clergé.
>
> Il est certain que le communication se trouve renforcée
> lorsque les locuteurs utilisent des langues différentes:
> ainsi, je suis sûr d'avoir raison contre ceux qui ne
> peuvent comprendre ce que j'écris.
>
> C'est d'aileurs une grande victoire de la modernité qui me
> permet d'étaler ici mon ignorance, sachant pertinemment
> que "BabelFish" vous permettra d'en saisir toutes les subtilités.
>
> À Mauvais Entendeur,
>
> --
> Jean-Francois Brouillet <ve...@cybercable.fr>
>
> > Jerry Avins wrote:
> >>
> >> Jean-Francois Brouillet wrote:
> >> >
> >> ...
> >> >
> >> > You know, one of the most telling things about some contributors is
> >> > all in their sigs, all nonsense ranging from "elegance is for taylors",
> >> > "late answers are wrong answers" or "if you want it done right, do it
> >> > yourself"...
> >> > But I do take note that you _yourself_ don't have such a childish
> >> > epitaph. ( <-- and I think I just used the right word :-)
> >> >
> >> ...
> >> >
> >> > --
> >> > Jean-Francois Brouillet <ve...@cybercable.fr>
> >>
> >> Epitaph: n 1. a commemorative inscription on a tomb or mortuary
> >> monument. 2. a brief poem or other writing in praise of a deceased
> >> person. from Gr epi- over + taph(os) tomb.
> >>
> >> Right word? Probably not.
> >>
bio...@erols.com
>
> Based on 1960s programming technology, Forth is an economical
> language for use with constrained resources. Four to ten
> times slower than native code, when that's not fast enough, it
> can easily incorporate native code through its argument
> conventions. Excellent for embedded systems, microprocessors,
> controlling FPGAs, _etc_., it is used in Open Firmware as a
> minimal portable facility to configure extensive custom
> environments.
>
> Because of its extreme simplicity, it is convenient for
> studying elaboration of source code.
>
> It is also useful as a foundation for text manipulation.
>
> Forth works best with functions of at most two arguments. With
> more than that, calculations may be complicated, inefficient,
> and difficult to understand, especially without auxiliary
> variables.
>
> Originally Forth was multiuser and multitasking. Multiuser is
> no longer appropriate. Multitasking is still important in
> embedded systems, but non-commercial implementations for use
> on personal computers usually do not include it.
>
> Recent attempts to adopt Forthish architecture to hardware are
> appalling: an extravagant number of registers, with limited
> access to them; and a data format incompatible with the rest
> of the world.
So are you of the opinion that Forth has outlived its usefulness? Isn't
there place for a development environment based on Forth's simplicity
and extensibility?
I keep saying to myself "C was not the language of choice when I entered
the field. How come it continues to hang on and inspire derivatives
like C++ and Java? Why can't we pick another model?" There is so much
bad code today. I attribute much of this problem to the
institutionalized use of C and C++. Is Forth or a Forth-inspired
language a better alternative? Heck, I don't know, but from what I have
seen it offers far more power than does C or C++ while maintaining about
the same (or possibly less) danger factor?
The thing that intrigues me the most about Forth are the claims made
about its ability to deliver where C failed. I would really like to see
more case studies where Forth succeeded and other languages failed. At
this point in my career, I am more interested in getting the work done
correctly, on time, and on budget than playing with the computer; thus,
I am looking for anything that improves developer productivity while
lowering defect rates.
Mark
Jean-Francois Brouillet
wrote on 1/24/2000 19:49:
> My French is only just good enough for me to guess that you are sulking.
^^^^^^^
Yep! A new word in my (for ever) improving English WORDLIST ;-)
> Whatever I might have written to have caused this, I wish I hadn't!
No offense! I was just reminding people (rather caustically, I must
admit ;-( that we, foreigners, make the effort to write in _your_
language, and thus that it is a bit harsh to criticize us if ever
we were to slip by the official wording for such or such concept,
especially when we get it right:
French -> English (Harap's Shorter)
signature n.f signature
English -> French (ditto)
signature n. signature n. f.
but have chosen, on purpose, another word (epitaph) even more
sarcastically ;-)
Jean-Francois Brouillet
Your goals are very understandable, but the only general comment that
can be made at this point (without knowing your precise situation) is
that a _good_ Forth developer will, most of the time, outperform a _good_
C developer when it comes to code tightness. But if both of them are good
in their language of choice, there's no clear cut advantage to either,
except, as I already said, that ITC/DTC Forth code is the only high
level alternative to assembly when you have to fit your code in ridiculously
small amount of address space, which is most of the time when developing
embedded systems.
>
> Mark
Graham Telfer
> Would you mind saying that "portable minimal facility"?
> I think it sounds better that way.
I think we can improve on "portable minimal facility".
smallest handy tool
Graham Telfer
>
>
Julian V. Noble
> First, left me start off by saying that I am not a professional Forth
> developer; so, my view of the Forth community is from that of an
> outsider. Secondly, as a senior software architect, who has been
> designing and developing commercial, operating-system-level products in
> C++ for number of years, I know what it is like living in the "patterns"
> and "OOA/OOD" world! :-)
>
> about how to re-use designs and code that we are starting to forget how
> to invent. People are no longer interested in finding a better way to
> solve a problem. Instead, we have people looking at the best pattern in
> which to fit a problem. We have people hacking bad old code to fit new
> problems. This orientation has led us to the point where we now have
> code that runs as fast on Pentium III 500 as it did in an 80286, and has
almost!
> tons of bugs.
>
>
> Mark
--
Julian V. Noble
j...@virginia.edu
"Elegance is for tailors!" -- Ludwig Boltzmann
John Passaniti
<bio...@erols.com> wrote in message news:388CB808...@erols.com...
> I keep saying to myself "C was not the language
> of choice when I entered the field. How come it
> continues to hang on and inspire derivatives like
> C++ and Java? Why can't we pick another model?"
> There is so much bad code today. I attribute much
> of this problem to the institutionalized use of C and
> C++. Is Forth or a Forth-inspired language a better
> alternative? Heck, I don't know, but from what I
> have seen it offers far more power than does C or
> C++ while maintaining about the same (or possibly
> less) danger factor?
When I look at my neighbor's exceptionally ugly garden and hedges, I don't
attribute the fault to be in the tools he uses. I attribute the fault to
be his lack of skill using the tools. That, and apparently color
blindness. My partner has a much more limited set of gardening tools, but
he knows how to use them effectively. Our garden and hedges look great.
The Yamaha DX-7 is an ancient cheesy synthesizer. When I have a song in my
head that I want to play, I start poking at the buttons in a feeble attempt
to make music. I generally make more noise than music. Is the reason why
my neighbors keep their windows shut in summer because the DX-7 sucks, or
because I'm a far cry from Keith Emerson?
The company I work for had record profits last quarter. Management decided
it would be fun to take everyone out to a local ice skating rink to
celebrate. I went along, and was given a pair of ice skates. Since I have
absolutely no ability to stand on anything but dry flat land, I fell on my
ass a lot. Yet, the skates I used was from a coworker who claims they were
top-notch.
Why do people constantly blame the tool when it is more often the users of
the tool that are at fault? Unless you've dabbling in the exotic, when the
processor runs code, it isn't running Forth, C++, Java or any other
language. The processor has no idea that the add instruction it just
executed was the result of wonderfully factored Forth code, a massive C++
application framework, or yet another Java applet clogging up your
bandwidth. It's all just electrons shifting around, drawing current, and
heating up substrates.
I'm not saying that there isn't any difference between languages. Clearly,
from the programmer's perspective, Forth, C++, and Java present different
models. But I keep coming back to the fact that the processor doesn't care
about any of this. It only sees a stream of instructions.
Bad code is the result of bad programming. It may be simply a lack of
skill in understanding how to effectively use the language. It may be
using the wrong language for the application domain. It may be a design
methodology that is flawed.
But it isn't the language. To blame bad code on the language is
fundamentally wrong. It doesn't make sense. My neighbor is still a
terrible gardener even after buying the best tools. I'm still a bad
keyboard player even after I switched from cheap FM synthesis to sample
playback synthesis. And you can bet my ass would still be red and frozen
even if I had Brian Boitano pick out ice skates for me.
The companies I've worked for mostly use C for development. There are
people there who butcher the language, writing some of the most bloated,
inefficient, and unmaintainable code I've ever seen. Then there are people
who seem to have a deeper understanding of what's happening underneath the
language who write wonderful, compact, efficient code. Same language--
different results. It's obviously the programmer, not the language that
matters.
And why does it matter? I think it has something to do with how "close to
the metal" one is. When you program in Java, the virtual machine ensures
that as long as you stay in Java, you don't have to fear vectoring off on a
wild pointer, or trying to dereference a non-existent object. Because of
this, Java developers tend to view the underlying machine not in terms of
whatever physical characteristics it has, but the virtual characteristics
of the virtual machine. Consequently, Java developers-- at least the ones
I know-- don't seem to have a good sense of what instruction sequences are
best. The level of insulation prevents them from feeling it as viscerally
as programmers in other languages do.
C++ programmers are closer to the hardware than Java. But because C++ is
based on C, and because C wants to pretend the world is a PDP computer, you
find C++ programmers who don't know what contexts a "x++" is more efficient
than a "x+= 1". Plus, I when I look at the educational and professional
training available, I seldom see instruction in how to effectively use C++
for embedded systems. Because of that, it is something that just has to be
learned.
Forth programmers tend to be much closer to the hardware, so there is a
deeper appreciation of what effect various code sequences will have. Plus,
the language encourages (but doesn't enforce) factoring into smaller
pieces. This all helps the programmer write better code, and have an
understanding of how it will perform.
But again, it's the programmer, not the language. There are bad Forth
programmers for the same reason there are bad C++ and bad Java programmers.
> The thing that intrigues me the most about Forth
> are the claims made about its ability to deliver
> where C failed.
This assumes C failed. Again, I question if the language failed or the
programmers in that language failed. Those people who make such grandiose
claims about Forth are looking at the language in isolation. They aren't
considering that a programming language without a programmer is just bit
patterns spinning on a disk platter. It takes people to make Forth deliver
with C supposedly failed.
> I would really like to see more case studies where
> Forth succeeded and other languages failed.
You'll get plenty here in comp.lang.forth. All of the Forth vendors will
gladly provide you scenarios that following this pattern:
"Company V had ambiguously product W. They
used a team X engineers who wanted to program
it in language Y (the fools!). After Z months, the
engineers still weren't finished. Our company was
hired to take over. We wrote the application in
Forth, reduced application size by A%, increased
performance by B%, and got the project done in
only 1/C of the time projected. All because we
used Forth."
When you see such claims, ask the difficult questions. Then sit back and
enjoy the equivocation.
Maybe the X engineers failed because they didn't have effective management
to coordinate the project and to maintain communication. Maybe the product
W was inadequately defined or a moving target. Maybe the engineers were
new to the application domain, and the Forth programmers weren't. Maybe
language Y wasn't being effectively used. Maybe...
Maybe we'll never know, because the point of such claims is not to go into
a deep analysis of what went wrong, but rather to sell the products and
services of that company. Keep that in mind at all times.
> At this point in my career, I am more interested in
> getting the work done correctly, on time, and on
> budget than playing with the computer; thus, I am
> looking for anything that improves developer
> productivity while lowering defect rates.
I can't speak for others, but I know how I improved *my* productivity,
lowered defect rates, and delivered more projects on time and on budget.
It's called a library.
You walk in, and go to the computer science section. You see the name of a
programming language, methodology, or tool you don't recognize, and you
pick up the book. You read the book and fill your mind with as much as you
can possibly stand. In the process, you learn that there is no silver
bullet, that the world is filled with dozens of application domains you
didn't even know existed, and that people are incredibly creative at
solving problems.
You start to see that your favorite language-- maybe it's Forth-- is just
one of hundreds of computer languages that have been created. And you
start to learn why. You learn that object orientation doesn't necessarily
have anything to do with classes, but there are other models (delegation
and prototypes, for example). You learn about modeling methods like UML.
You learn why Smalltalk doesn't define control structures at the language
level. You learn what patterns are. Yada yada yada.
Then suddenly it happens. You look up and spinning around you is a
universe of ideas. You realize you can freely pick and choose from them.
Congratulations, you've arrived. You are finally free of the mental
shackles that your choice of language has placed on you.
You're no longer a Forth programmer or a C++ programmer or a Java
programmer or whatever. You're better than all that. You've escaped from
the depressing pit that happens as someone focused themselves on a singular
model or way of thinking. You might still *code* in Forth because it is a
flexible and enjoyable language. But you will be *thinking* with a much
larger scope.
Give it a whirl.
Stephen Pelc
>Based on 1960s programming technology, Forth is an economical
>language for use with constrained resources. Four to ten
>times slower than native code, when that's not fast enough, it
>can easily incorporate native code through its argument
>conventions.
moved on from 1960s programming technology! This is the sort
of opening sentence that instantly triggers "corporate immune
syndrome" during a sales pitch.
If you mean that there is still a place for ITC/DTC implementations,
then that is a different matter. There's an old marketeer's adage about
advertising your worst feature. In this case, offer code density by
threaded code.
--
Stephen Pelc, s...@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)2380 631441, fax: +44 (0)2380 339691
web: http://www.mpeltd.demon.co.uk - free ProForth downloads!
Andrew Haley
: Based on 1960s programming technology,
As opposed to, say, C, based on FORTRAN and ALGOL...
: Forth is an economical language for use with constrained resources.
: Four to ten times slower than native code
Eh?
: Forth works best with functions of at most two arguments. With more
: than that, calculations may be complicated, inefficient, and
: difficult to understand, especially without auxiliary variables.
Nonsense.
: Originally Forth was multiuser and multitasking. Multiuser is
: no longer appropriate.
Utter nonsense. What is a web server if not a multi-user system?
: Recent attempts to adopt Forthish architecture to hardware are
: appalling: an extravagant number of registers, with limited access
: to them; and a data format incompatible with the rest of the world.
Such as, for example?
Really Wil, is this you or is someone impersonating you?
Andrew.
Andrew Haley
: When I look at my neighbor's exceptionally ugly garden and hedges, I
: don't attribute the fault to be in the tools he uses. I attribute
: the fault to be his lack of skill using the tools. That, and
: apparently color blindness. My partner has a much more limited set
: of gardening tools, but he knows how to use them effectively. Our
: garden and hedges look great.
Part of the discussion here is based on what I feel to be a
misunderstanding. The word Forth, in this context, is not just used
to describe the programming language, which is just a tool, but also
to describe a way of thinking about computers and programming them.
Both of these, the language and the approach, came out of work done at
FORTH Inc. The language and OS was evolved over the years to suit the
way that its users worked. This combination of language and
techniques is discussed in this newsgroup.
: I'm not saying that there isn't any difference between languages.
: Clearly, from the programmer's perspective, Forth, C++, and Java
: present different models. But I keep coming back to the fact that
: the processor doesn't care about any of this. It only sees a stream
: of instructions.
The ANS Forth standard, and indeed all language standards, do not
cover the way that people use Forth. Nontheless, reducing Forth to
merely a tool is, in my view, a mistake. It's more than that.
That is perhaps the reason for much of the disagreement here.
: You'll get plenty here in comp.lang.forth. All of the Forth vendors will
: gladly provide you scenarios that following this pattern:
: "Company V had ambiguously product W. They
: used a team X engineers who wanted to program
: it in language Y (the fools!). After Z months, the
: engineers still weren't finished. Our company was
: hired to take over. We wrote the application in
: Forth, reduced application size by A%, increased
: performance by B%, and got the project done in
: only 1/C of the time projected.
I have seen such claims. I have even participated in such work. This
last sentence, however, is of your own devising:
: All because we used Forth."
: When you see such claims, ask the difficult questions. Then sit
: back and enjoy the equivocation.
No need to equivocate: it's a strawman.
Andrew.
bio...@erols.com
>
>
> When I look at my neighbor's exceptionally ugly garden and hedges, I don't
> attribute the fault to be in the tools he uses. I attribute the fault to
> be his lack of skill using the tools. That, and apparently color
> blindness. My partner has a much more limited set of gardening tools, but
> he knows how to use them effectively. Our garden and hedges look great.
>
> The Yamaha DX-7 is an ancient cheesy synthesizer. When I have a song in my
> head that I want to play, I start poking at the buttons in a feeble attempt
> to make music. I generally make more noise than music. Is the reason why
> my neighbors keep their windows shut in summer because the DX-7 sucks, or
> because I'm a far cry from Keith Emerson?
>
I am beginning to believe that you are the one missing the forest for
the the trees--tools do make a difference in project outcome. I am an
accomplished guitarist, and yes I can make a cheap guitar sound good.
However, with this said, there is absolutely no doubt in my mind that I
sound better on a high quality guitar. Plus, I am less likely to get
fatigued or walk away with bloody finger tips when playing a
high-quality instrument. Here, the quality of the tool not only ditates
the quality of the music, but the quality of the musician's life as
well. Additionally, I build quitars as a hobby, and I can tell you from
first-hand experience that cutting a body to shape with a bandsaw
instead of a coping saw results in a body that needs less shaping,
and a much more enjoyable woodworking experience; so, here, once
again, the tool makes a difference.
>
> Why do people constantly blame the tool when it is more often the users of
> the tool that are at fault? Unless you've dabbling in the exotic, when the
> processor runs code, it isn't running Forth, C++, Java or any other
> language. The processor has no idea that the add instruction it just
> executed was the result of wonderfully factored Forth code, a massive C++
> application framework, or yet another Java applet clogging up your
> bandwidth. It's all just electrons shifting around, drawing current, and
> heating up substrates.
>
The tool used has very much to do with the level of skill and effort
needed to use it properly. Yes, good code can be developed in C and
C++. I develop excellent code in any language I use, but a) I hold a
BSCS, magna cum laude, in CS from the University of Maryland (a top CS
institution--see http://www.glue.umd.edu/~pwalczak/csranks.html; thus,
my fundamentals are strong), b) I have completed graduate work in
software engineering (i.e., I understand the dynamics involved in
developing software in a production environment for profit), and c) most
importantly of all I have a natural talent for developing software (I
guess it is that musician/software developer structured, abstract, and
creative thing.)
With this said, I currently use C++Builder, Delphi, TASM, and VC++ to
develop software. Without a shadow of a doubt, I can tell you that I
produce a better product in Delphi with less effort than I do in
C++Builder, TASM, or VC++ even though I spend much more time working in
C++ (and, yes, I use C++, not C, i.e., I have zero free-standing,
utility functions in my designs, and a large portion of my code is built
using templates that I, not Rogue Wave, designed). There are many
dynamics at work here, but the language most definitely makes a
difference in software quality and productivity.
Object Pascal has a much different design philosophy than does C++. In
Object Pascal, everything needs to be defined before it is used (just
like in Forth.) Definitions occur in a certain order, and one is not
allowed to intermix code with definitions within a function.
Intermixing code with definitions within a function is probably one of
C's and C++'s worse features. It leads developers to build large,
poorly-factored code. Whenever I see a piece code in the format:
declaration list, statement list, declaration list, statement list, the
first thing that pops into my head is that we have multiple functions
masquerading as one. Another bad habit that goes along with this style
of coding, is multiple exit points (we all know that a properly-designed
function should have one exit point.) This style of coding leads to
buggy code that is next to impossible to verify for correctness.
>
> The companies I've worked for mostly use C for development. There are
> people there who butcher the language, writing some of the most bloated,
> inefficient, and unmaintainable code I've ever seen. Then there are people
> who seem to have a deeper understanding of what's happening underneath the
> language who write wonderful, compact, efficient code. Same language--
> different results. It's obviously the programmer, not the language that
> matters.
>
A language should not be designed such that it requires "Alpha" labor in
order to complete a job correctly. The institutionalized use of C and
C++ has lead in part to the bidding for people competent enough to build
software using these languages wars. Yes, I have personally benefited
from these wars--I now make as much as, if not more than, many
executives as an employee, not a freelancer. However, with this said, I
still see the institutionalized use of C and C++ as bad thing that is
holding software engineering back, not advancing it.
Mark
Dave Bennett
The thing holding software engineering back is people like yourself. The
words "engineer" and "science" (BSCS) mean something. There are rules in
engineering that if followed lead to a known conclusion. There is such a
thing as the "scientific method", which if followed will lead one to a
conclusion. I have managed software developers for 20 years and still
have yet to find even one that doesn't code with the "let's see if this
works, oops, let me change this line" method until they are taught
differently. (I generally avoid hiring BSCS kinds of people; the BS is
too deeply embedded in their thought process.)
There are soooo few shops where engineering and scientific principles
are applied in software development, and so few people that program that
understand these concepts, that many people who call themselves
developers who feel that it is a "creative thing".
Having written hundreds of programs in tens of languages, I can tell you
that the bottom line is twofold: 1) technically if you do A in source
code, B will result and 2) if the result isn't what the customer or
specification calls for, it is useless.
I've played guitar for 32 years, have a degree in photography and
studied with Ansel Adams and Brett Weston, and I have written more
production code than I care to remember; and I still don't feel that
"artsy" stuff has a thing to do with successful code production.
---
Dave Bennett
Anton Ertl
Jean-Francois Brouillet <jean-franco...@virgin.net> writes:
>Your goals are very understandable, but the only general comment that
>can be made at this point (without knowing your precise situation) is
>that a _good_ Forth developer will, most of the time, outperform a _good_
>C developer when it comes to code tightness. But if both of them are good
>in their language of choice, there's no clear cut advantage to either,
>except, as I already said, that ITC/DTC Forth code is the only high
>level alternative to assembly when you have to fit your code in ridiculously
>small amount of address space, which is most of the time when developing
>embedded systems.
Well, my data indicates that the code size advantage of Forth over
other languages is not due to threaded code (threaded code is not
tighter than native code, see
http://www.complang.tuwien.ac.at/forth/performance.html#size), and
that it is at least partly due to language-induced design decisions
(see http://www.complang.tuwien.ac.at/papers/ertl99.ps.gz).
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Elizabeth D Rather
news:86n4fl$g7b$2...@news.tuwien.ac.at...
> In article <B4B28FFD.14247%jean-franco...@virgin.net>,
> Jean-Francois Brouillet <jean-franco...@virgin.net> writes:
> >Your goals are very understandable, but the only general comment that
> >can be made at this point (without knowing your precise situation) is
> >that a _good_ Forth developer will, most of the time, outperform a _good_
> >C developer when it comes to code tightness. But if both of them are good
> >in their language of choice, there's no clear cut advantage to either,
> >except, as I already said, that ITC/DTC Forth code is the only high
> >level alternative to assembly when you have to fit your code in
ridiculously
> >small amount of address space, which is most of the time when developing
> >embedded systems.
>
> Well, my data indicates that the code size advantage of Forth over
> other languages is not due to threaded code (threaded code is not
> tighter than native code, see
> http://www.complang.tuwien.ac.at/forth/performance.html#size), and
> that it is at least partly due to language-induced design decisions
> (see http://www.complang.tuwien.ac.at/papers/ertl99.ps.gz).
I agree. IMO the biggest effect is from the extreme modularity of Forth and
the fact that it is optimized for modularity, meaning there's minimal
overhead for calls. This leads to an extreme degree of code reuse. When I
talk to C/C++ programmers, for example, and ask what "modularity" means to
them, they typically say it means subroutines rarely longer than 3-4 pages;
in Forth, it's more like 3-4 _lines_. Code reuse at that level can produce
extremely compact programs.
Having now a good deal of experience with direct code compilation, it's our
experience that for smaller CPU's it's close to break even on size, and on
32-bit CPUs DTC is smaller.
Cheers,
Elizabeth
Jean-Francois Brouillet
<an...@mips.complang.tuwien.ac.at> wrote on 1/26/2000 15:39:
> In article <B4B28FFD.14247%jean-franco...@virgin.net>,
> Jean-Francois Brouillet <jean-franco...@virgin.net> writes:
>> Your goals are very understandable, but the only general comment that
>> can be made at this point (without knowing your precise situation) is
>> that a _good_ Forth developer will, most of the time, outperform a _good_
>> C developer when it comes to code tightness. But if both of them are good
>> in their language of choice, there's no clear cut advantage to either,
>> except, as I already said, that ITC/DTC Forth code is the only high
>> level alternative to assembly when you have to fit your code in ridiculously
>> small amount of address space, which is most of the time when developing
>> embedded systems.
>
> Well, my data indicates that the code size advantage of Forth over
> other languages is not due to threaded code (threaded code is not
> tighter than native code, see
> http://www.complang.tuwien.ac.at/forth/performance.html#size), and
> that it is at least partly due to language-induced design decisions
> (see http://www.complang.tuwien.ac.at/papers/ertl99.ps.gz).
>
My experience contradicts your paper ;-)
On the Hitach H8/3xx series, the only generic way to call
a subroutine is through 'JSR <@abs:16>'. The other two modes
( BSR <8-bit> and JSR @page-0<8-bit> ) not being usable in the
general case (but useful for adhoc asm hacking)
The JSR @abs:16 takes 4 bytes of object code.
An ITC/DTC Forth definition only takes 2 bytes. In this ITC/DTC
model, the only Forth constructs taking more than 2 bytes are
the LITERALs and some branch targets.
I *do* have experienced a 20% size decrease of my code size
when moving from raw assembly to ITC.
Obviously, your mileage may vary ;-]
> threaded code is not tighter than native code,
Not to hammer on the obvious, but Token Threaded Code is
even more tighter than ITC/DTC, and can beat most (any?)
native code gen when code size is _the_ limiting factor.
Jeff Fox
> >except, as I already said, that ITC/DTC Forth code is the only high
> >level alternative to assembly when you have to fit your code in ridiculously
> >small amount of address space, which is most of the time when developing
> >embedded systems.
I have worked with two different styles of native code
optimizing compilers. They produce very different sized object
code by either inlining many sequences or by compiling small
tokens that map closely to the hardware. One might also want to
consider bit threaded and token threaded Forth if one is
interested in compact code.
Some people use ITC or DTC because of the increased
productivity that come from working system with simple
internals that are easily bent to do what they want. Those
are however not the only alternative for compact code
on small embedded systems or even ridiculously small ones.
I am used to native code that has something in common with
token threaded code, most instructions compile to small opcodes
that look very much like tokens. In that environment Forth native
code can be considerably more compact than traditionally
threaded code, let alone compared to code factored for other
languages.
> Well, my data indicates that the code size advantage of Forth over
> other languages is not due to threaded code (threaded code is not
> tighter than native code, see
> http://www.complang.tuwien.ac.at/forth/performance.html#size), and
I like to point out that Chuck is way out of sync on this. He
thinks good Forth is compact. He said that, "If it isn't 100
times smaller than 'C' it isn't (good) Forth." He actually
said "isn't Forth" but it was an uncharacteristicly intolerant
comment for him to make about how other people do Forth. It
was in the context of a talk about what makes for good Forth.
This compactness doesn't come primarily from DTC vs native
code but from designing and factoring code in Forth style
vs the style used in other languages. This compactness is a
sign of highly factored code that will be easier to debug and
maintain.
As Elizabeth Rather pointed out factoring in some languages
means keeping routines to a few pages of source. Factoring
in Forth is often more like keeping routine source to a
few lines. Factoring for Chuck is keeping it to a few
characters. In analyzing some of this examples I measured
the average length of a colon definition as 44 characters,
and the average compiled defintion was about ten words long.
The code was also characterized by doing more interpretation
at compile time than compilation at compile time. The small,
simple, highly factored code makes it easy to experiment with
algorithm improvement. These are some things that lead to
extremely compact code and efficient runtime code.
Jeff Fox
Elizabeth D Rather
news:86o3sk$gn0$1...@news.IAEhv.nl...
> In article <388F7579...@UltraTechnology.com>,
> Jeff Fox <F...@UltraTechnology.com> wrote:
> [..]
> >I like to point out that Chuck is way out of sync on this. He
> >thinks good Forth is compact. He said that, "If it isn't 100
> >times smaller than 'C' it isn't (good) Forth." He actually
> >said "isn't Forth" but it was an uncharacteristicly intolerant
> >comment for him to make about how other people do Forth. It
> >was in the context of a talk about what makes for good Forth.
> >
> >This compactness doesn't come primarily from DTC vs native
> >code but from designing and factoring code in Forth style
> >vs the style used in other languages. This compactness is a
> >sign of highly factored code that will be easier to debug and
> >maintain.
>
quoted
> so we can see how the real experts do it, and put it in the FAQ to show
the
> C-guys next time they question it.
Sounds to me like Chuck was exaggerating a bit for rhetorical effect.
We had an excellent real-world comparison a few years ago, when we and Paul
Curtis were both writing OTA virtual machines, conforming to a very detailed
spec. We were writing in Forth, of course, and Paul in C. What makes this
interesting is that Paul is an outstanding C programmer, one of the best I
know. Our VMs were 32K on 8-bit CPUs, and about 45K on a 68K. Paul's were
64K on average. Performance was equivalent on equivalent platforms. IMO
this type of real-world challenge is far more meaningful than "benchmarks".
Cheers,
Elizabeth
Marcel Hendrix
Jeff Fox <F...@UltraTechnology.com> wrote:
[..]
>I am used to native code that has something in common with
>token threaded code, most instructions compile to small opcodes
>that look very much like tokens. In that environment Forth native
>code can be considerably more compact than traditionally
>threaded code, let alone compared to code factored for other
>languages.
>
>> Well, my data indicates that the code size advantage of Forth over
>> other languages is not due to threaded code (threaded code is not
>> tighter than native code, see
>> http://www.complang.tuwien.ac.at/forth/performance.html#size), and
>
>thinks good Forth is compact. He said that, "If it isn't 100
>times smaller than 'C' it isn't (good) Forth." He actually
>said "isn't Forth" but it was an uncharacteristicly intolerant
>comment for him to make about how other people do Forth. It
>was in the context of a talk about what makes for good Forth.
>
>This compactness doesn't come primarily from DTC vs native
>code but from designing and factoring code in Forth style
>vs the style used in other languages. This compactness is a
>sign of highly factored code that will be easier to debug and
>maintain.
Please post the code equivalent to Anton's benchmarks on the page he quoted
so we can see how the real experts do it, and put it in the FAQ to show the
C-guys next time they question it.
-marcel
Stephen Pelc
>Well, my data indicates that the code size advantage of Forth over
>other languages is not due to threaded code (threaded code is not
>tighter than native code, see
>http://www.complang.tuwien.ac.at/forth/performance.html#size), and
>(see http://www.complang.tuwien.ac.at/papers/ertl99.ps.gz).
systems and optmising native compilers is heavily dependent on
the quality of the optimisation. Naive optimisers, however, are likely
to lead to a substantial increase in code size. After that, code size
then depends very heavily on coding style. Even on CPUs that are
not very compiler friendly, the size of good native code systems is
very comparable to the size of threaded systems.
The OTA experience has been mentioned by Elizabeth and myself
several times on this newsgroup, and it suggests that a substantial
application for an 8051 will be twice as large in C as in Forth. And
yes, the C programmer was good.
Jeff Fox
>
> In article <388F7579...@UltraTechnology.com>,
> Jeff Fox <F...@UltraTechnology.com> wrote:
> >Anton Ertl wrote:
> [..]
> >I am used to native code that has something in common with
> >token threaded code, most instructions compile to small opcodes
> >that look very much like tokens. In that environment Forth native
> >code can be considerably more compact than traditionally
> >threaded code, let alone compared to code factored for other
> >languages.
> >
> >> other languages is not due to threaded code (threaded code is not
> >> tighter than native code, see
> >> http://www.complang.tuwien.ac.at/forth/performance.html#size), and
> >
> >thinks good Forth is compact. He said that, "If it isn't 100
> >times smaller than 'C' it isn't (good) Forth." He actually
> >said "isn't Forth" but it was an uncharacteristicly intolerant
> >comment for him to make about how other people do Forth. It
> >was in the context of a talk about what makes for good Forth.
> >
> >This compactness doesn't come primarily from DTC vs native
> >code but from designing and factoring code in Forth style
> >vs the style used in other languages. This compactness is a
> >sign of highly factored code that will be easier to debug and
> >maintain.
>
> Please post the code equivalent to Anton's benchmarks
> on the page he quoted
> so we can see how the real experts do it, and put it
> in the FAQ to show the
> C-guys next time they question it.
I assume this is a joke and not an actual request for
programming services. Few people are willing to pay for
professional services just to give away what they pay
for.
The benchmarks you refer are all run on a 486 so to fit
in what you are asking for is a custom compiler just
to compile a few benchmarks. Well if that is really what
you want let me know.
I was refering to real world applications where one can
apply factoring as appropriate. One problem with said
benchmarks is stated right in the paper, "They have an
unusually low amount of calls." They don't represent
Forth very well, but then again the paper is about
programs translated from 'C' to Forth and back.
Another problem with said benchmarks is the their
notorious reputation for producing very missleading
results as a result of compiler optimizations. If
one has studied benchmarks one is likely to feel that
developing optimizations for benchmarks is a hollow
activity since they tend not to apply to real code.
Jeff Fox
Jeff Fox
>
> > In article <388F7579...@UltraTechnology.com>,
> > Jeff Fox <F...@UltraTechnology.com> wrote:
> > >I like to point out that Chuck is way out of sync on this. He
> > >thinks good Forth is compact. He said that, "If it isn't 100
> > >times smaller than 'C' it isn't (good) Forth."
> Sounds to me like Chuck was exaggerating a bit for rhetorical effect.
That could be. I know if I had heard Chuck make that statement
ten years ago I would have assumed that he was just being arrogant
and naive, or exaggerating for effect. But often over the years
when I did assume that I learned later that I was the one who was
being arrogant and naive.
Were it not for all the times where I saw examples over the years
where the numbers were of that order and all the times when I
mistakenly thought that Chuck was exaggerating for effect I might
have thought the same thing. It fits in with the way that
Chuck feels that his approach to Forth produces about 1/10 as
much code as other people's approach to Forth.
>IMO this type of real-world challenge is far more meaningful
>than "benchmarks".
I agree. The problem with many benchmarks is that they are
more easily optimized than real problems. Some of the
optimizations that work wonders on them do little on well
planned code. One has to look very closely at the fine
print in benchmarks or read between the lines and try not
to generalize too much from them.
Jeff Fox
Marcel Hendrix
Jeff Fox <F...@UltraTechnology.com> wrote:
>Marcel Hendrix wrote:
>>
>> In article <388F7579...@UltraTechnology.com>,
>> Jeff Fox <F...@UltraTechnology.com> wrote:
[..]
>> on the page he quoted
>> so we can see how the real experts do it, and put it
>> in the FAQ to show the
>> C-guys next time they question it.
>
>I assume this is a joke and not an actual request for
>programming services. Few people are willing to pay for
>professional services just to give away what they pay
>for.
>
>The benchmarks you refer are all run on a 486 so to fit
>in what you are asking for is a custom compiler just
>to compile a few benchmarks. Well if that is really what
>you want let me know.
>
So you meant that there is no change at the source code level, and still a
factor of 100 smaller compiled code size than for the published results up to
now? I am happy with seeing just the source code.
>I was refering to real world applications where one can
>apply factoring as appropriate. One problem with said
>benchmarks is stated right in the paper, "They have an
>unusually low amount of calls." They don't represent
>Forth very well, but then again the paper is about
>programs translated from 'C' to Forth and back.
>
>Another problem with said benchmarks is the their
>notorious reputation for producing very missleading
>results as a result of compiler optimizations. If
>one has studied benchmarks one is likely to feel that
>developing optimizations for benchmarks is a hollow
>activity since they tend not to apply to real code.
Ah yes, I see.
-marcel
Tony Williams
Jeff Fox <F...@UltraTechnology.com> wrote:
> Elizabeth D Rather wrote:
> >
> > > In article <388F7579...@UltraTechnology.com>,
> > > Jeff Fox <F...@UltraTechnology.com> wrote:
> > > [..]
> > > >I like to point out that Chuck is way out of sync on this. He
> > > >thinks good Forth is compact. He said that, "If it isn't 100
> > > >times smaller than 'C' it isn't (good) Forth."
> > Sounds to me like Chuck was exaggerating a bit for rhetorical effect.
> That could be. I know if I had heard Chuck make that statement
> ten years ago I would have assumed that he was just being arrogant
> and naive, or exaggerating for effect. But often over the years
> when I did assume that I learned later that I was the one who was
> being arrogant and naive.
An actual example (not of 100x though).......
I design/make/prog avionics ATEs for a living. They
are Forth machines (in concept) running with a 23K
proprietry Forth as the underlying core.
Each of our runtime progs (for major test specs that might
have taken up to 8 man-hours with manual test equipment)
have well spread out source code that fits into less
than 360K (a single floppy) and with actual runtimes
of around 12 to 15 minutes.... really limited by the
practical speed at which a UUT can be thrashed.
I know for a fact that a competitor (using, afaik, a
"more respectable" compiled TestBasic) requires 5+ megs
of HD space for each of the same test progs, and with
average runtimes exceeding 40 mins.....ie, about 15x
larger and 3x slower.
I could reduce the size (say by another 2x maybe) but
extreme factoring can reduce the readability of progs
and cause difficulties for (say) the SQA people.
--
Tony Williams.
Leo Wong
Dave Bennett <dben...@micoks.net> wrote:
> The
> words "engineer" and "science" (BSCS) mean something. There are rules
in
> engineering that if followed lead to a known conclusion. There is
such a
> thing as the "scientific method", which if followed will lead one to a
> conclusion. I have managed software developers for 20 years and still
> have yet to find even one that doesn't code with the "let's see if
this
> works, oops, let me change this line" method until they are taught
> differently. (I generally avoid hiring BSCS kinds of people; the BS is
> too deeply embedded in their thought process.)
>
> There are soooo few shops where engineering and scientific principles
> are applied in software development, and so few people that program
that
> understand these concepts, that many people who call themselves
> developers who feel that it is a "creative thing".
>
This may corroborate some of what you are saying:
"Building software - some call it _software engineering_ - is only
30 or 40 years old, and it shares with other engineering disciplines
virtually nothing." - Richard P. Gabriel, _Patterns_of_Software_
--
Leo Wong he...@albany.net
http://www.albany.net/~hello/
Sent via Deja.com http://www.deja.com/
Before you buy.
Axel Harvey
> I design/make/prog avionics ATEs for a living.
> [ ... ]
> Each of our runtime progs (for major test specs that might
> have taken up to 8 man-hours with manual test equipment)
> have well spread out source code that fits into less
> than 360K [ ... ]
> I know for a fact that a competitor (using, afaik, a
> "more respectable" compiled TestBasic) requires 5+ megs
> of HD space for each of the same test progs, and with
> average runtimes exceeding 40 mins [ ... ]
You must not have a marketing department, or they might be telling you
to spread your source code out even more ("Can't you even make it one
megabyte?") :)~
Tony Williams
Axel Harvey <a...@cam.org> wrote:
> On Fri, 28 Jan 2000, Tony Williams wrote:
> > Each of our runtime progs (for major test specs that might
> > have taken up to 8 man-hours with manual test equipment)
> > have well spread out source code that fits into less
> > than 360K [ ... ]
> You must not have a marketing department, or they might be telling you
> to spread your source code out even more ("Can't you even make it one
> megabyte?") :)~
Not a chance chum; Forth can be so embarrassing sometimes,
especially when it comes to invoicing.......
--
Tony Williams.
Anton Ertl
Jean-Francois Brouillet <jean-franco...@virgin.net> writes:
>> Well, my data indicates that the code size advantage of Forth over
>> other languages is not due to threaded code (threaded code is not
>> tighter than native code, see
>> http://www.complang.tuwien.ac.at/forth/performance.html#size), and
>> (see http://www.complang.tuwien.ac.at/papers/ertl99.ps.gz).
>>
>
>
>On the Hitach H8/3xx series, the only generic way to call
>a subroutine is through 'JSR <@abs:16>'. The other two modes
>( BSR <8-bit> and JSR @page-0<8-bit> ) not being usable in the
>general case (but useful for adhoc asm hacking)
>
>The JSR @abs:16 takes 4 bytes of object code.
>An ITC/DTC Forth definition only takes 2 bytes. In this ITC/DTC
>model, the only Forth constructs taking more than 2 bytes are
>the LITERALs and some branch targets.
On the 386 architecture whose code sizes are reported in
http://www.complang.tuwien.ac.at/forth/performance.html#size, the size
of a call is 5 bytes and the size of a threaded-code word is four
bytes. However, not everything in native code is a call; by contrast,
take a look at "8 + @". This is one instruction (3 bytes) in native
code on the 386, whereas it takes 16 bytes in threaded code. Overall
the native code is slightly smaller than the threaded code in my
measurements.
>I *do* have experienced a 20% size decrease of my code size
>when moving from raw assembly to ITC.
>
>Obviously, your mileage may vary ;-]
Yes, as our results indicate. However, both your and my results
support my conclusion that the big size differences reported (e.g.,
100x by Jeff Fox) are not due to the difference between native and
threaded code.
Anton Ertl
Jeff Fox <F...@UltraTechnology.com> writes:
>Anton Ertl wrote:
>> Well, my data indicates that the code size advantage of Forth over
>> other languages is not due to threaded code (threaded code is not
>> tighter than native code, see
>> http://www.complang.tuwien.ac.at/forth/performance.html#size), and
>
>thinks good Forth is compact.
Yes, but how does this relate to the native vs. threaded code size
issue discussed above? He now uses native code, so he appears to
agree with me on this.
> He said that, "If it isn't 100
>times smaller than 'C' it isn't (good) Forth." He actually
>said "isn't Forth" but it was an uncharacteristicly intolerant
>comment for him to make about how other people do Forth. It
>was in the context of a talk about what makes for good Forth.
So looking at http://www.complang.tuwien.ac.at/papers/ertl99ef.ps.gz
(this is the correct URL, sorry for giving the wrong one earlier), we
see that the smallest C program is rdp at 4947 source lines. So
bnfparse (14 source lines) is a good Forth program, and Gray (473
source lines) is not.
From what I have read about Chuck Moore, I guess that is about right;
I don't think he would consider using a parser generator like Gray as
the right approach to parsing; he might be more inclined to use a
parser support package like bnfparse, but actually I think he would go
for hand-writing his parser using an approach specialized for his
application, and ignore parser generators (Niklaus Wirth does that,
too). So if it's more than 100x smaller than C, that's not a
guarantee for being good Forth, either, right.
Jean-Francois Brouillet
<an...@mips.complang.tuwien.ac.at> wrote on 1/29/2000 11:32:
> In article <B4B4F192.151EE%jean-franco...@virgin.net>,
> Jean-Francois Brouillet <jean-franco...@virgin.net> writes:
>>> Well, my data indicates that the code size advantage of Forth over
>>> other languages is not due to threaded code (threaded code is not
>>> tighter than native code, see
>>> http://www.complang.tuwien.ac.at/forth/performance.html#size), and
>>> that it is at least partly due to language-induced design decisions
>>> (see http://www.complang.tuwien.ac.at/papers/ertl99.ps.gz).
>>>
>>
>> My experience contradicts your paper ;-)
>>
>> On the Hitach H8/3xx series, the only generic way to call
>> a subroutine is through 'JSR <@abs:16>'. The other two modes
>> ( BSR <8-bit> and JSR @page-0<8-bit> ) not being usable in the
>> general case (but useful for adhoc asm hacking)
>>
>> The JSR @abs:16 takes 4 bytes of object code.
>> An ITC/DTC Forth definition only takes 2 bytes. In this ITC/DTC
>> model, the only Forth constructs taking more than 2 bytes are
>> the LITERALs and some branch targets.
>
> On the 386 architecture whose code sizes are reported in
> http://www.complang.tuwien.ac.at/forth/performance.html#size, the size
> of a call is 5 bytes and the size of a threaded-code word is four
> bytes. However, not everything in native code is a call; by contrast,
> take a look at "8 + @". This is one instruction (3 bytes) in native
> code on the 386, whereas it takes 16 bytes in threaded code. Overall
> the native code is slightly smaller than the threaded code in my
> measurements.
>
Not to start bashing the 386 family, but obviously one of the
big difference comes from the word length. On a 32 bit system
it is probable that native gen _can_ be more dense than ITC/DTC
(but probably not TTC) but on a 16 bit system, the code size
advantage of ITC/DTC shows very clearly.
Your example above translates to, in 16 bit ITC:
<LIT ><8 ><+ ><@ >
<-16-><-16-><-16-><-16->
that is: 8 bytes,
where the corresponding native H8/3xx is
CODE foo ( 8 + @ ) \ 2 (pointer to PFA)
MOV.W @R6, R0 \ 2
MOV.W #8, R1 \ 4 LITERAL 8
ADD.W R1, R0 \ 2 +
MOV.W @R0, R0 \ 2 @
MOV.W R0, @R6 \ 2
(NEXT) \ 2
END-CODE
total: 16 bytes
(and discounting the first 2 and last 2 lines would simply
be cheating: the cost of interfacing with both the stack
and the threading system (here 8 bytes) is paid otherwise
in raw assembly, simply by the need to shuffle register
contents around, which is _always_ needed - in non trivial
programs - to solve the register mismatch between function
calls. Anyway, even if you were to do this, the core native
code (8 bytes) surely doesn't outperform the ITC version
(8 bytes too) as your paper would tend to suggest)
>> I *do* have experienced a 20% size decrease of my code size
>> when moving from raw assembly to ITC.
>>
>> Obviously, your mileage may vary ;-]
>
> Yes, as our results indicate. However, both your and my results
> support my conclusion that the big size differences reported (e.g.,
> 100x by Jeff Fox) are not due to the difference between native and
> threaded code.
This was not _my_ claim (100x); I'm just glad enough that my current
project lost 20% fat and went from above the 32K limit to below (at
about 26K now ;-)
> - anton
Charles Mélice
Wil Baden <wilb...@netcom18.netcom.com> a écrit dans l'article
> Forth works best with functions of at most two arguments. With
> more than that, calculations may be complicated, inefficient,
> and difficult to understand, especially without auxiliary
> variables.
Factoring resolve this problem.
This is part of the Forth philosophy.
The resulting code is more reliable, and more easy to test.
But I think you know that better then me !
> Recent attempts to adopt Forthish architecture to hardware are
> appalling: an extravagant number of registers, with limited
> access to them;
This is probably not a definitive state: its possible to append
optimisation features, for example, factorize at the assembler level.
But I think you know that better then me !
> and a data format incompatible with the rest of the world.
"1 CELLS" is compatible with all common format I know. Can you give
example, please ?
>
> (
> --
> Wil Baden Costa Mesa, California WilB...@Netcom.com
> )
>
Hoping greatly you continue to appreciate the Forth approach.
Charles Melice Belgium
Jeff Fox
>
> In article <388F7579...@UltraTechnology.com>,
> Jeff Fox <F...@UltraTechnology.com> writes:
> >Anton Ertl wrote:
> >> other languages is not due to threaded code (threaded code is not
> >> tighter than native code, see
> >> http://www.complang.tuwien.ac.at/forth/performance.html#size), and
> >
> >thinks good Forth is compact.
>
> Yes, but how does this relate to the native vs. threaded code size
> issue discussed above? He now uses native code, so he appears to
> agree with me on this.
Yes I think that we are all in sync on that. I like to point out
that there are different styles of optimizing code. There is
often a tradeoff between speed and size so that using inlining
instead of calls can remove some runtime overhead at the expense
of generating more code on some systems.
I have no problem with data showing that ITC or DTC with
32 bit cells is not likely to be smaller than native code.
However things like token threading can produce much smaller
object code. ITC and DTC are expensive on a wide bus in
that sense. In a sense the word size is the token size
in ITC or DTC, this gives you big spaces and lots of
words but will not generate small object code especially
on small problems. On very small problem (benchmark)
A system might only need a few tokens so they could be
very small, a few bit, they don't have to be 32 bits
just because it is threaded.
To me "threaded code" includes more things than just ITC and
DTC. Since some threading methods may produce much smaller
code than others I think comparing ITC and DTC to native
code on only one architecture is not general enough to
conclude that theaded code will not produce smaller
objects than native code. I do agree that threaded code is
not "tighter" code than optimized native code except
perhaps in rare cases where it is enough smaller that it
can stay in cache or in memory or something and be both
smaller and faster in the process.
I agree that ITC and DTC vs native code isn't going to result
in really big differences. That comes from exploring the algorithms,
moving things from runtime to compile time, more factoring,
using custom instead of canned functions, and mostly an effort
to do it. In fact the architecture I am used to has native code
that is several times smaller than ITC or DTC due to many
opcodes inlining to 5 bits and : defs being 20 bit calls while
all functions use 20 bit cells in ITC or DTC there.
> > He said that, "If it isn't 100
> >times smaller than 'C' it isn't (good) Forth." He actually
> >said "isn't Forth" but it was an uncharacteristicly intolerant
> >comment for him to make about how other people do Forth. It
> >was in the context of a talk about what makes for good Forth.
>
> So looking at http://www.complang.tuwien.ac.at/papers/ertl99ef.ps.gz
> (this is the correct URL, sorry for giving the wrong one earlier), we
> see that the smallest C program is rdp at 4947 source lines. So
> bnfparse (14 source lines) is a good Forth program, and Gray (473
> source lines) is not.
Chuck's statements are confusing. He says given a choice he
will always choose the simplest approach. But at the same
time he will make some of his code very highly optimized
using any trick in the book. If you look at some of the code
it is not the simplest approach at all in that it may be
highly hand optimized inlined code using clever tricks. Other
code built on top of that tends to be simple and highly
factored. To me this means that when he says he will always
choose the simplest approach this doesn't mean simpleminded
code. It also does not mean that because good code is small
that small code is good.
Sometimes very short code snippets are simple in terms of
being short, but very inefficient at runtime. They are often
presented in c.l.f to express short ideas about coding constructs
and while they are sometimes pretty they often come with
the disclaimer that no one uses this version because it
is too inefficient. If good code simply means short source
then these would be the best Forth code and that certainly is
not what Chuck means when he talks about good code being short
code.
Sometimes he will use code like that when it is high level
scripting code where runtime overhead is not an issue and
a short simple definition is better use of his time than
a carefully optimized version. Understanding Chuck's
approach to Forth is very much about knowing
when to factor, when not to factor, when to inline,
when not to inline, when to simplify and when to
optimize.
> From what I have read about Chuck Moore, I guess that is about right;
> I don't think he would consider using a parser generator like Gray as
> the right approach to parsing; he might be more inclined to use a
> parser support package like bnfparse, but actually I think he would go
> for hand-writing his parser using an approach specialized for his
> application, and ignore parser generators (Niklaus Wirth does that,
> too). So if it's more than 100x smaller than C, that's not a
> guarantee for being good Forth, either, right.
Very true. Chuck's definition of quality is such that compactness
is a byproduct of the approach. Chuck is the first compiler
and spends a lot of time distilling the idea and problem before
it gets to the computer compiler. He says problems can be solved
with large quantities of code or small quantities of well thought
out code.
While small size of source or object code may be an indication of
how much has been shifted from runtime to compile time or from
compile time to design time it can also be an indication of
the use of short (in size not time) but inefficient ways of
doing things.
Jeff Fox
Bernd Paysan
> The companies I've worked for mostly use C for development. There are
> people there who butcher the language, writing some of the most bloated,
> inefficient, and unmaintainable code I've ever seen. Then there are people
> who seem to have a deeper understanding of what's happening underneath the
> language who write wonderful, compact, efficient code. Same language--
> different results. It's obviously the programmer, not the language that
> matters.
Hm, this is the "good artists don't blame their tools" approach - but
good artists select their tools themselves. Certainly, a Stradivari
doesn't make you or me a good violinist, but even a Jehudi Menuhin can't
play good on a bad violine - but that's not the question here. Getting a
good tune out of a violine is more difficult than out of a keyboard. So,
for the average amateur musican, a keyboard is the more appropriate
tool. For the Menuhins, the keyboard can only produce something that
might be not completely unrelated to the output of a real instrument,
though there are high quality keyboards, which may (after being fed by
the right samples) produce something closer to the "real thing".
> But again, it's the programmer, not the language. There are bad Forth
> programmers for the same reason there are bad C++ and bad Java programmers.
I don't care about bad programmers. Bad programmers aren't worth
anything, regardless of what language they use. They should search a
profession that makes better use of their talents (whatever they are).
You can't teach a pig to sing, it annoys the pig and makes you look
stupid.
As much as you can write Fortran programs in any language, you can write
Forth programs in any language. You can apply factoring in every
language (ok, in Fortran or BASIC, you need a newer version), and you
certainly can apply the KISS principle everywhere (it doesn't need
language support). You can apply the rigid and more-or-less interactive
testing to any language. But to get back to gardeners: you can dig holes
with everything, and if there's nothing, you still can dig them with
your fingers. But you'd prefer a spade.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Elizabeth D Rather
> Yes, as our results indicate. However, both your and my results
> support my conclusion that the big size differences reported (e.g.,
> 100x by Jeff Fox) are not due to the difference between native and
> threaded code.
...[summarizing prev. discussions] the biggest difference is factoring
leading to high code reuse.
However, no one has shown that even that produces results in the 100x
bracket. When Chuck speaks of that level of compression, he is probably (in
addition to possibly exaggerating a little for effect, as I charged earlier)
he is also probably assuming a re-design that "simplifies" the problem
leaving out what he considers non-essential functionality (e.g. fancy user
interface).
In my 10 years of working side-by-side with Chuck on many projects, I know
he did this ruthlessly, and gather from the discussions of his CAD system
that this continues.
His normal pattern on a new project was to produce, very quickly, a tiny
program that to him performed all the "essential" functions of the spec.
Invariably, the customer was disatisfied about some functionality _he_
thought was essential but Chuck had left out. It was my job to negotiate
these things. Over a period of time, Chuck would reluctantly add feature
after feature. At the point at which the software was almost acceptable,
Chuck would wake up one morning with a "Eureka!" reaction and completely
redesign the code for an implementation that incorporated all the
functionality he had been persuaded was essential in a clean, consistent
fashion that was much better than the patchwork resulting from the
incremental add-ons.
If the customer knew this was happening, consternation reigned. He would
always prefer the version that was already "almost perfect" to the unknown
even though the latter might be potentially better (better the devil you
know...). The best we could hope for was to get the new version done before
being discovered! In a few cases, when the redesign was simply prohibited,
we had to bring in other programmers to finish the 2nd-stage version.
Of course, nowadays Chuck doesn't have external customers to please, so it's
only his evolving sense of "essential functionality" that governs. It's
likely that this will differ from common marketplace expectations for
similar programs.
Cheers,
Elizabeth
Jeff Fox
> When Chuck speaks of that level of compression, he is probably (in
> addition to possibly exaggerating a little for effect, as I charged earlier)
> he is also probably assuming a re-design that "simplifies" the problem
> leaving out what he considers non-essential functionality (e.g. fancy user
> interface).
I think you are quite right about that and it does sound like
Chuck. He likes to reduce the problem at the design stage
where possible and I can well imagine how that would work
with user's projects as you describe.
We did however see a lot of evidence of what happens when you apply
the design related aspects of his approach to problems and projects
with very specific requirements. We had a chance to compare
different implementations which met the exact same specs quite
often. So we could compare code for different compilers,
or different languages. The speed numbers tended to vary more
than the size numbers but they were occasionally 100x. At
least that was my experience
> In my 10 years of working side-by-side with Chuck on many projects,
In an unrelated subject I have a question about the history
of Forth and specifically at Forth Inc. When did Forth Inc.
first start supporting FP in your products? When the
Standard went with either a separate FP stack or the FP
stack integrated with the data stack what was the reason
for the lobby for FP on data stack? Is that as important
today as it was at that time or has the balance shifted on that
issue?
Jeff Fox
Elizabeth D. Rather
>
> In an unrelated subject I have a question about the history
> of Forth and specifically at Forth Inc. When did Forth Inc.
> first start supporting FP in your products? When the
> Standard went with either a separate FP stack or the FP
> stack integrated with the data stack what was the reason
> for the lobby for FP on data stack? Is that as important
> today as it was at that time or has the balance shifted on that
> issue?
Our first support for FP was in the mid-70's using PDP-11 hardware floating
point in a project for Cal Tech. We later added support for 8087-class
processors in the early 80's. We have rarely done software FP (the exception
was for the Novix), because if you don't have the hardware it's way slower than
fixed-point fraction methods for transcendental functions etc., and we do supply
those libraries.
As for the option in ANS Forth for having FP on the data stack, that was done as
a special concession to Harris for the RTX. There has been some discussion of
declaring that entitlement "obsolescent" (which would give us the freedom to
ditch it in the _next_ standards round).
Cheers,
Elizabeth
--
===============================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-372-8493
111 N. Sepulveda Blvd. Fax: +1 310-318-7130
Manhattan Beach, CA 90266
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
===============================================
Axel Harvey
> [ ... ]
> As for the option in ANS Forth for having FP on the data stack, that was done as
> a special concession to Harris for the RTX. There has been some discussion of
> declaring that entitlement "obsolescent" (which would give us the freedom to
> ditch it in the _next_ standards round).
There are advantages to both arrangements.
With fp on the data stack, many useful operations can be done in
high-level Forth, particularly if the binary exponent is at the front
(i.e. "top") of the stack, for example : f10* 1+ fdup 2 + f+ ; .
With separate stacks the code is much more fluid. It's almost like
having a return stack where you can do operations while the data stack
takes a breather. :)~
Swidbert R Ott
he ever stop his art metaphors?
--
Swidbert R. OTT
Dept. Zoology, Univ. Cambridge/UK
Bart Lateur
>Over a period of time, Chuck would reluctantly add feature
>after feature. At the point at which the software was almost acceptable,
>Chuck would wake up one morning with a "Eureka!" reaction and completely
>redesign the code for an implementation that incorporated all the
>functionality he had been persuaded was essential in a clean, consistent
>fashion that was much better than the patchwork resulting from the
>incremental add-ons.
Now this is the main reason for the worshipping of Chuck Moore by the
FORTH crowd. Some people in this newsgroup don't like that... :-)
>If the customer knew this was happening, consternation reigned. He would
>always prefer the version that was already "almost perfect" to the unknown
>even though the latter might be potentially better (better the devil you
>know...). The best we could hope for was to get the new version done before
>being discovered!
This is rather unbelievable.
So the customer prefers the clumsy, imperfect "prototype" to the second
version, the "real thing".
--
Bart.
Elizabeth D. Rather
This is not unreasonable or illogical. Suppose I (as the customer) see a system
that is very close to doing what it needs to do. I'm not looking at internal
structure, but external functionality and costs to date vs. budget. Both are
nearing their limits. Now the programmer wants to throw away all this
nearly-working code and start over. He _says_ it won't take long and the result
will be better, but can I believe that? Isn't it natural for me to say, "Why
can't you just finish polishing what you have, which is so close to what I
need?"
We're looking at human nature here.
Anton Ertl
Jean-Francois Brouillet <jean-franco...@virgin.net> writes:
>in article <86uj4a$d6p$1...@news.tuwien.ac.at>, "Anton Ertl" at
><an...@mips.complang.tuwien.ac.at> wrote on 1/29/2000 11:32:
>> On the 386 architecture whose code sizes are reported in
>> http://www.complang.tuwien.ac.at/forth/performance.html#size, the size
>> of a call is 5 bytes and the size of a threaded-code word is four
>> bytes. However, not everything in native code is a call; by contrast,
>> take a look at "8 + @". This is one instruction (3 bytes) in native
>> code on the 386, whereas it takes 16 bytes in threaded code. Overall
>> the native code is slightly smaller than the threaded code in my
>> measurements.
>>
>
>Not to start bashing the 386 family, but obviously one of the
>big difference comes from the word length. On a 32 bit system
>it is probable that native gen _can_ be more dense than ITC/DTC
>(but probably not TTC) but on a 16 bit system, the code size
>advantage of ITC/DTC shows very clearly.
>
>Your example above translates to, in 16 bit ITC:
>
><LIT ><8 ><+ ><@ >
>
><-16-><-16-><-16-><-16->
>
>that is: 8 bytes,
This is still more than twice as long as the native code size on the
386; I wouldn't call that bashing the 386.
>where the corresponding native H8/3xx is
>
>CODE foo ( 8 + @ ) \ 2 (pointer to PFA)
>MOV.W @R6, R0 \ 2
>MOV.W #8, R1 \ 4 LITERAL 8
>ADD.W R1, R0 \ 2 +
>MOV.W @R0, R0 \ 2 @
>MOV.W R0, @R6 \ 2
>(NEXT) \ 2
>END-CODE
The H8/3xx doesn't have an reg+constant addressing mode, not even an
add instruction wih immediate operands? Still, the sequence 8 + @
takes 8 bytes, the same as in threaded code.
>(and discounting the first 2 and last 2 lines would simply
> be cheating: the cost of interfacing with both the stack
> and the threading system (here 8 bytes) is paid otherwise
> in raw assembly, simply by the need to shuffle register
> contents around, which is _always_ needed - in non trivial
> programs - to solve the register mismatch between function
> calls.
Yes, in register code there is some register shuffling, and in stack
code there is stack shuffling.
The example I gave is one extreme case where native code is favoured,
and you gave an example where threaded code is favoured. What is
smaller overall depends on various factors.
Anton Ertl
"Elizabeth D Rather" <era...@forth.com> writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote in message
>news:86uj4a$d6p$1...@news.tuwien.ac.at...
>> Yes, as our results indicate. However, both your and my results
>> support my conclusion that the big size differences reported (e.g.,
>> 100x by Jeff Fox) are not due to the difference between native and
>> threaded code.
>
>...[summarizing prev. discussions] the biggest difference is factoring
>leading to high code reuse.
>
>However, no one has shown that even that produces results in the 100x
>addition to possibly exaggerating a little for effect, as I charged earlier)
>he is also probably assuming a re-design that "simplifies" the problem
>leaving out what he considers non-essential functionality (e.g. fancy user
>interface).
Certainly. The difference between bnfparse (14 source lines) and Gray
(473 source lines) is mainly a difference in functionality.
I took a closer look at the difference between Gray and Coco/R (the
next-smallest program with similar functionality, written in Modula-2,
4005 source lines). I couldn't identify size differences due to
factoring; the designs weretoo different in general, and for the
comparable parts (in particular, the sets code) the size differences
were small.
Apart from functionality differences, the size difference between Gray
and Coco/R seems to come mainly from design differences; some of these
design differences are language-induced (accounting for at least 1178
source lines of Coco/R), others are things that can be done in both
languages.
Bernd Paysan
> This is not unreasonable or illogical. Suppose I (as the customer) see a system
> that is very close to doing what it needs to do. I'm not looking at internal
> structure, but external functionality and costs to date vs. budget. Both are
> nearing their limits. Now the programmer wants to throw away all this
> nearly-working code and start over. He _says_ it won't take long and the result
> will be better, but can I believe that? Isn't it natural for me to say, "Why
> can't you just finish polishing what you have, which is so close to what I
> need?"
A good parable might be creating a bronze. You start up with a wax model
of what you want to form. When it looks like it should be, you cover it
with mud, dry that mud, melt the wax, and fill in the bronze. It pretty
much looks like destroying what you have (the mud traditionally consists
of loam and horse shit), but in fact, it's the only way to make the wax
statue durable.
Jean-Francois Brouillet
<an...@mips.complang.tuwien.ac.at> wrote on 2/5/2000 15:48:
> In article <B4B8DA48.158CC%jean-franco...@virgin.net>,
> Jean-Francois Brouillet <jean-franco...@virgin.net> writes:
>> in article <86uj4a$d6p$1...@news.tuwien.ac.at>, "Anton Ertl" at
>> <an...@mips.complang.tuwien.ac.at> wrote on 1/29/2000 11:32:
>>> On the 386 architecture whose code sizes are reported in
>>> http://www.complang.tuwien.ac.at/forth/performance.html#size, the size
>>> of a call is 5 bytes and the size of a threaded-code word is four
>>> bytes. However, not everything in native code is a call; by contrast,
>>> take a look at "8 + @". This is one instruction (3 bytes) in native
>>> code on the 386, whereas it takes 16 bytes in threaded code. Overall
>>> the native code is slightly smaller than the threaded code in my
>>> measurements.
>>>
>>
>> Not to start bashing the 386 family, but obviously one of the
>> big difference comes from the word length. On a 32 bit system
>> it is probable that native gen _can_ be more dense than ITC/DTC
>> (but probably not TTC) but on a 16 bit system, the code size
>> advantage of ITC/DTC shows very clearly.
>>
>> Your example above translates to, in 16 bit ITC:
>>
>> <LIT ><8 ><+ ><@ >
>>
>> <-16-><-16-><-16-><-16->
>>
>> that is: 8 bytes,
>
> This is still more than twice as long as the native code size on the
> 386; I wouldn't call that bashing the 386.
As soon as you get a 386 for Smart Cards, send me an email:
I'll be _really_ interested ;-)
>
>> where the corresponding native H8/3xx is
>>
>> CODE foo ( 8 + @ ) \ 2 (pointer to PFA)
>> MOV.W @R6, R0 \ 2
>> MOV.W #8, R1 \ 4 LITERAL 8
>> ADD.W R1, R0 \ 2 +
>> MOV.W @R0, R0 \ 2 @
>> MOV.W R0, @R6 \ 2
>> (NEXT) \ 2
>> END-CODE
>
> The H8/3xx doesn't have an reg+constant addressing mode
It has:
MOV.B @(d:16, Rx), Ry.B
MOV.W @(d:16, Rx), Ry
MOV.B Rx.B, @(d:16, Ry)
MOV.W Rx, @(d:16, Ry)
But since, in that case, the operand is on TOS "@(0, R6)"
this isn't of much help.
Even if the TOS was cached in some reg (not that we have
plenty of them ;-( the best native version I could come
up with is:
MOV.W #8, R1 \ 4 -- still have to load the imm:16 into a reg
ADD.W R1, R4 \ 2 -- say R4 is the TOS
MOV.W @R4, R4 \ 2
(NEXT) \ 2
Discounting the aforementioned overheads,
we still end up with 10 bytes code which certainly doesn't
outperform the ITC version.
> not even an add instruction wih immediate operands?
It has:
ADD.B #imm:8, Rx.B
but no equivalent for #imm:16, so you have to load
the immediate 16 bits value first into some spare reg.
(Or you could:
ADD.B #8, R4L \ 2
ADDX.B #0, R4H \ 2
but there would be _no_ code savings, and the code
would be slightly slower)
> Still, the sequence 8 + @
> takes 8 bytes, the same as in threaded code.
>
>> (and discounting the first 2 and last 2 lines would simply
>> be cheating: the cost of interfacing with both the stack
>> and the threading system (here 8 bytes) is paid otherwise
>> in raw assembly, simply by the need to shuffle register
>> contents around, which is _always_ needed - in non trivial
>> programs - to solve the register mismatch between function
>> calls.
>
> Yes, in register code there is some register shuffling, and in stack
> code there is stack shuffling.
Yes. Except that a SWAP finds the temporary "magically" whereas,
when you want to exchange R0 and R1 you have to free some Rx, at
least temporarily -- unless you happen to have a spare one, which
is rare enough -- which, again, increases code size. Beside this
in 16 bit ITC SWAP is always 2 bytes whereas the lucky "spare reg
case" native version is 6 bytes.
>
> The example I gave is one extreme case where native code is favoured,
> and you gave an example where threaded code is favoured. What is
> smaller overall depends on various factors.
Obviously.
But discounting ITC as an old-fashioned technique that native
compilation has rendered obsolete (what your referred to web
page somehow implies) is a bit too quick.
That's the main point I wanted to drive home: there's no panacea,
and ITC has other advantages that native code will ever lack such
as near "out-of-the-box" _binary_ portability of user code ;-)
>
> - anton
Anton Ertl
Jean-Francois Brouillet <jean-franco...@virgin.net> writes:
>It has:
>
>MOV.B @(d:16, Rx), Ry.B
>MOV.W @(d:16, Rx), Ry
>MOV.B Rx.B, @(d:16, Ry)
>MOV.W Rx, @(d:16, Ry)
>
>But since, in that case, the operand is on TOS "@(0, R6)"
>this isn't of much help.
You load that first into a register, anyway.
>Even if the TOS was cached in some reg (not that we have
>plenty of them ;-( the best native version I could come
>up with is:
>
>MOV.W #8, R1 \ 4 -- still have to load the imm:16 into a reg
>ADD.W R1, R4 \ 2 -- say R4 is the TOS
>MOV.W @R4, R4 \ 2
>(NEXT) \ 2
What's wrong with
MOV.W @(8,R4),R4
(NEXT)
>Discounting the aforementioned overheads,
>we still end up with 10 bytes code which certainly doesn't
>outperform the ITC version.
Since you include the NEXT for native code, how about including the
code field and the EXIT/;S for the threaded code.
>> Yes, in register code there is some register shuffling, and in stack
>> code there is stack shuffling.
>
>Yes. Except that a SWAP finds the temporary "magically" whereas,
>when you want to exchange R0 and R1 you have to free some Rx, at
>least temporarily -- unless you happen to have a spare one, which
>is rare enough -- which, again, increases code size. Beside this
>in 16 bit ITC SWAP is always 2 bytes whereas the lucky "spare reg
>case" native version is 6 bytes.
A sophisticated native code compiler would just remap the registers;
in the ideal case, this leads to no register shuffling for a SWAP;
e.g., consider the sequence
swap 1+ swap
This would become one instruction on most architectures, without any
register shuffling.
In less fortunate cases, you may have to do the shuffling upon control
flow joins.
>But discounting ITC as an old-fashioned technique that native
>compilation has rendered obsolete (what your referred to web
>page somehow implies) is a bit too quick.
Where does it imply this? I certainly think that threaded code is not
obsolete. I am one of the authors of Gforth, a threaded-code system,
and have no intention of throwing it away in favour of a native-code
system.
>That's the main point I wanted to drive home: there's no panacea,
>and ITC has other advantages that native code will ever lack such
>as near "out-of-the-box" _binary_ portability of user code ;-)
Although Gforth's image files have this feature (at least between
platforms with the same cell size and byte order), I don't consider
that an important advantage (probably because my main platforms have
different word size and all the stuff I have is available as source).
The possibilities of accessing the code easily with tools (e.g.,
writing SEE) are more important IMO.
However, the most important point for me is that it is relatively
simple way to implement a Forth system (or any other programming
language implementation) for multiple platforms with relatively high
performance.
Jean-Francois Brouillet
<an...@mips.complang.tuwien.ac.at> wrote on 2/6/2000 15:31:
>> MOV.W #8, R1 \ 4 -- still have to load the imm:16 into a reg
>> ADD.W R1, R4 \ 2 -- say R4 is the TOS
>> MOV.W @R4, R4 \ 2
>> (NEXT) \ 2
>
> What's wrong with
>
> MOV.W @(8,R4),R4
> (NEXT)
Nothing!
And I'm a bit embarrassed now ;-{
>> Discounting the aforementioned overheads,
>> we still end up with 10 bytes code which certainly doesn't
>> outperform the ITC version.
>
> Since you include the NEXT
Change this to: RTS if you wish, that's the same byte count/
same effect.
> for native code, how about including the
> code field and the EXIT/;S for the threaded code.
that's what I did in the previous round:
>>>> CODE foo ( 8 + @ ) \ 2 (pointer to PFA)
...
>>>> (NEXT) \ 2
>>>> END-CODE
>>>> total: 16 bytes
which still is comparing favorably (that is, for my argument
that native code can be bigger than ITC) to
<ENTER><LIT><8><+><@><EXIT>: 12 bytes,
and, assuming I can't cache the TOS (which I effectively can't
for other reasons), in _my_ case I'm better off with ITC.
But if I could cache the TOS, then your example above would
probably win.
>
>>> Yes, in register code there is some register shuffling, and in stack
>>> code there is stack shuffling.
>>
>> Yes. Except that a SWAP finds the temporary "magically" whereas,
>> when you want to exchange R0 and R1 you have to free some Rx, at
>> least temporarily -- unless you happen to have a spare one, which
>> is rare enough -- which, again, increases code size. Beside this
>> in 16 bit ITC SWAP is always 2 bytes whereas the lucky "spare reg
>> case" native version is 6 bytes.
>
> A sophisticated native code compiler would just remap the registers;
> in the ideal case, this leads to no register shuffling for a SWAP;
> e.g., consider the sequence
>
> swap 1+ swap
>
> This would become one instruction on most architectures, without any
> register shuffling.
In my next life, I'll have such a compiler !-)
> In less fortunate cases, you may have to do the shuffling upon control
> flow joins.
>
>> But discounting ITC as an old-fashioned technique that native
>> compilation has rendered obsolete (what your referred to web
>> page somehow implies) is a bit too quick.
>
> Where does it imply this? I certainly think that threaded code is not
> obsolete. I am one of the authors of Gforth, a threaded-code system,
> and have no intention of throwing it away in favour of a native-code
> system.
>
>> That's the main point I wanted to drive home: there's no panacea,
>> and ITC has other advantages that native code will ever lack such
>> as near "out-of-the-box" _binary_ portability of user code ;-)
>
> Although Gforth's image files have this feature (at least between
> platforms with the same cell size and byte order), I don't consider
> that an important advantage (probably because my main platforms have
> different word size and all the stuff I have is available as source).
>
> The possibilities of accessing the code easily with tools (e.g.,
> writing SEE) are more important IMO.
>
> However, the most important point for me is that it is relatively
> simple way to implement a Forth system (or any other programming
> language implementation) for multiple platforms with relatively high
> performance.
>
> - anton
Stephen Pelc
>MOV.W #8, R1 \ 4 -- still have to load the imm:16 into a reg
>ADD.W R1, R4 \ 2 -- say R4 is the TOS
>MOV.W @R4, R4 \ 2
>(NEXT) \ 2
>
>we still end up with 10 bytes code which certainly doesn't
>outperform the ITC version.
From the MPE H8/300H VFX cross compiler in 32 bit mode,
which is usually bigger than 16 bit code we get the following
output:
: t 8 + @ ; ok
dis t
T
( 0000.5EB6 01006F330008 ) MOV.L 08 @(ER3) ER3
( 0000.5EBC 5470 ) RTS/NEXT
8 bytes
ok
In general, as I keep saying, native code compilers can generate
tight code, but you have to put in the same amount of work as MPE
put into VFX or Anton put into RAFTS to get it.
--
Stephen Pelc, s...@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)2380 631441, fax: +44 (0)2380 339691
web: http://www.mpeltd.demon.co.uk - free ProForth downloads!
Stephen Pelc
><an...@mips.complang.tuwien.ac.at> wrote on 2/6/2000 15:31:
>> What's wrong with
>>
>> MOV.W @(8,R4),R4
>> (NEXT)
>
>Nothing!
>And I'm a bit embarrassed now ;-{
...
>> A sophisticated native code compiler would just remap the registers;
>> in the ideal case, this leads to no register shuffling for a SWAP;
>> e.g., consider the sequence
>>
>> swap 1+ swap
>>
>> This would become one instruction on most architectures, without any
>> register shuffling.
>
>In my next life, I'll have such a compiler !-)
Such a compiler is available from MPE now, and is in use all over the
world.
Swidbert R Ott
> A good parable might be creating a bronze.
He, the Michelangelo of code, the Gould of the Forthberg Variationss, will
Jerry Avins
Come on, Swiddy! Programming is an art, as is writing good English.
Taken in context, I thought that metaphor rather apt.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------