Re: made it to page 4 of gforth tutorial

On Apr 24, 10:36 am, Elizabeth D Rather <erat...@xxxxxxxxx> wrote:

We have had this argument many times. I got so tired of giving
you the facts over and over and your coming back saying it was
"certainly" untrue and then changing the subject that I posted
a web page a decade ago reviewing in detail some of the actual
offensive code from the FSL as you appeared to forget the details
year after year. I thought it might be educational for other
people promoting this code but denying that they knew any of
the details.

Sounds like the problem is with the FSL code itself, not its
conformance to ANS Forth.  Without looking at the code to
see what took so much stack space, I couldn't do more than
guess, but can imagine some possibile causes, such as trying
to maintain floats on an integrated stack instead of a
separate stack, in which case a possible solution
might have been to put floats in DRAM and leave the
other stacks on board.

I know you have a selective memory problem but I doubt if
the smoke screen about how the problem might have been
related to some ridiculous made-up guesses when we I have
reviewed the facts and actual code examples so many times
in c.l.f and posted web pages about it.

So let's review again. The subject of code to access
fields in structures often comes up in c.l.f and the
usual response from supporters of using C-style structures
in Forth is that in theory, in theory mind you, all that
is actually needed is base-plus-offset calculation and
that all that is needed to make it reasonable efficient
in support of C-style is a base-plus-offset form of
memory addressing in the hardware.

But the real code in the FSL to this was some of the worst
ANS Forth code I had ever seen. It made gavino's Forth
code look very good yet it was being promoted by quite
a few c.l.f posters especially you.

People like to say that all that is needed for C-style
structures in Forth is a base-plus-offset addressing
mode but that was not the issue here or problem with
the code.

To aid your failing memory and refusal to read actual
accounts of what was wrong with the code you were promoting
let me review it again.

C-sytle structure field access in the FSL was not just
a base-plus-offset calculation. It was several lines of
code that ended with two print statements for diagnostic
purposes. The actual library code was easily 100x bigger
than just a base-plus-offset calculation. It wasn't a
floating point issue. It wasn't single or mixed floating
point stack issue. Those were absurd guesses unless you
think you need floating point math to do Internet protocols.

When the code got pasted in to an embedded application the
several lines of structure field access code below all the
network protocol code did have the two print statements at
the end removed. This made it only about another 10x on
top of the 100x issue for this environment. But that was
all that had been done.

In a staff meeting and code review soon after, and again
several times in c.l.f, and later on a web page about C-style
structures in Forth, I reviewed the actual code. When the
two print statements were removed they were replaced by
2DROP as if an optimizing compiler was going to turn the
rest of the ugly remaining code into good code.

Since the two arguments were eventually removed by a 2DROP
at the end the arguments were still carried throughout the
entire definition in a wonderful example of stack-juggling.
In addition to the extra weight of an unneeded 2DROP there
were OVERs, DUPs, and 2DUPs, throughout the word to carry
the garbage to the end of the definition. So in our staff
meeting and code review, in c.l.f, and on a web page I
questioned why all that unnecessary stack-juggling had
not been removed from the code in the first place. It
was code I would have thought would be an easy exercise
for a second-day Forth programmer to fix. It only took
a couple of minutes to make it five times faster or so
by removing the garbage.

It made me wonder which optimizing native code Forth
compilers remove all the stack-juggling code over several
lines of previously compiled code when they encounter that
sort of poor quality Forth source code.

In the code review I showed that in many cases all that
had really been needed was to use one five-bit opcode
in machineForth with no size or speed penalty instead
of another instead of pasting from a library and getting
the 100x x 10x or 1000x example was the sort of thing
that Chuck politely said was an example of
"not getting it right."

You can simply declare again that this wasn't true and
that it was "certainly not a hundred times slower."

It is silly of you to assert that it would not be true
in a completely different content that the one at hand.

Ok, putting stacks in DRAM is 100 times slower than having
them on-chip. That's not the same thing as saying that ANS
Forth is necessarily 100 times slower than native code.  

It "certainly" was as true in the context of the statements
that were made. You can try to change the subject to how
the statements made would not be true in a completely
different imaginary context than the one given but that
is just avoiding trying to defend your original statement.

You've identified problems with FSL code and iTV decisions;
put the responsibility for slow code where it belongs.

Both iTV and I should take responsibility for a number of
things and "not getting them right."

We had this argument just a few months ago and you response
was that it was so long ago you had hoped people would have
forgotten all about it like you had.

I recommended that they use a Forth Inc. optimizing native
code compiler, not because we didn't have a dozen different
people in house, including Chuck Moore who could write one.
I made that recommendation because I was in agreement with
them that there would be perceived "value added" if they
could point to ANS compliance for people who were worried
about portability and show that Forth Inc. offered a
product tuned for the job.

