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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#43976

On 11/29/15 11:48 PM, minforth@arcor.de wrote:
>> This is where user testing comes in handy. If you're in business to make money, you find out the minimum that will make your users truly happy, then you do that. There's little point in optimizing code when the users don't notice either way.
>>
>> That said, it's of course also true that readability and maintainability is also very important. It's hard to go wrong "optimizing" them.
>
> In most cases I leaft full runtime checking ON. The overhead was mostly negligible.
>
> Why? You lose customer confidence and money with every bug that appears in the production system.
>
> And the longer it takes to isolate and repair it, the worse it gets. This outweighs practically any performance maximization, of which so many Forthers seem to be fond.

The way to prevent that is disciplined programming and test procedures 
before your program goes to "production" status. The kinds of errors 
that compiler checking can detect are straightforward to find in 
testing. The only really dangerous and hard-to-detect bugs are logical 
mistakes, which your compiler cannot detect.

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]

#43924

On Friday, November 27, 2015 at 7:25:31 AM UTC-7, Alfred Singlestone wrote:
> On Thursday, November 26, 2015 at 2:49:07 AM UTC-5, Ron Aaron wrote:
> > 
> > My experience is that even the very best make mistakes.  And what's
> > worse, the better one is the more subtle the mistake...
> 
> The guy who knows our system the best is a literal genius who's been a programmer for forty years and has an acute grasp of the nuances of small changes to our huge product. Even so, he's known for forgetting to change the sense of compares after copying and pasting code. Why? Because he is unfortunately a human being saddled with a human brain, and is therefore prone to make the kind of mistakes that we make.
> 
> Allow, but don't force, the computer to do the kind of checking that it's good at. In this situation, maybe do stack checking if a debug flag is on, and not if not. Never assume that users of your product, or your programmers, can't and won't make rookie errors. If you do, you will be committing a rookie error yourself. You will suffer Consequences, and I will have no sympathy.

I agree with this. Everybody makes dumb mistakes occasionally, so it is good if these get caught quickly and a meaningful error message gets sent. Turn off the checking for the compile of production code if the extra boost in speed is noticeable. This seems abundantly obvious --- I'm not aware of any programmer who would disagree.

Note that "error message" is a euphemism. An error is when your code is theoretically correct but provided a wrong answer due to shortcomings of the system. For example, a stack overflow is an error (the system provided too small of a stack), but a stack underflow is a mistake (you removed more data from the stack than you put on the stack). As another example, if your system only provided single-precision IEEE-754 (FICL, for example) and your result was mush, then that is an error, but if your result was mush because you got your arithmetic tangled up, then that is a mistake on your part. The word "error" has been totally corrupted in our society --- we should call it a "mistake message" in most cases.

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

#43812

"Elizabeth D. Rather" <erather@forth.com> writes:
> 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.

I know I've made mistakes where a built-in word had a different stack
effect from what I thought it had, or where I typed + instead of f+ and
used the wrong stack.  But yeah, that probably gets better with
practice.

> 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'd be interested in seeing an application like that sometime.  What I'm
used to in control systems is there's a bunch of configuration and setup
code, there's a user interface of some kind, there's some logging,
there's internal monitoring and failure recovery code, etc. etc., and oh
yes, there's that all-important i/o loop doing the actual data mangling.
That loop uses 99% of the CPU cycles but it's 1% of the code.  The rest
is not speed-critical at all.  In the old days code space was also
constrained, but these days that's less of an issue, even on MCU's.

>> Sure, so compile in optimized mode that turns off the checks.
> Having multiple modes is asking for trouble.

I don't find this at all.  Are we in the same world?  GCC generates up
to 3x faster code with optimization on, but the compile is slower and
it's harder to debug (because there's no longer a simple correspondence
between source lines and output code).  So it's completely normal to
develop/debug with optimization off, then turn it on for real builds (of
course you have to test those thoroughly).  The optimizer is very
complex and people sometimes worry about it introducing bugs, but I've
never heard of bugs coming from turning the optimizer OFF.

