MattS-UK:
Imagine you want to implement a many nested menu system on your Arduino, with every node returning directly to a 'home' screen. Using structured code, the execution point descends a series of functions, each one pushing pointers onto the stack, which grows upwards consuming SRAM. The stack then has to be collapsed, to return to the home screen. Write the menu using GOTOs avoids growing the stack and the CPU overhead of collapsing it.Essentially, a GOTO compiles to an assembly language BRA (branch always) instruction. An unconditional branch uses fewer clock cycles and less RAM, than pushing data onto the stack and calling JSB (jump subroutine).
Interestingly, Return To Basic was developed for the RasPI by a long time friend of mine. For the sake of nostalgia, I wrote an ASCII arcade scroller for the early version. Initially using line numbers and goto, then again using structured code. The structured code was so much slower, the game became unplayable.
Yes but the BBC Micro introduced structured BASIC to the masses. BASIC with procedures, functions, local variables and without line numbers. Fast BASIC and GW BASIC soon followed.
How many 8 bit home micros came with Forth exactly? One as far as I know, the Jupiter ACE.
That would be a very poor way to implement a menu system. I've done menuing systems with many levels of menus, sometimes going 4 or 5 levels deep. I've never once had to use goto. A proper design will use a state machine, or a lookup table, or some other high-level structure to avoid the headaches goto can create, and to make the path, both down and back up, the menuing system absolutely concrete. There is VERY rarely a "need" to use goto. It is a poor design choice in all but a very small number of exceptional cases.
Regards,
Ray L.