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

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

Question about checking the stack

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

Contents

  Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-11-24 22:31 -0800
    Re: Question about checking the stack Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-25 07:46 +0100
      Re: Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-11-24 23:09 -0800
        Re: Question about checking the stack Ron Aaron <rambamist@gmail.com> - 2015-11-25 09:16 +0200
    Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-24 23:19 -0800
      Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-24 22:05 -1000
        Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-25 13:17 -0800
          Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 13:58 -1000
            Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-25 18:00 -0800
              Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 17:44 -1000
                Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-25 23:05 -0800
                  Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 21:38 -1000
                    Re: Question about checking the stack Ron Aaron <rambamist@gmail.com> - 2015-11-26 09:49 +0200
                      Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 22:42 -1000
                      Re: Question about checking the stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 14:51 +0000
                        Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-30 13:00 -0800
                          Re: Question about checking the stack hughaguilar96@gmail.com - 2015-11-30 21:54 -0800
                            Re: Question about checking the stack Julian Fondren <julian.fondren@gmail.com> - 2015-12-01 04:24 -0800
                              Re: Question about checking the stack Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-01 05:07 -0800
                                Re: Question about checking the stack Julian Fondren <julian.fondren@gmail.com> - 2015-12-01 06:02 -0800
                                Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-12-01 19:30 -1000
                              Re: Question about checking the stack Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-01 14:47 +0000
                                Re: Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-12-01 11:56 -0800
                                  Re: Question about checking the stack Alfred Singlestone <vitonis@gmail.com> - 2015-12-03 05:48 -0800
                                  Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-12-03 09:24 -1000
                                    Re: Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-12-03 21:10 -0800
                                      Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-12-03 20:52 -1000
                                        Re: Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-12-04 06:08 -0800
                                Re: Question about checking the stack Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-01 20:32 +0000
                                Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-12-01 19:32 -1000
                          Re: Question about checking the stack Lars Brinkhoff <lars.spam@nocrew.org> - 2015-12-01 08:18 +0100
                      Re: Question about checking the stack Alfred Singlestone <vitonis@gmail.com> - 2015-11-27 06:25 -0800
                        Re: Question about checking the stack Ron Aaron <rambamist@gmail.com> - 2015-11-28 17:55 +0200
                          Re: Question about checking the stack mhx@iae.nl - 2015-11-28 08:24 -0800
                            Re: Question about checking the stack Ron Aaron <rambamist@gmail.com> - 2015-11-28 20:54 +0200
                          Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-28 11:32 -1000
                            Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-28 19:17 -0800
                            Re: Question about checking the stack Ron Aaron <rambamist@gmail.com> - 2015-11-29 07:30 +0200
                            Re: Question about checking the stack Alfred Singlestone <vitonis@gmail.com> - 2015-11-29 09:41 -0800
                              Re: Question about checking the stack minforth@arcor.de - 2015-11-30 01:48 -0800
                                Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-30 08:03 -1000
                        Re: Question about checking the stack hughaguilar96@gmail.com - 2015-11-28 19:09 -0800
                    Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-26 00:03 -0800
                      Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 22:49 -1000
                    Re: Question about checking the stack hughaguilar96@gmail.com - 2015-11-26 10:59 -0800
              Re: Question about checking the stack franck.bensusan@gmail.com - 2015-11-25 21:03 -0800
            Re: Question about checking the stack Alfred Singlestone <vitonis@gmail.com> - 2015-11-27 06:14 -0800
    Re: Question about checking the stack "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-25 04:54 -0500
    Re: Question about checking the stack François <francois.ganza@wanadoo.fr> - 2015-11-25 03:09 -0800
    Re: Question about checking the stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-25 12:53 +0000
      Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-25 09:02 -0800
        Re: Question about checking the stack Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-25 18:53 +0100
          Re: Question about checking the stack Paul Rubin <no.email@nospam.invalid> - 2015-11-25 12:01 -0800
        Re: Question about checking the stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-25 17:26 +0000
    Re: Question about checking the stack François <francois.ganza@wanadoo.fr> - 2015-11-25 13:51 -0800
    Re: Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-11-28 09:29 -0800
      Re: Question about checking the stack Alfred Singlestone <vitonis@gmail.com> - 2015-11-28 12:03 -0800
    Re: Question about checking the stack François <francois.ganza@wanadoo.fr> - 2015-12-01 06:15 -0800
    Re: Question about checking the stack Chris Curl <ccurl609@gmail.com> - 2015-12-01 14:05 -0800
      Re: Question about checking the stack "Elizabeth D. Rather" <erather@forth.com> - 2015-12-01 19:35 -1000
      Re: Question about checking the stack dunno <dunno@dunno.dunno> - 2015-12-03 03:40 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#43724 — Question about checking the stack

