Dumb Question - More Efficient Way to Gosub?

[Thorham]

Originally Posted by carrion

Maybe they are

Not maybe, definitely.

Originally Posted by carrion

but as far as I can tell (and tested) they are slow in BB2.

That's quite a shame, because they're quite important.

Originally Posted by carrion

it's faster and compiles strictly to the same code in assembly language.

Yes, although in handwritten asm you'd use a register to pass the argument and you'd also have the routine save registers to the stack:

    move.l  #123,d0
    bsr     subroutine

subroutine
    movem.l d1,-(sp)
    
    move.l  d0,d1
    lsl.l   #1,d0
    add.l   d1,d0
    
    movem.l (sp)+,d1
    rts

Are you sure it's slow? The above code is basically what a function should more or less compile to.

[AestheticDebris]

Originally Posted by DisasterIncarna

JSR/RTS?, never used that kind of thing before but ill try giving that a go, looks like a simple find/replace can be used to replace Gosub>JSR and Return>RTS.

I'm not convinced that will actually make any difference at all in terms of code efficiency. GOSUB is essentially just a synonym for JSR. It only makes a difference with functions/procedures because you're removing the overhead of passing parameters etc, which you could just as "easily" do by converting them to GOSUBs (obviously all the problems of using global variables to manage shared data would then exist).

[Daedalus]

Yep, there's an overhead involved in using functions. If you're using AmiBlitz, you can specify a FAST keyword when defining a function. This makes them a bit faster, but imposes some limitations like not initialising local variables to 0 and not being able to pass strings as parameters. Goto and Gosub are much more efficient - as said, they compile to pretty simple jumps, at the expense of the code modularity and organisation.

I haven't benchmarked it, but if you're looking for more condensed code, Blitz also supports the On version of Goto / Gosub from other Basics. You can jump to a number of labels based on a value, starting from 1. For your code:

If WHATEVENT= $40 AND EventWindow = mywindow  ; Do something if gadget is selected/hit
     On GadgetHit - 49 Gosub HITSEARCHBOX, HITSEARCHBUTT, HITDESTBOX, HITDESTBUTT, HITEXTRACTTYPE
  EndIf

This is, of course, dependent on your event codes being sequential, and is ripe for introducing bugs if you ever adjust your constants to e.g. fit more gadgets in. I don't think there's any advantage worth the potential for bugs there, but it's an option.

[patrik]

Is the potential performance overhead of a function call relevant in this case? It looks like it will spend most time waiting on events here.

Had it been an hot inner loop of some computational function, it would be more relevant to worry about calling functions or jumping.

[DisasterIncarna]

Originally Posted by Daedalus

Yep, there's an overhead involved in using functions. If you're using AmiBlitz, you can specify a FAST keyword when defining a function. This makes them a bit faster, but imposes some limitations like not initialising local variables to 0 and not being able to pass strings as parameters. Goto and Gosub are much more efficient - as said, they compile to pretty simple jumps, at the expense of the code modularity and organisation.

I haven't benchmarked it, but if you're looking for more condensed code, Blitz also supports the On version of Goto / Gosub from other Basics. You can jump to a number of labels based on a value, starting from 1. For your code:

If WHATEVENT= $40 AND EventWindow = mywindow  ; Do something if gadget is selected/hit
     On GadgetHit - 49 Gosub HITSEARCHBOX, HITSEARCHBUTT, HITDESTBOX, HITDESTBUTT, HITEXTRACTTYPE
  EndIf

This is, of course, dependent on your event codes being sequential, and is ripe for introducing bugs if you ever adjust your constants to e.g. fit more gadgets in. I don't think there's any advantage worth the potential for bugs there, but it's an option.

this looks exactly like what im after to cut down a page and a half of code.

yeah i dont ever call the gadget numbers directly, they are all preassigned numbers at the beginning of the program starting at 50 and work up from there in 1's, so at the beginning for example i start with #_SEARCHBOX=50, and every time i need to refer to the button this equates to i refer to it as #_SEARCHBOX rather than a hard/fixed 50, just makes it easier for me when i see a load of GT-Gadget commands using those named tags instead of numbers.

