Author Topic: more bugs..  (Read 9466 times)

0 Members and 1 Guest are viewing this topic.

edcronos

  • Guest
Re: more bugs..
« Reply #15 on: January 03, 2018, 10:12:31 PM »
yes I like it I use to get out of nested loops
but also have some not-so-noble uses as say the gotophobics

despite the non-need of usage nowadays, I think gosub can save some processing cycles in place of function calls.
at least in vba when I took the gosub and added functions it got remarkably slower, I even preferred to put the command lines inside the macro itself repeating everything inside the loops


Charles Pegge

  • Guest
Re: more bugs..
« Reply #16 on: January 04, 2018, 04:32:36 AM »

gosub is very efficient. It is almost identical to an assembler call, and does not have the prolog and epilog code required by functions. It should always be available in a Basic compiler.

JRS

  • Guest
Re: more bugs..
« Reply #17 on: January 05, 2018, 12:28:03 PM »
Does O2 have a POP like keyword to exit a GOSUB without a RET?

edcronos

  • Guest
Re: more bugs..
« Reply #18 on: January 05, 2018, 01:24:27 PM »
but gosub is to function as an internal function, and does every fuction have to have an end function or not?

gosub as well as goto is very frowned upon, maybe a lot more than goto
I find it useful in constructions when you have many nested instructions because the editor does not close pieces, but as soon as I remove the gosub

or when you do not want to create a function that will not be useful outside of that macro and besides having multiple calls you have to deal with many variables

as I said so I started vba I did not know what was functions so I used gosub,
in something like this:
Code: [Select]
     For w = 1 To k
          'Origem --( Leitura )--
          If Op = 0 Then GoSub OCoL: If T = 1 Then T = 0: GoSub OLin
          If Op = 1 Then GoSub OLin: If T = 1 Then T = 0: GoSub OCoL
          Ddo = Cells(Loi, Coi).Value2

          'Destino --(Escrita )--
          If Dp = 0 Then GoSub DCoL: If T = 1 Then T = 0: GoSub DLin
          If Dp = 1 Then GoSub DLin: If T = 1 Then T = 0: GoSub DCoL
          Cells(Ldi, cdi).Value2 = Ddo

     Next
     ''-----------------( Fim do loop )----
     GoTo saida

  '----------------------------( ORIGEM )------------
OLin:
     If Op = 0 Then
...
 Else
...
                    If Oquadante_L = True Then GoSub OCoL:
...
                    Else
...
                    If Oquadante_L = True Then GoSub OCoL:
      End If
     Return

OCoL:          '----( Controle de colunas )---
     If Op = 0 Then
...
GoSub OLin:
...
          Else
...
 GoSub OLin:
...
Else
    GoSub OLin:
     End If
     Return

     '---------( DESTINO )-----------
DLin:
     If Dp = 0 Then
...
 GoSub DCoL:
   Else
...
If Dquadante_L = True Then GoSub DCoL:
...
          Else
...
If Dquadante_L = True Then GoSub DCoL:
...
     End If
     Return

DCoL:
...
GoSub DLin:
...
          Else
GoSub DLin:
  End If
 Return

and the call of each function should be something like this
        Call funOCoL(Op, Loi, OLi, OLf, OqL, Lig, OZigL, Oquadrante_L, Coi, OCi, OCf, OqC, Cig, OZigC, Oquadrante_C, T)

but in general using functions is much more practical

Charles Pegge

  • Guest
Re: more bugs..
« Reply #19 on: January 05, 2018, 02:47:02 PM »
John,

You can have multiple rets from a gosub. Unlike a function, there is no formal termination. It compiles straight into assembly code without hidden extras.

It is also possible to pop the return address but this hack is cursed by the 64bit 16byte stack alignment protocol. However, You can allow the gosub routine to drop thru to end function without ret. The parent function epilog will automatically clean up the stack before the parent function is terminated.

Code: [Select]
int a=5,b=10
gosub sumif
print a
end

sumif:
if a<=5 then ret
a+=b
ret

Eduardo,

There are no restrictions with a gosub, which is probably why they are so reviled. As you say, gosubs share the variables of the environment where they are defined, unlike functions which require parameters.

Macros are also very useful. They are even faster and take parameters.

In both gosubs and macros, private variables can be defined inside a scope block. So you can achieve the encapsulation benefits of functions.
« Last Edit: January 05, 2018, 03:11:02 PM by Charles Pegge »

edcronos

  • Guest
Re: more bugs..
« Reply #20 on: January 05, 2018, 03:25:10 PM »
Charles, I do not understand what you mean by restrictions,
a single poorly defined variable can give a lot of headache

in this macro with gosub that allocates data from one array to another "Ranges" I had several problems with it by drawing up geometric figures with the data in the target array "something I can never reproduce"
and I suffered to adjust the adjustments of the variables

JRS

  • Guest