>> [simulator]
> 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.

Sure, to debug the hardware, you need the hardware, I can understand
that.  But lots of the code shouldn't be too hardware dependent.  If
your application needs you to write a math routine (no i/o, no special
registers etc), you should generally be able to develop it on a PC and
then transplant it to the target.

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

#43816

On 11/25/15 10:03 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> 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.
>
> I know I've made mistakes where a built-in word had a different stack
> effect from what I thought it had, or where I typed + instead of f+ and
> used the wrong stack.  But yeah, that probably gets better with
> practice.
>
>> 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'd be interested in seeing an application like that sometime.  What I'm
> used to in control systems is there's a bunch of configuration and setup
> code, there's a user interface of some kind, there's some logging,
> there's internal monitoring and failure recovery code, etc. etc., and oh
> yes, there's that all-important i/o loop doing the actual data mangling.
> That loop uses 99% of the CPU cycles but it's 1% of the code.  The rest
> is not speed-critical at all.  In the old days code space was also
> constrained, but these days that's less of an issue, even on MCU's.

Yeah, it's certainly true that most of the time is spend in a small 
fraction of the code, but if you put in all those stack checks, that 
inflicts everything.

>>> Sure, so compile in optimized mode that turns off the checks.
>> Having multiple modes is asking for trouble.
>
> I don't find this at all.  Are we in the same world?  GCC generates up
> to 3x faster code with optimization on, but the compile is slower and
> it's harder to debug (because there's no longer a simple correspondence
> between source lines and output code).  So it's completely normal to
> develop/debug with optimization off, then turn it on for real builds (of
> course you have to test those thoroughly).  The optimizer is very
> complex and people sometimes worry about it introducing bugs, but I've
> never heard of bugs coming from turning the optimizer OFF.

We always run with optimizing on except for the very rare occasions when 
we turn it off for a particular span of code for some very specific 
reason. And compilation is blinding fast (it's very rare for compilation 
of a full application to take >1sec). This is not like GCC at all.

>>> [simulator]
>> 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.
>
> Sure, to debug the hardware, you need the hardware, I can understand
> that.  But lots of the code shouldn't be too hardware dependent.  If
> your application needs you to write a math routine (no i/o, no special
> registers etc), you should generally be able to develop it on a PC and
> then transplant it to the target.

We have a lot of common control system comms and math in our "back 
pockets", and generally find there's not a whole lot to do until the 
hardware is ready. Some of the user interface, maybe.

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]

#43839

On Thursday, November 26, 2015 at 12:38:50 AM UTC-7, 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.

Forth Inc. sold me SwiftForth-v2 for over $400 and it was a bug-ridden mess --- there were so many bugs that it couldn't be used for commercial programming in which programs have to be written on deadline --- it was just a toy compiler for people who have a lot of time to work around the bugs and who don't care about efficiency at all.

For example, the whole system would crash when (LOCAL) was used. This is not a subtle bug that slipped past the testing --- if any testing at all had been done, you would have noticed that the system crashes --- the truth is that you shipped SwiftForth-v2 to your customers without any testing whatsoever. Then you refused to upgrade your customers to v3 that has this bug fixed; you demanded $300 for the upgrade. This is just a scam!

All this talk about "experienced programmers" at Forth Inc. is just hot air. You've never written a computer program in your life. Forth Inc. employees are sales people, not programmers. Forth Inc. ships software without any testing at all.

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

#43797

Le jeudi 26 novembre 2015 03:00:27 UTC+1, Paul Rubin a écrit :
> "Elizabeth D. Rather" <erather@forth.com> writes:
> 
> >  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%.
> 

Hi,

Oforth default behavior is to generate checks for data stack overflow 
and underflow (but not on all ds access).

Using --O command line option, those checks are not generated.

I have never noticed a difference in term of performance, at least on X86
processors. X86 optimisations (pipeline, superscalar, ...) makes those
tests almost free. Perhap's not the same on other CPU...