I know what cost they told me they had been quoted.
I know that you have denied that that was the cost that
you quoted. So I don't know if their decision not to
go that way was as bad as their decision to also not
use an already written and demonstrated native code
optimizing compiler converting ANS to machineForth
that was free.

I and iTV should admit that it was our mistake to use a
"professional Forth compiler" that we purchased from
Forth Inc. for the project. I freely admit that I made
an error that I learned from on that one.

I had believed what you told us, that it was professional
quality, that it had professional documentation, and that
it would have professional support. I eventually learned
that these were simply untrue marketing claims.

The $4000 per copy that we spent on that tool was a big
waste but little did we know that it would be about the
buggiest Forth any of us had ever seen. We did not know
that the huge boxes were because of silly useless machine
generated documentation that only detailed such things
as what DUP does and what its stack diagram looks like.
There was no documentation about how any of the important
Windows interface code worked or didn't work in so many
cases. But the worst problem was that your marketing
claim of it including "professional support" actually
meant it included zero support.

As you no doubt recall since we have this argument every
couple of years was that you said that MPE needed to provide
the support because they wrote it. MPE said Forth Inc.
needed to provide support because they sold it. We said
that "someone" needed to provide support because we bought
it based your claims of "professional support."

You have acknowledged these facts in the past also. Your
comment was that, "It was a most unfortunate situation for
everyone."

That wasn't exactly the way I saw it since we were the ones
who got burned and Forth Inc. were the ones to walk away
with over $40,000.00 of our money and then abandon us.

It was an important lesson in my career. The last time this
subject came up last year your response was people should
forget it because it was long in the past. We got sold a
pig in a poke and you hoped we would forget about it and
not tell anyone I guess.

You may say that it was iTV's fault that we believed your
claims and ended up being sold a pig-in-a-poke instead
of professional quality code, professional quality
documentation, and any support at all let alone professional
quality support. That's one way to see it I guess.

I do admit it was a mistake to have believed your claims
at that time. Later we found that we could avoid the five
minute compiles using your "professional quality" product
and could do the same thing without all the bugs and bug
work arounds using gforth and get fifteen second compiles,
twenty times faster compiles, with free software.

More than ten years later we were surprised again
at IntellaSys that the VentureForth compiler and
simulator for SEAforth chips ran faster under
gforth-fast than under SwiftForth.

What still puzzles me is that you don't seem to like
the story of our mistakes of believing you, purchasing
Forth products for $4000 per desk, and getting zero
support but for some reason you bring up the subject
every year or two. You can't deny the actual facts but
you say you forget them and hope other people did too.
Yet every couple of years you bring the whole thing
up again with comments such that the performance
numbers in that context were "certainly" not true.

Then we go over again how you think it was iTV's mistake
to have believed your claims which proved so untrue
and such an expensive error for our company. You have
never been willing to admit that the worst parts of
the problem was actually your responsibility.

And I always end up agreeing with you that both I and
iTV managment made a terrible mistake back then by
thinking your marketing claims about what you were
selling were true.

I just don't get why you want to bring up the $4000
per copy for buggy, undocumented, and completely
unsupported "professional Forth" mistake we made
back then by believing your claims.

Cheers,
Elizabeth

Best Wishes
.

Relevant Pages

  • Re: [PATCH] a new UniCore32 arch-dependent patch for linux-2.6.37-rc1
    ... I've started a review of your code with lots of comments for roughly ... multi-cpu support from the ARM tree. ... * compiler that it's constant. ...
    (Linux-Kernel)
  • Re: how do you start learning assembly language
    ... compiler technology for decades, and which every compiler author have ... And I have refuted your claim that monofiles are bad idea or "design lack" ... Yes, I said that if an assembler did not support linking, it ...
    (alt.lang.asm)
  • Re: FBI: Cuba hiding dozens of wanted fugitives
    ... News wonders whether Cuba will cough up dozens of fugitives hiding on ... But then you support those that kill people, rob banks, bomb bars ... ... Whenever Dan Christensen is stuck he resorts to slander and lies out of frustration. ... campaign: facts he can't deny. ...
    (soc.culture.cuba)
  • ANN: Chicken 2.0
    ... - The compiler is able to inline more procedure calls ... - The alternative continuation API described in Marc Feeley's paper ... Hash-tables support now user-defined hash functions ...
    (comp.lang.scheme)
  • Re: Lint
    ... There are many versions of lint out there from "free" to expensive. ... Free, as in open source, will often take time to get full use of - and it may have hidden "costs" (such as license or support issues). ... Secondly, C compilers do much better static error checking than they used to as a side effect of better optimisation - while figuring out things like aliasing, variable lifetimes, and ideal memory organisation, a compiler can often spot buffer overflows and other such errors. ...
    (comp.arch.embedded)