bugGforth - Bugs: bug #57741, Strange begin drop again ;

 
 

bug #57741: Strange begin drop again ;

Submitted by:  Julián Albo <notfound>
Submitted on:  Tue 04 Feb 2020 04:25:17 PM UTC  
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  Anton Ertl <anton>
Open/Closed:  Closed

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 05 Feb 2020 06:56:14 AM UTC, comment #5: 

fixed in the git head

Anton Ertl <anton>
Project AdministratorIn charge of this item.
Tue 04 Feb 2020 06:55:02 PM UTC, comment #4: 

comment #3:

> Ok, I'll fix it.  2DROP, FDROP and RDROP are also relevant, anything else?


2RDROP. All LP+ variants.

Bernd Paysan <paysan>
Project Administrator
Tue 04 Feb 2020 06:49:30 PM UTC, comment #3: 

Ok, I'll fix it.  2DROP, FDROP and RDROP are also relevant, anything else?

Anton Ertl <anton>
Project AdministratorIn charge of this item.
Tue 04 Feb 2020 06:42:24 PM UTC, comment #2: 

comment #1:

> We could fix this by adding a memory access in DROP (and some other words), but I am not sure if this is worth the effort and the slowdown.


With the debugging engine (gforth), it's probably worth it.  We don't do TOS caching there only to get precise stack empty traps, and it hurts performance more than an unused read in DROP.

Bernd Paysan <paysan>
Project Administrator
Tue 04 Feb 2020 04:38:13 PM UTC, comment #1: 

The gforth engine (without stack caching; for gforth-fast NIP would have the same effect as DROP for gforth) does not try to access the stack when DROPping.  In the usual case the stack underflow is discovered in the first word afterwards that accesses memory (e.g., because it actually does something with the stack item, or because it tries to push something), which is usually pretty soon.  Your example is one of the rare cases where this does not happen.  We could fix this by adding a memory access in DROP (and some other words), but I am not sure if this is worth the effort and the slowdown.

Anton Ertl <anton>
Project AdministratorIn charge of this item.
Tue 04 Feb 2020 04:25:17 PM UTC, original submission:  

I was trying to generate a stack underflow exception for some testing of CATCH, and found this:

: a begin drop again ;
' a catch .

Does not return to interactive mode, looks like it's trapped in an infinite loop.

But this

: a begin 1 drop drop again ;
' a catch .

Prints -4 as expected.

Using gforth 0.7.3 from the Debian 10 ia64 package.

Julián Albo <notfound>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by paysan (Posted a comment)
  • -email is unavailable- added by anton (Posted a comment)
  • -email is unavailable- added by notfound (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-05 anton StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2020-02-04 anton StatusNone => Confirmed
        Assigned toNone => anton

    Back to the top


    Powered by Savane 3.5