--O command line option is still there for code size optimisation.

Franck

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

#43862

On Wednesday, November 25, 2015 at 6:58:08 PM UTC-5, Elizabeth D. Rather wrote:
> On 11/25/15 11:17 AM, Paul Rubin wrote:
>> 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?

Because I am QA, and my job and intention is to break the product, or to reveal deviations from desired behavior, or to reveal questionable behavior that no one has yet considered.

Or maybe I didn't want to do it, didn't mean to do it, but I did it anyway. It'd be nice to know that if I make such a mistake (mis-stack?), my session isn't going to have PTSD symptoms or get a signal and terminate.

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

#43747

On Wed, 25 Nov 2015 01:31:28 -0500, Chris Curl <ccurl609@gmail.com> wrote:

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

Currently, I check on every push and pop to the data and
return stacks.  This adds a bit of extra overhead for C.

I've been thinking about checking far less often, but was
worried about possible underflows and overflows not being
detected or being detected too late.

Even if I do check less frequently, I intend to keep the
check for underflow of the data stack for every pop.
I think is the most likely type of frequent underflow.

IIRC, the return stack shouldn't underflow for normal
interpreter operation.  I.e., it requires user abuse of
the return stack or incorrect manipulation of it.

Overflow of either stack is likely far less common too.
I have very small stacks and haven't come close to an
overflow yet.  So, I think those can be safely checked
far less frequently.  You can check for a stack value
approaching overflow, say within 10 of the limit, to
prevent an actual overflow.


Rod Pemberton


-- 
How to kill Facebook.  Tell a bunch of fourth graders that
only old people use Facebook.  Wait eight years.

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

#43751

In the past i had 2 forth
One for debugging :check the stack before, after...
And one other for final applications, only check after words execution (in interpretation).

now i only use the second, and check my words step by step for debugging.

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

#43754

Chris Curl <ccurl609@gmail.com> writes:
>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?

Many systems do it this way, yes.  However, Gforth's debugging engine
"gforth" reports the error earlier (on nice operating systems):

. 
:1: Stack underflow
>>>.<<<
Backtrace:
$7FFFF69F1708 dup 
$7FFFF69F2E30 s>d 
. . 
:2: Stack underflow
>>>.<<< .
Backtrace:
$7FFFF69F1708 dup 
$7FFFF69F2E30 s>d 
: sss . . . ; sss 
:3: Stack underflow
: sss . . . ; >>>sss<<<
Backtrace:
$7FFFF69F1708 dup 
$7FFFF69F2E30 s>d 
$7FFFF6A44308 . 
: xxx sss sss ; xxx 
:4: Stack underflow
: xxx sss sss ; >>>xxx<<<
Backtrace:
$7FFFF69F1708 dup 
$7FFFF69F2E30 s>d 
$7FFFF6A44308 . 
$7FFFF6A44368 sss 
sss sss 
:5: Stack underflow
>>>sss<<< sss
Backtrace:
$7FFFF69F1708 dup 
$7FFFF69F2E30 s>d 
$7FFFF6A44308 .

As you can see the error is always caught in the DUP called by S>D
called by ".".

How is that implemented?  There is an unmapped page where the memory
location for the stack item below the bottom of the stack would lie,
so accessing that memory location causes a segmentation violation in
the OS, and when the access is to a place close to the bottom of the
data stack, Gforth translates this into a "-4 throw" (stack
underflow).  So this does not cost any checks at run-time.

There is a cost, though: For accurate error reporting the debugging
engine always stores the IP and the RP in memory.  Also, the debugging
engine keeps all stack items in memory (no stack caching in
registers), and does not use static superinstructions: Stack caching
occasionally loads memory cells below the stack bottom into a register
(when the stack is empty), and for static superinstructions there is
only one IP to report for a sequence of primitives.

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

#43761

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Gforth's debugging engine "gforth" reports the error earlier...
> How is that implemented?  There is an unmapped page ...