For you guys who have implemented your own Forths ... when do you check the stack?

Playing with it in SP-Forth (with the stack empty) ... I see this behavior:

"." gives me ONE number followed by "-4 Stack underflow."
". ." gives me ONE number and the -4 error.
": sss . . . ; sss" gives me THREE numbers and the -4 error. 
": xxx sss sss ; xxx" gives me SIX numbers and the -4 error. 
Lastly, "sss sss" gives me THREE numbers and the -4 error. 

So it looks like it doesn't check the stack at all during execution; rather, it checks after executing each word during the interpretation loop.

Is that pretty standard behavior?

[toc] | [next] | [standalone]

#43726

Chris Curl <ccurl609@gmail.com> writes:
> For you guys who have implemented your own Forths ... when do you
> check the stack?

Same as SP-Forth: after interpreting each word.

The traditional (FIG Forth and others?) name is ?STACK, for what that's
worth.  Also there's !CSP and ?CSP for checking that colon definitions
are balanced with respect to control structures.

They are mentioned here:
http://pfe.sourceforge.net/pfe-wordsets/tools_misc.html
http://github.com/larsbrinkhoff/forth-documents/blob/master/figForth-glossary.txt

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

#43729

On Wednesday, November 25, 2015 at 1:46:31 AM UTC-5, Lars Brinkhoff wrote:
> Same as SP-Forth: after interpreting each word.
> 
> The traditional (FIG Forth and others?) name is ?STACK, for what that's
> worth.  Also there's !CSP and ?CSP for checking that colon definitions
> are balanced with respect to control structures.
> 
> They are mentioned here:
> http://pfe.sourceforge.net/pfe-wordsets/tools_misc.html
> http://github.com/larsbrinkhoff/forth-documents/blob/master/figForth-glossary.txt
That works for me! I was hoping that it was OK to avoid the overhead of having to check on every single access. 

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

#43732

On 11/25/2015 09:09, Chris Curl wrote:
> That works for me! I was hoping that it was OK to avoid the overhead of having to check on every single access. 

"OK" really depends on context.

In 8th, the stack is checked before each access, and an exception is
thrown if over- or under-flow will occur.  The reason that is done is
because 8th is intended for end-user applications (e.g. for mobile
devices etc), and one of the primary concerns is security.  If you allow
access off the end of the stack, you likely will open up a security
hole.  That's our thoughts anyway.

In practice, the extra tens of nanoseconds it takes to check that the
stack is not empty or not full are not noticeable.

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

#43733

Chris Curl <ccurl609@gmail.com> writes:
> "." gives me ONE number followed by "-4 Stack underflow."...
> So it looks like it doesn't check the stack at all during execution;
> Is that pretty standard behavior?

I think it's best to check before each access during execution, to catch
more errors during testing.  You can have an "optimized" version that
does less checking for code that's believed (heh) to be already
debugged.

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

#43741

On 11/24/15 9:19 PM, Paul Rubin wrote:
> Chris Curl <ccurl609@gmail.com> writes:
>> "." gives me ONE number followed by "-4 Stack underflow."...
>> So it looks like it doesn't check the stack at all during execution;
>> Is that pretty standard behavior?
>
> I think it's best to check before each access during execution, to catch
> more errors during testing.  You can have an "optimized" version that
> does less checking for code that's believed (heh) to be already
> debugged.
>

I disagree. Testing is supposed to be an interactive process. You do not 
write a bunch of definitions and then try executing the highest-level 
one. You try each, in turn, typing appropriate arguments as needed and 
then checking the stack afterwords, testing bottom-up. If you do this 
you will quickly find stack as well as logical problems. I would never 
write a system that checked the stack at every word! Stack checking 
should be performed whenever you're at the command-line level. So, if I 
type:

123 dup .

...it will chech after 123, after dup, and after . (not while executing 
whatever words are called by these.

It only sounds inefficient compared with languages that are 
batch-oriented. In practice, it makes the most efficient use of the 
mind-computer link.

Cheers,
Elizabeth

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

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

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

#43783

"Elizabeth D. Rather" <erather@forth.com> writes:
> I would never write a system that checked the stack at every word!

I don't see why not: you find out about errors sooner, at the cost of
some computer cycles that are almost always essentially free.
> 123 dup .
>
> ...it will chech after 123, after dup, and after . (not while
> executing whatever words are called by these.

What happens if you type dup with an empty stack?

> It only sounds inefficient compared with languages that are
> batch-oriented. In practice, it makes the most efficient use of the
> mind-computer link.

I guess I'm more interested in making the most efficient use of the
mind, rather than the mind-computer combination.  So I want to push as
much work as possible to the computer, even if it makes the computer
side of the combination less efficient.  One reason languages like
Python are so popular (even though they're dog slow compared to Forth)
is that they do a ton of runtime error checking, so finding errors is
quick.

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

#43788

On 11/25/15 11:17 AM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> I would never write a system that checked the stack at every word!
>
> I don't see why not: you find out about errors sooner, at the cost of
> some computer cycles that are almost always essentially free.

No computer cycles are "free". And doubling the cost of something that 
is happening as frequently as stack access in Forth is simply not worth 
it. Actually, we did write a special Forth with buckets of error 
checking for use in classes some years ago. It had the effect of 
tremendously slowing down the learning process, as the students were 
relying on the system error checking instead of thinking about what they 
were doing, so we ditched it.

>> 123 dup .
>>
>> ...it will chech after 123, after dup, and after . (not while
>> executing whatever words are called by these.
>
> What happens if you type dup with an empty stack?

You dup the stack underflow position (which contains a zero). Why would 
you want to do that?

>> It only sounds inefficient compared with languages that are
>> batch-oriented. In practice, it makes the most efficient use of the
>> mind-computer link.
>
> I guess I'm more interested in making the most efficient use of the
> mind, rather than the mind-computer combination.  So I want to push as
> much work as possible to the computer, even if it makes the computer
> side of the combination less efficient.  One reason languages like
> Python are so popular (even though they're dog slow compared to Forth)
> is that they do a ton of runtime error checking, so finding errors is
> quick.

Well, I'm accustomed to working with professional programmers who are 
working on hard projects under deadline pressure. They will do anything 
that they think will improve their efficiency, and I've never heard them 
wish for internal stack checking. It's just not cost-effective. We are 
working mostly with low-end microcontrollers, where cycles count, but 
even on super-fast PCs it has just never proven genuinely helpful.

Cheers,
Elizabeth

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

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

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

#43794

"Elizabeth D. Rather" <erather@forth.com> writes:
> No computer cycles are "free".

Even a dinky MCU runs at millions of cycles per second, and sitting
typing interactively at it generally won't use even 1% of them.
Do you have a way of saving the rest for later?

>  And doubling the cost of something that is happening as frequently as
> stack access in Forth is simply not worth it.

Are there some benchmarks showing the cost doubling?  Obviously it will
cost something but I'd hope it isn't as bad as doubling.  Even if it
does double, so what?  You use 2% of your CPU instead of 1%.

> Actually, we did write a special Forth with buckets of error checking
> for use in classes some years ago. It had the effect of tremendously
> slowing down the learning process

Gforth effectively does such a check (it uses a memory protection trap
instead of a runtime comparison, but it still signals the error where it
happens).  I've found it very helpful.

>> What happens if you type dup with an empty stack?
> You dup the stack underflow position (which contains a zero). Why
> would you want to do that?

It can happen by accident during development.  Obviously it's an error:
so why should the programmer spend her time hunting it down, instead of
having the computer flag it immediately?

> We are working mostly with low-end microcontrollers, where cycles
> count, but even on super-fast PCs it has just never proven genuinely
> helpful.

I haven't written any Forth code so far where I cared in the slightest
how fast it ran-- i.e., a 2x or even 10x slowdown would not have been
noticed.  Even speed-critical and realtime applications tend to be like
that.  There are a few hot spots that have to be optimized carefully,
and the rest of the code should just do whatever is simplest and safest.
And the speed critical parts can usually run slow during debugging,
under simulation if necessary.

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

#43795

On 11/25/15 4:00 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> No computer cycles are "free".
>
> Even a dinky MCU runs at millions of cycles per second, and sitting
> typing interactively at it generally won't use even 1% of them.
> Do you have a way of saving the rest for later?

I certainly don't plan to be developing on a system that is different 
from the one the program is running on. So I'm thinking about the 
finished program's timing.

>>   And doubling the cost of something that is happening as frequently as
>> stack access in Forth is simply not worth it.
>
> Are there some benchmarks showing the cost doubling?  Obviously it will
> cost something but I'd hope it isn't as bad as doubling.  Even if it
> does double, so what?  You use 2% of your CPU instead of 1%.

I don't know what kinds of programs you write, but a lot of the 
applications we work on have performance targets and, as I said earlier, 
run on pretty small/slow processors. In any case, the cost of comparing 
two addresses and taking a possible branch surely exceeds the cost of a 
push or a pop on most systems.

>> Actually, we did write a special Forth with buckets of error checking
>> for use in classes some years ago. It had the effect of tremendously
>> slowing down the learning process
>
> Gforth effectively does such a check (it uses a memory protection trap
> instead of a runtime comparison, but it still signals the error where it
> happens).  I've found it very helpful.
>
>>> What happens if you type dup with an empty stack?
>> You dup the stack underflow position (which contains a zero). Why
>> would you want to do that?
>
> It can happen by accident during development.  Obviously it's an error:
> so why should the programmer spend her time hunting it down, instead of
> having the computer flag it immediately?

Because I'll find it in the length of time it takes you to respond to 
that error message.

>> We are working mostly with low-end microcontrollers, where cycles
>> count, but even on super-fast PCs it has just never proven genuinely
>> helpful.
>
> I haven't written any Forth code so far where I cared in the slightest
> how fast it ran-- i.e., a 2x or even 10x slowdown would not have been
> noticed.  Even speed-critical and realtime applications tend to be like
> that.  There are a few hot spots that have to be optimized carefully,
> and the rest of the code should just do whatever is simplest and safest.
> And the speed critical parts can usually run slow during debugging,
> under simulation if necessary.

Well, I like everything to run fast all the time. We've heard too many 
times, "Oh, you can't use Forth for that, it's too slow!" It's nice to 
be able to show people it's performing as well as whatever they're 
familiar with. Even compilation: if the compile takes over a second 
that's too long, and for nice fast compiles you want everything to be 
fast. I also hate simulation, because simulators are never perfect, and 
it's an extra step to have to figure out what's different when you get 
on the real hardware.

Cheers,
Elizabeth

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

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

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

#43803

"Elizabeth D. Rather" <erather@forth.com> writes:
> I certainly don't plan to be developing on a system that is different
> from the one the program is running on. So I'm thinking about the
> finished program's timing.

Interesting.  I always prefer to develop on a workstation if possible.
Some machine dependent things of course have to be deveoped on the
target, but even with those, workstation-side emulators can help.

> I don't know what kinds of programs you write, but a lot of the
> applications we work on have performance targets 

Even for such programs though, there are usually a few tight loops
where the performance critical stuff is.  The initializations,
terminal i/o, etc. can be quite unoptimized and still be fine.

> Because I'll find it in the length of time it takes you to respond to
> that error message.

Eh?  First you have to see there was an error, then you have to
find there was an underflow at the dup, then you have to figure out
what caused the underflow.  With an error check at the dup, I get
to skip the first two steps and then we're in exactly the same place.

It's even worse if you use a word like ?dup where you think there might
be a legitimate zero on the stack, but the stack is actually empty.  The
?dup puts a zero there and the program keeps going.  Even with that very
fine grained testing it still sounds likely to create confusion.

> Well, I like everything to run fast all the time. We've heard too many
> times, "Oh, you can't use Forth for that, it's too slow!" 

I just did some timings on a Scaleway arm7, simple loops counting to 1e8.

Gforth 0.7.2 (non-fast, from Debian 8 repo) took 4.4 seconds
Gforth-fast took 3.4 seconds
Mecrisp 2.1.6 took less than 1 second
Python, the language I use all day, took 1 minute 16 seconds.

So Forth is beating Python by 15x to maybe 100x.  Despite this, the slow
speed of Python is usually not a problem for my apps.  They spend most
of their time waiting for network i/o, or call libraries (generally
written in C) for their computation intensive parts.  If the program is
still too slow (that happens sometimes) I can write the slow parts in
C++ or some other language while keeping the non-speed-critical control
and coordination parts in Python, which is much more convenient to code
in.  It's a good trade.

I'm sure that any reasonable Forth even with those stack checks will
still be much faster than Python.  I also know the relative market size
of the two languages, so Python must be doing something right, or else
people usually don't care that much about the interpreter speed.

> It's nice to be able to show people it's performing as well as
> whatever they're familiar with.

Sure, so compile in optimized mode that turns off the checks.

> I also hate simulation, because simulators are never perfect, and it's
> an extra step to have to figure out what's different when you get on
> the real hardware.

I generally find simulators to be worth the bother, because you then
don't have to muck with the actual hardware--which can be hard to get
your hands on, requires messy setup, needs manual operations so it's
hard to automate testing, etc.  But I guess it depends on what you're
doing.

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

#43807

On 11/25/15 9:05 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> I certainly don't plan to be developing on a system that is different
>> from the one the program is running on. So I'm thinking about the
>> finished program's timing.
>
> Interesting.  I always prefer to develop on a workstation if possible.
> Some machine dependent things of course have to be deveoped on the
> target, but even with those, workstation-side emulators can help.
>
>> I don't know what kinds of programs you write, but a lot of the
>> applications we work on have performance targets
>
> Even for such programs though, there are usually a few tight loops
> where the performance critical stuff is.  The initializations,
> terminal i/o, etc. can be quite unoptimized and still be fine.
>
>> Because I'll find it in the length of time it takes you to respond to
>> that error message.
>
> Eh?  First you have to see there was an error, then you have to
> find there was an underflow at the dup, then you have to figure out
> what caused the underflow.  With an error check at the dup, I get
> to skip the first two steps and then we're in exactly the same place.
>
> It's even worse if you use a word like ?dup where you think there might
> be a legitimate zero on the stack, but the stack is actually empty.  The
> ?dup puts a zero there and the program keeps going.  Even with that very
> fine grained testing it still sounds likely to create confusion.

I guess those aren't the kinds of mistakes experienced programmers make. 
Conceptually, you're right, but it just doesn't happen that way in my 
experience.

>> Well, I like everything to run fast all the time. We've heard too many
>> times, "Oh, you can't use Forth for that, it's too slow!"
>
> I just did some timings on a Scaleway arm7, simple loops counting to 1e8.
>
> Gforth 0.7.2 (non-fast, from Debian 8 repo) took 4.4 seconds
> Gforth-fast took 3.4 seconds
> Mecrisp 2.1.6 took less than 1 second
> Python, the language I use all day, took 1 minute 16 seconds.
>
> So Forth is beating Python by 15x to maybe 100x.  Despite this, the slow
> speed of Python is usually not a problem for my apps.  They spend most
> of their time waiting for network i/o, or call libraries (generally
> written in C) for their computation intensive parts.  If the program is
> still too slow (that happens sometimes) I can write the slow parts in
> C++ or some other language while keeping the non-speed-critical control
> and coordination parts in Python, which is much more convenient to code
> in.  It's a good trade.

We do different kinds of applications. Mostly equipment control & data 
acquisition, where data rates are pretty high and response times are 
critical. We compete against C and assembler, not Python.

> I'm sure that any reasonable Forth even with those stack checks will
> still be much faster than Python.  I also know the relative market size
> of the two languages, so Python must be doing something right, or else
> people usually don't care that much about the interpreter speed.

See above.

>> It's nice to be able to show people it's performing as well as
>> whatever they're familiar with.
>
> Sure, so compile in optimized mode that turns off the checks.

Having multiple modes is asking for trouble.

>> I also hate simulation, because simulators are never perfect, and it's
>> an extra step to have to figure out what's different when you get on
>> the real hardware.
>
> I generally find simulators to be worth the bother, because you then
> don't have to muck with the actual hardware--which can be hard to get
> your hands on, requires messy setup, needs manual operations so it's
> hard to automate testing, etc.  But I guess it depends on what you're
> doing.

That's not been our experience. We're usually called in about the time 
the hardware's ready for the first time, and help debug it.

Cheers,
Elizabeth

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

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

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

#43811

On 26/11/2015 09:38, Elizabeth D. Rather wrote:
> On 11/25/15 9:05 PM, Paul Rubin wrote:

>> It's even worse if you use a word like ?dup where you think there might
>> be a legitimate zero on the stack, but the stack is actually empty.  The
>> ?dup puts a zero there and the program keeps going.  Even with that very
>> fine grained testing it still sounds likely to create confusion.
> 
> I guess those aren't the kinds of mistakes experienced programmers make.
> Conceptually, you're right, but it just doesn't happen that way in my
> experience.

Really?  I guess you have only worked with android-genius programmers then.

My experience is that even the very best make mistakes.  And what's
worse, the better one is the more subtle the mistake...

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

#43815

On 11/25/15 9:49 PM, Ron Aaron wrote:
>
>
> On 26/11/2015 09:38, Elizabeth D. Rather wrote:
>> On 11/25/15 9:05 PM, Paul Rubin wrote:
>
>>> It's even worse if you use a word like ?dup where you think there might
>>> be a legitimate zero on the stack, but the stack is actually empty.  The
>>> ?dup puts a zero there and the program keeps going.  Even with that very
>>> fine grained testing it still sounds likely to create confusion.
>>
>> I guess those aren't the kinds of mistakes experienced programmers make.
>> Conceptually, you're right, but it just doesn't happen that way in my
>> experience.
>
> Really?  I guess you have only worked with android-genius programmers then.

No android anything. Experienced Forth programmers :-)

> My experience is that even the very best make mistakes.  And what's
> worse, the better one is the more subtle the mistake...

Oh, yes, we make mistakes. Just not the ones that would be caught by 
this kind of error checking.

Cheers,
Elizabeth

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

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

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

#43830

Ron Aaron <rambamist@gmail.com> writes:
>
>
>On 26/11/2015 09:38, Elizabeth D. Rather wrote:
>> On 11/25/15 9:05 PM, Paul Rubin wrote:
>
>>> It's even worse if you use a word like ?dup where you think there might
>>> be a legitimate zero on the stack, but the stack is actually empty.  The
>>> ?dup puts a zero there and the program keeps going.  Even with that very
>>> fine grained testing it still sounds likely to create confusion.
>> 
>> I guess those aren't the kinds of mistakes experienced programmers make.
>> Conceptually, you're right, but it just doesn't happen that way in my
>> experience.
>
>Really?  I guess you have only worked with android-genius programmers then.
>
>My experience is that even the very best make mistakes.

Yes, but programmers adapt.  When the environment protects them from
certain mistakes, they program differently than when it does not.  My
favourite quote of Bjarne Stroustroup (creator of C++) is:

|As programmers learned C with Classes or C++, they lost the ability to
|quickly find the ``silly errors'' that creep into C programs through
|the lack of checking. Further, they failed to take the precautions
|against such silly errors that good C programmers take as a matter of
|course. After all, ``such errors don't happen in C with Classes.''
|Thus, as the frequency of run-time errors caused by uncaught argument
|type errors goes down, their seriousness and the time needed to find
|them goes up.

Conversely, when people program in a language with less checking, they
test earlier and more, as Elizabeth Rather has written, and take other
precautions, such as more factoring, which makes testing easier.

>And what's
>worse, the better one is the more subtle the mistake...

Sure, there will always be mistakes that neither the environment nor
the programming practices that one develops agains frequent types of
errors will catch quickly.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43981

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> My favourite quote of Bjarne Stroustroup (creator of C++) is:
> |As programmers learned C with Classes or C++, they lost the ability to
> |quickly find the ``silly errors'' that creep into C programs through
> |the lack of checking. 

RMS used to say that when he automated some task with software and then
lost the ability to do it manually, that told him that the task must
have been a significant cognitive load, so automating it improved his
productivity by freeing up that much of his mental capacity for other
things.  He's told this story multiple times regarding the automatic
parenthesis balancing in Emacs.  He apparently lost the ability to count
parentheses while coding Lisp, once he programmed Emacs to do it.

> |Thus, as the frequency of run-time errors caused by uncaught argument
> |type errors goes down, their seriousness and the time needed to find
> |them goes up.

We could say that C++ is badly designed because it makes such errors
infrequent rather than impossible.  I know I've made those errors in C++
code and been surprised and annoyed that the compiler didn't catch them.
I do find myself using C++ in preference to C these days.  I don't know
if I've gotten worse at finding the errors while coding, though it's
possible.

> Conversely, when people program in a language with less checking, they
> test earlier and more, as Elizabeth Rather has written, and take other
> precautions, such as more factoring, which makes testing easier.

You're saying that when the language does less checking, developers
spend more time guarding against and testing for errors that a
differently designed language could find instantly and automatically.
Is that supposed to weigh in favor of the automatic checks, or against
them?

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

#43997

On Monday, November 30, 2015 at 2:00:23 PM UTC-7, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> > My favourite quote of Bjarne Stroustroup (creator of C++) is:
> > |As programmers learned C with Classes or C++, they lost the ability to
> > |quickly find the ``silly errors'' that creep into C programs through
> > |the lack of checking. 
> 
> RMS used to say that when he automated some task with software and then
> lost the ability to do it manually, that told him that the task must
> have been a significant cognitive load, so automating it improved his
> productivity by freeing up that much of his mental capacity for other
> things.  He's told this story multiple times regarding the automatic
> parenthesis balancing in Emacs.  He apparently lost the ability to count
> parentheses while coding Lisp, once he programmed Emacs to do it.

This whole thread is getting dumb. Obviously, error checking is good. No programmer would argue against it. Anton Ertl is just arguing this point to support Elizabeth Rather, not because he actually believes it.

Anton Ertl says:
-------------------------------------------------------------------------
Conversely, when people program in a language with less checking, they 
test earlier and more, as Elizabeth Rather has written, and take other 
precautions, such as more factoring, which makes testing easier. 
-------------------------------------------------------------------------
How does he know that? Is he a psychologist? This is nonsense!

Having error-checking working in the background doesn't magically turn the programmer into an idiot who is no longer able to write good-style programs and/or to find bugs. I'm not going to say: "Well, I'm using a compiler that checks for stack underflow, so now I can write programs with 100-line functions just like the C programmers do. I've been waiting all these years for the opportunity!" RMS's point was that the parenthesis-matching in EMACS freed up his brain for more important things, not that he somehow lost the ability to count. He would have still been able to program in Lisp using VIM although he would have programmed slower and he would have been libel to more mistakes due to the distraction of dealing with VIM. Obviously, the fewer distractions that a programmer has, the better able he will be to focus his mind on the important aspects of programming. 

Upgrading from a stick-shift car to an automatic-transmission car doesn't make a person a bad driver and cause him to drive into telephone poles --- if anything, his driving will improve because there are fewer distractions.

This argument against error-checking reminds me of how some people believe that the saber-tooth tiger's saber teeth got longer and longer (evolution out of control!) until the tiger was no longer able to eat and so it starved to death, and that is why it is extinct. Obviously not true!

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

#44006

On Monday, November 30, 2015 at 11:54:58 PM UTC-6, hughag...@gmail.com wrote:
> This whole thread is getting dumb. Obviously, error checking is
> good. No programmer would argue against it.

If a long-running process has a slightly unbalanced stack, then
without stack checking it will eventually crash.  With stack checking
it'll crash more reliably.  My webserver had a couple of bugs that
left an extra item on the stack, and this caused a crash after 90k
requests or so.  If your process is *not* long-running, then it may
end satisfactorily without ever crashing, with or without stack
checking, and you would only notice that something's wrong if you
checked the stack at the end.

So this 'error checking' is almost worthless.  If it were at all
expensive to implement, would no programmer argue against it?  Rather
than ask for a feature that slightly changes how my buggy program
eventually misbehaves, I'd rather have a debugging mode that helped
me expensively remove the bug, and then some tests to be sure that I
had no need to worry about the stack on deployment.

That is, I'd rather have a good way to check the stack everywhere
along the stack, to check a word's usage of the stack, rather than
only check one extreme end or the other.


-- Julian

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

#44009

marți, 1 decembrie 2015, 14:24:38 UTC+2, Julian Fondren a scris:
> On Monday, November 30, 2015 at 11:54:58 PM UTC-6, hughag...@gmail.com wrote:
> > This whole thread is getting dumb. Obviously, error checking is
> > good. No programmer would argue against it.
> 
> If a long-running process has a slightly unbalanced stack, then
> without stack checking it will eventually crash.  With stack checking
> it'll crash more reliably.  My webserver had a couple of bugs that
> left an extra item on the stack, and this caused a crash after 90k
> requests or so.  If your process is *not* long-running, then it may
> end satisfactorily without ever crashing, with or without stack
> checking, and you would only notice that something's wrong if you
> checked the stack at the end.
> 
> So this 'error checking' is almost worthless.  If it were at all
> expensive to implement, would no programmer argue against it?  Rather
> than ask for a feature that slightly changes how my buggy program
> eventually misbehaves, I'd rather have a debugging mode that helped
> me expensively remove the bug, and then some tests to be sure that I
> had no need to worry about the stack on deployment.
> 
> That is, I'd rather have a good way to check the stack everywhere
> along the stack, to check a word's usage of the stack, rather than
> only check one extreme end or the other.
> 
> 
> -- Julian

What do you mean? Checking the stack programatically in the application?
For example, save the depth before a request, get the depth after it and
make the difference. If it not as expected, bingo!
It is interesting, but may be or may be not practical, depending on the
application.

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

#44012

On Tuesday, December 1, 2015 at 7:07:32 AM UTC-6, Raimond Dragomir wrote:
> marți, 1 decembrie 2015, 14:24:38 UTC+2, Julian Fondren a scris:
> > On Monday, November 30, 2015 at 11:54:58 PM UTC-6, hughag...@gmail.com wrote:
> > > This whole thread is getting dumb. Obviously, error checking is
> > > good. No programmer would argue against it.
> > 
> > If a long-running process has a slightly unbalanced stack, then
> > without stack checking it will eventually crash.  With stack checking
> > it'll crash more reliably.  My webserver had a couple of bugs that
> > left an extra item on the stack, and this caused a crash after 90k
> > requests or so.  If your process is *not* long-running, then it may
> > end satisfactorily without ever crashing, with or without stack
> > checking, and you would only notice that something's wrong if you
> > checked the stack at the end.
> > 
> > So this 'error checking' is almost worthless.  If it were at all
> > expensive to implement, would no programmer argue against it?  Rather
> > than ask for a feature that slightly changes how my buggy program
> > eventually misbehaves, I'd rather have a debugging mode that helped
> > me expensively remove the bug, and then some tests to be sure that I
> > had no need to worry about the stack on deployment.
> > 
> > That is, I'd rather have a good way to check the stack everywhere
> > along the stack, to check a word's usage of the stack, rather than
> > only check one extreme end or the other.
> > 
> > 
> > -- Julian
> 
> What do you mean? Checking the stack programatically in the application?
> For example, save the depth before a request, get the depth after it and
> make the difference. If it not as expected, bingo!
> It is interesting, but may be or may be not practical, depending on the
> application.

Yep.  Executable stack comments would be nice.  So far I've handled such
bugs just by littering code with commands to print the stack, and with
stuff like saving DEPTH at the beginning of a word and checking the
difference at exits.

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web