GTString mywindow,#_SEARCHBOX,0,0,LRSIZE,GADHEIGHT,"",$0,256,SRCHTXT$

is easier for me to quickly identify than

GTString mywindow,50,0,0,LRSIZE,GADHEIGHT,"",$0,256,SRCHTXT$

probably extra fluff being added but helps me see whats what, esp as my GT gadget stuff looks a bit over complex due to it trying to smart adapt to the window when it resizes and adjust to fill the window when certain gadgets are turned off by the user.

but that "On" solution again looks perfect for what i want, ill try and use that for my 2 main projects.

[DisasterIncarna]

This is at the start of my GUI for UHC Tools, not a massive amount of gadgets but its how i refer to them rather than fixed numbers, my other program uses significantly more gadgets/number id's.

; Gadget Identifier List

; Row 1 of gadgets
#_SEARCHBOX = 50
#_SEARCHBUTT = 51
#_DESTBOX = 52
#_DESTBUTT = 53
#_EXTRACTTYPE = 54

; Row 2 of gadgets
#_DOWNLOADBUTT = 55
#_CLEARSEARCHBUTT = 56
#_RECENTUPLOADBUTT = 57
#_VIEWREADMEBUTT = 58
#_MIRRORLISTCYCLE = 59

; Row 3 HeaderText
#_HEADERTEXT = 60

; Row 4 of gadgets - Listviews
#_SEARCHRESULTLIST = 61
#_MIRRORLIST = 62
#_CATEGORYLIST = 63
#_UPDATEWATCHER = 64

; Row 5 of gadgets - Info bar
#_INFOTEXT = 65

[Daedalus]

Yep, using constants definitely makes code more readable and is something that should be encouraged. The thing to bear in mind is that the On form of Gosub effectively does use gadget numbers directly, so if the constants ever change in the future you might have unexpected results from the jump. But so long as you don't change them, it should work fine.

[DisasterIncarna]

noted, cheers.

[E-Penguin]

Originally Posted by Daedalus

Yep, there's an overhead involved in using functions. If you're using AmiBlitz, you can specify a FAST keyword when defining a function. This makes them a bit faster, but imposes some limitations like not initialising local variables to 0 and not being able to pass strings as parameters. Goto and Gosub are much more efficient - as said, they compile to pretty simple jumps, at the expense of the code modularity and organisation.

I haven't benchmarked it, but if you're looking for more condensed code, Blitz also supports the On version of Goto / Gosub from other Basics. You can jump to a number of labels based on a value, starting from 1. For your code:

If WHATEVENT= $40 AND EventWindow = mywindow  ; Do something if gadget is selected/hit
     On GadgetHit - 49 Gosub HITSEARCHBOX, HITSEARCHBUTT, HITDESTBOX, HITDESTBUTT, HITEXTRACTTYPE
  EndIf

This is, of course, dependent on your event codes being sequential, and is ripe for introducing bugs if you ever adjust your constants to e.g. fit more gadgets in. I don't think there's any advantage worth the potential for bugs there, but it's an option.

If I was doing this in C, I'd use an array of function pointers and avoid the

case 

statement entirely. I guess this is more or less what's going on here. I don't know if it's possible to do function pointers in blitz? maybe with some embedded asm or something hacky.

[Dunny]

Originally Posted by E-Penguin

If I was doing this in C, I'd use an array of function pointers and avoid the

case 

statement entirely. I guess this is more or less what's going on here. I don't know if it's possible to do function pointers in blitz? maybe with some embedded asm or something hacky.

That's what I was just wondering. If Blitz can maintain an array of addresses, then just use that as a LUT to branch to based on the ID number of the event?

[Daedalus]

Yeah, I don't think you can do that with the standard Blitz commands, but you can jump to an address with a JMP or JSR. The addresses of program labels can be found using a question mark:

myAddress.l = ?myLabel

[idrougge]

You can use a self-modifying macro to create an enumeration automatically.

Then you can use a macro to make a label for your Gosub matching the ID generated by the macro.

[Daedalus]

Ooh, that sounds very clever, I must try it out some time.

[idrougge]

There is also the CNAME ~expression~ feature to help out with this.