Interesting--for some reason I thought only gforth-fast did that
and gforth(non-fast) actually had a dynamic check.  How badly would
an explicit check slow things down?  I presume it's been tried.

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

#43766

Paul Rubin wrote:

> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Gforth's debugging engine "gforth" reports the error earlier...
>> How is that implemented?  There is an unmapped page ...
> 
> Interesting--for some reason I thought only gforth-fast did that
> and gforth(non-fast) actually had a dynamic check.  How badly would
> an explicit check slow things down?  I presume it's been tried.

No, we haven't tried, but we would have to compare sp against sp0+some 
offset for each primitive with input on the stack.  sp0 isn't in a register 
now, it would have to go to a register to be fast.

On the other hand, the unmapped page is really "cost-free"; we do it only on 
CPUs with MMU, though.  All OSes on these CPUs are now friendly enough.  We 
do it on the floating point stack, too, but not on return stack and locals 
stack, to avoid aliasing problems.  Early versions of Gforth, when CPUs with 
direct mapped non-associative cache were still popular even had a 
displacement for the floating point stack, so that all four stacks didn't 
alias in normal operating conditions.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#43777

Bernd Paysan <bernd.paysan@gmx.de> writes:
> On the other hand, the unmapped page is really "cost-free"; we do it
> only on CPUs with MMU, though.  All OSes on these CPUs are now
> friendly enough.

It also might work on some of the current Cortex M's--they don't have
MMU's per se, but they have some memory segmention to protect tasks from
each other.  I don't know the details of this so I'm not sure if it's
really doable.

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

#43769

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Gforth's debugging engine "gforth" reports the error earlier...
>> How is that implemented?  There is an unmapped page ...
>
>Interesting--for some reason I thought only gforth-fast did that
>and gforth(non-fast) actually had a dynamic check.  How badly would
>an explicit check slow things down?  I presume it's been tried.

We have not tried it, as we have a working (well, on decent OSs)
solution.

I have thought about doing extra loads in code that use stack caching
in order to produce an exception near the place of the logical
underflow; one could also do it with branches, but I expect that loads
are cheaper.  If you have an analytic compiler, you probably can
optimize many of the extra loads away.

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

#43784

Bugs related to a lack of data on the stack are easy to fix.
Bugs related to bad arguments on the stack are harder ...

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

#43904

I like the idea of an assembler switch to enable or disable run-time stack checking. I will go with that.

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

#43911

On Saturday, November 28, 2015 at 12:29:28 PM UTC-5, Chris Curl wrote:
> I like the idea of an assembler switch to enable or disable run-time stack checking. I will go with that.

You can do the same thing with extensive tracing, too. I use another flag for that.

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

#44013

So... DUP (for example) had to control if :
- the stack is not empty
- the stack is not full
- the data is not a double length
- the coffee is ready... =O)

 

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

#44024

Are there any test suites to see how close a Forth implementation is 
to the ANS Standard? I would be surprised if mine ever got that far, 
but something like that seems like a useful thing.

Might someone have a Forth bootstrap script that assumes (some number 
of) primitives are already defined? Ideally, such a script could build 
a working Forth by building on the primitives that are hand coded 
into the system.

Then an implementer could focus on the base system and use the script
to get off the ground.

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

#44034

On 12/1/15 12:05 PM, Chris Curl wrote:
> Are there any test suites to see how close a Forth implementation is
> to the ANS Standard? I would be surprised if mine ever got that far,
> but something like that seems like a useful thing.
>
> Might someone have a Forth bootstrap script that assumes (some number
> of) primitives are already defined? Ideally, such a script could build
> a working Forth by building on the primitives that are hand coded
> into the system.
>
> Then an implementer could focus on the base system and use the script
> to get off the ground.
>

Yes. There was a test suite written for Forth94, and the latest 
incarnation, testing Forth 2012, is being discussed just a few threads 
down: Ann: ANS/FORTH 2012 test suite update.

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]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web