Re: more bugs..
« Reply #21 on: January 05, 2018, 05:03:57 PM »
Here is how it works under Script BASIC.

Code: Script BASIC
  1.  
  2. GOSUB Go_Sub
  3.  
  4. END
  5.  
  6. Go_Sub:
  7.   POP
  8.   GOTO Done
  9. RETURN
  10.  
  11. Done:
  12. PRINT"Exited GOSUB without a RETURN stack error.\n"
  13.  


jrs@jrs-laptop:~/sb/examples/test$ scriba pop.sb
Exited GOSUB without a RETURN stack error.
jrs@jrs-laptop:~/sb/examples/test$


edcronos

  • Guest
Re: more bugs..
« Reply #22 on: January 05, 2018, 07:12:16 PM »
I did not understand John,
how do you get out of a function without going back to the program that called it?
I even have a Sub Control that is called by most of the sub from a spreadsheet I made, and I had to add a control variable to determine the neutral
the gosub I think that one has to determine the functionalities and if it has to give sequendia to use a variable, in the case I used the variable T of tests to inform that the function had a change of value in the variables

Code: HTML5
  1.  
  2. GOSUB Go_Sub
  3.  if t=0 then GOTO Done
  4. ...
  5. END
  6.  
  7. Go_Sub:
  8. ...
  9.  if fails then t=0
  10. RETURN
  11.  
  12. Done:
  13. PRINT"Exited GOSUB without a RETURN stack error.\n"
  14.  
  15.  

JRS

  • Guest
Re: more bugs..
« Reply #23 on: January 05, 2018, 08:30:00 PM »
Quote
how do you get out of a function without going back to the program that called it?

GOSUB is not calling a function. It jumps to a LABEL and when it sees the RETURN it executes the line after the GOSUB that called it unless you use a POP before exiting without returning.

edcronos

  • Guest
Re: more bugs..
« Reply #24 on: January 05, 2018, 11:48:44 PM »
initially was to simulate function calls,
but of course it would be nice to have other facilities,
but in this case, how do you get nested calls?

Of course I would like to have goto and gosub with labels inside variable
but I do not know if it's possible, and I can not want everything

Charles Pegge

  • Guest
Re: more bugs..
« Reply #25 on: January 06, 2018, 03:09:22 AM »
Macros can replace small functions and gosubs very effectively, without using the stack and the expense of setting up stack frames for local variables.

Macros can be defined anywhere, even inside functions for local use.

Code: [Select]
macro limit(a,b)
  if a>b then goto done
end macro

int x=1
do
  limit(x,10)
  x+=3
end do
 
Done:
PRINT"Exited GOSUB without a RETURN stack error.\n"

edcronos

  • Guest
Re: more bugs..
« Reply #26 on: January 06, 2018, 04:11:16 AM »
I'm reading about macros and subroutines
but it is a strange concept for me, I did not quite understand the relation of scope to internal variables.
I do not know if it's what you intended using sub inside of sub, in case it would be something like a call taking advantage of the same scope of variables
well, I'm going to pick it up, anyway my use is very limited

a question, what kind of code example is interesting to post?

JRS

  • Guest
Re: more bugs..
« Reply #27 on: January 06, 2018, 10:38:49 PM »
BASIC Interpreters are easier to deal with GOSUB as in most cases variables are of a global scope, Script BASIC function/sub arguments are local but can easily refer to global variables within functions or subs. The LOCAL keyword is provided to isolate variables to a routine. The MODULE/END MODULE scope is a form of name space. Functions and variables in modules must be prefixed by the module name and :: for access from the MAIN:: script.

Code: Script BASIC
  1. ' MAIN
  2.  
  3. a = "Hello from MAIN::"
  4.  
  5. MODULE This
  6.  
  7. a = "Hello from This::"
  8.  
  9. END MODULE
  10.  
  11. PRINT MAIN::a,"\n"
  12. PRINT This::a,"\n"
  13.  


jrs@jrs-laptop:~/sb/examples/test$ scriba scope.sb
Hello from MAIN::
Hello from This::
jrs@jrs-laptop:~/sb/examples/test$


Note:  The MAIN:: prefix is optional in Script BASIC as it would make the program overly verbose. The syntax is supported if you can find a use.
« Last Edit: January 06, 2018, 10:51:24 PM by John »

edcronos

  • Guest
Re: more bugs..
« Reply #28 on: January 07, 2018, 10:49:50 AM »
is almost equal to vba
being that in vba the modules are physical but variable and procedures are seen,
  except as Private when only other procedures, from the same module see them, but do not replace internal variables with procedures

  and Global usage replaces any variable with the same name, something that has to be very careful but can serve as key variable

JRS

  • Guest
Re: more bugs..
« Reply #29 on: January 07, 2018, 11:56:43 AM »
Quote
s almost equal to vba

Actually SB is more like VBA then most people think. Checkout what I'm doing with SB on the Open Sage Forum.