|
|
Post by parzival on Apr 28, 2021 14:26:08 GMT
I come from the school that says GOTO statements are to be avoided, and that GOSUB/RETURN routines are preferable.
But from what I can tell, GOSUB in C64 BASIC risks slowing things down, especially as they nest. Would replacing GOSUB/RETURN statements with direct GOTOs be quicker, if generally poorer coding practice?
|
|
|
|
Post by Unbeliever on Apr 29, 2021 18:42:09 GMT
My general feeling is that hacks to speed up BASIC are pointless. If speed is an issue, use assembly. Or at least, a BASIC/ML hybrid approach. I would HATE to work on a BASIC program littered with GOTOs. For me, at least, readability is the most essential coding virtue. The harder the code is to understand, the harder is is to develop in the first place, much less modify later. And the more GOTOs, the more you sacrifice readability...
That said, your question made me curious, so I ran a simple test.
5000 GOSUB/RETURNs:
5000 pairs of GOTOs:
Same line numbers, same code -- I just used GOSUB/RETURN in the first example, and a pair of GOTOs in the second example.
In this (simple) example, it looks like GOSUB is actually faster.
So you can keep your superior coding practice, worry-free! 
|
|
|
|
Post by parzival on Apr 29, 2021 19:51:45 GMT
Well, assembler and ML are out of my wheelhouse. So tightening up my BASIC code is my only option.
Thanks for checking and for the reply! Yeah, I’ll be sticking with GOSUB, especially as RETURN closes out FOR/NEXT loops, which I need to happen (and need fewer of).
|
|
|
|
Post by vic2020ian on Apr 30, 2021 7:15:49 GMT
I would HATE to work on a BASIC program littered with GOTOs. For me, at least, readability is the most essential coding virtue. The harder the code is to understand, the harder is is to develop in the first place, much less modify later. And the more GOTOs, the more you sacrifice readability...
You can make readable code with goto equivalent to Gosub readability. The disadvantage is that you sacrifice reusability. Gosub is for reusable routines to save memory. Goto makes for perhaps repeated code or conditional goto statements to return to a different place. 10 Print "Hello":a=1 20 goto 100: rem clear screen routine 30 print" hello again":a=2 40 goto 100: rem clear screen routine 50 print"hello 3rd time" 60 etc. 100 print"clrscrn":rem clears the screen and goes back 110 if a=1 goto 30: if a=2 goto 50 |
|
|
|
Post by namrok on Apr 30, 2021 14:14:13 GMT
Well, assembler and ML are out of my wheelhouse. So tightening up my BASIC code is my only option. Thanks for checking and for the reply! Yeah, I’ll be sticking with GOSUB, especially as RETURN closes out FOR/NEXT loops, which I need to happen (and need fewer of). Never say never! IMHO 6502 assembly language, and specifically 6502 with the C64's kernel/memory map, is a breeze so far as assembly languages go. Only 1 accumulator, 2 registers. Kernel functions that can do most basic tasks for you like reading input and printing to the screen. The entire instruction set is almost entirely reading and writing memory locations, with very intuitive math, testing and branching features. I mean, I say all this as a person with extensive programming experience. But still. If you don't want to because you don't want to, that's fine. But if you are intimidated by it, I say "Don't be". |
|
|
|
Post by parzival on Apr 30, 2021 15:16:54 GMT
Well, assembler and ML are out of my wheelhouse. So tightening up my BASIC code is my only option. Thanks for checking and for the reply! Yeah, I’ll be sticking with GOSUB, especially as RETURN closes out FOR/NEXT loops, which I need to happen (and need fewer of). Never say never! IMHO 6502 assembly language, and specifically 6502 with the C64's kernel/memory map, is a breeze so far as assembly languages go. Only 1 accumulator, 2 registers. Kernel functions that can do most basic tasks for you like reading input and printing to the screen. The entire instruction set is almost entirely reading and writing memory locations, with very intuitive math, testing and branching features. I mean, I say all this as a person with extensive programming experience. But still. If you don't want to because you don't want to, that's fine. But if you are intimidated by it, I say "Don't be". Not so much intimidated as not quite in a place to take the time to learn. It’s on my “to do” list. To some extent, what I’m coding is a proof-of-concept to myself, that I could take a very old program structure (which I first did on a TSR-80 back in the day) and turn it into a playable text adventure game on the C64. It’s as much a nostalgia trip as a programming effort. It’s also oiling some very, very rusty gears— I haven’t coded anything since the ‘90s! So for now, I’m gonna tighten this thing up as much as I can. I’ve already realized I’ve maxed the potential of raw BASIC for this sort of thing... and this game has only 25 “rooms” and 209 words (which I am probably going to reduce because of the processing delays). If I want to create a broader adventuring environment (and I do), then I’m going to have to find ways to trim the processing fat to make room for all the text strings it will need. |
|
