Found this on my disk. I forget where/why it came from but I
thought it was fun enough to share.

% cat gosub.c
#include <stdio.h>

#define GOSUB(target) do { *stk++ = __LINE__; goto target; case __LINE__: ;} while(0)
#define RETURN() do{ target = *--stk; goto Goto; } while(0)

int main(){
int *stk = (int [10]){};
int target = 0;
Goto: switch( target ){
default:
puts("program begins.");
GOSUB(test_label);
puts("program continues.");
GOSUB(test_label);
puts("program ends.");
return 0;
test_label:
puts("gosub successful.");
RETURN();
}
}

luser droog <luser.droog@gmail.com> wrote:

> Found this on my disk. I forget where/why it came from but I
> thought it was fun enough to share.

That was... worthy of the obfuscated C competition. Thanks, I hate it.
--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

om@iki.fi (Otto J. Makela) writes:
>That was... worthy of the obfuscated C competition.

The code given was quite clear. Still, such a macro is not
particularly elegant.

Indeed, I sometimes miss GOSUB in C.

When I have a function with many local names, and want to
add some structure to it, I might use a separate function
as a subroutine, but then I might have to write a lot of
parameter declarations, which might also be deemed to be
some kind of obfuscation. Today, optimizing compilers can
make sure that there will be no run-time penalty for this,
but there still is this write-time penalty. A GOSUB would
be less cumbersome and more clear in such cases.

Den 2022-04-12 skrev luser droog <luser.droog@gmail.com>:
> Found this on my disk. I forget where/why it came from but I
> thought it was fun enough to share.
>

It was well worth sharing!

>
> % cat gosub.c
> #include <stdio.h>
>
> #define GOSUB(target) do { *stk++ = __LINE__; goto target; case __LINE__: ;} while(0)
> #define RETURN() do{ target = *--stk; goto Goto; } while(0)
>
> int main(){
> int *stk = (int [10]){};
> int target = 0;
> Goto: switch( target ){
> default:
> puts("program begins.");
> GOSUB(test_label);
> puts("program continues.");
> GOSUB(test_label);
> puts("program ends.");
> return 0;
> test_label:
> puts("gosub successful.");
> RETURN();
> }
> }

I tried throwing this code at clang 10.0.1 with -O3 on an amd64 system
and it produced some, to me, surprising results. I expected the
compiler to turn the code into

int main()
{ puts("program begins.");
puts("gosub successful.");
puts("program continues.");
puts("gosub successful.");
puts("program ends.");
return 0;
}

but I got something along the lines of (assembler turned back into C
by hand)

int main()
{ int value = 0;

goto begin;

print_continue:
puts("program continues.");
value = 0xe;

print_gosub:
puts("gosub successful.");

begin:
if (value == 0xc)
goto print_continue;
if (value == 0xe)
goto print_end;

puts("program begins.");
value = 0xc;
goto print_gosub;

print_end:
puts("program ends.");
return 0;
}

I have a hard time imagining that this construct would be more
efficient than simply printing the output in sequence. Is it the
switch-case construct causing the compiler to organise the code the
way it does?

Andreas Kempe <kempe@lysator.liu.se> writes:
>int main()
>{
> puts("program begins.");
> puts("gosub successful.");
> puts("program continues.");
> puts("gosub successful.");
> puts("program ends.");
> return 0;
>}

Here,

leaq .LC0(%rip), %rcx; call puts
leaq .LC1(%rip), %rcx; call puts
leaq .LC2(%rip), %rcx; call puts
leaq .LC1(%rip), %rcx; call puts
leaq .LC3(%rip), %rcx; call puts

, assembler simplified and reformatted by hand, two
operations per line. gcc estimated to be not older than
5 years, options including "-march=native -Ofast -O3".

Den 2022-04-20 skrev Stefan Ram <ram@zedat.fu-berlin.de>:
> Andreas Kempe <kempe@lysator.liu.se> writes:
>>int main()
>>{
>> puts("program begins.");
>> puts("gosub successful.");
>> puts("program continues.");
>> puts("gosub successful.");
>> puts("program ends.");
>> return 0;
>>}
>
> Here,
>
> leaq .LC0(%rip), %rcx; call puts
> leaq .LC1(%rip), %rcx; call puts
> leaq .LC2(%rip), %rcx; call puts
> leaq .LC1(%rip), %rcx; call puts
> leaq .LC3(%rip), %rcx; call puts
>
> , assembler simplified and reformatted by hand, two
> operations per line. gcc estimated to be not older than
> 5 years, options including "-march=native -Ofast -O3".
>

I tried it on GCC 10.3.0 and got the same result as you, I also tried
it on another system with a newer llvm, clang version 13.0.1, and it
produced the same result as my first llvm attempt.

Interesting that GCC seems to provide a better optimisation than llvm
in this case. I'm not well versed enough in compiler construction to
say why.

On Wednesday, April 20, 2022 at 9:44:01 AM UTC-5, Andreas Kempe wrote:
> Den 2022-04-12 skrev luser droog <luser...@gmail.com>:
> > Found this on my disk. I forget where/why it came from but I
> > thought it was fun enough to share.
> >
> It was well worth sharing!
> >
> > % cat gosub.c
> > #include <stdio.h>
> >
> > #define GOSUB(target) do { *stk++ = __LINE__; goto target; case __LINE__: ;} while(0)
> > #define RETURN() do{ target = *--stk; goto Goto; } while(0)
> >
> > int main(){
> > int *stk = (int [10]){};
> > int target = 0;
> > Goto: switch( target ){
> > default:
> > puts("program begins.");
> > GOSUB(test_label);
> > puts("program continues.");
> > GOSUB(test_label);
> > puts("program ends.");
> > return 0;
> > test_label:
> > puts("gosub successful.");
> > RETURN();
> > }
> > }
> I tried throwing this code at clang 10.0.1 with -O3 on an amd64 system
> and it produced some, to me, surprising results. I expected the
> compiler to turn the code into
>
> int main()
> {
> puts("program begins.");
> puts("gosub successful.");
> puts("program continues.");
> puts("gosub successful.");
> puts("program ends.");
> return 0;
> }
> but I got something along the lines of (assembler turned back into C
> by hand)
>
> int main()
> {
> int value = 0;
>
> goto begin;
>
> print_continue:
> puts("program continues.");
> value = 0xe;
>
> print_gosub:
> puts("gosub successful.");
>
> begin:
> if (value == 0xc)
> goto print_continue;
> if (value == 0xe)
> goto print_end;
>
> puts("program begins.");
> value = 0xc;
> goto print_gosub;
>
> print_end:
> puts("program ends.");
> return 0;
> }
> I have a hard time imagining that this construct would be more
> efficient than simply printing the output in sequence. Is it the
> switch-case construct causing the compiler to organise the code the
> way it does?

Yes, it looks like the optimizer is having a hard time ironing out all of the
jumping/dispatching. It looks like the generous 10-element stack has been collapsed
into the single element actually used, but that "jump target" variable persists.
A little more unrolling of the loop and it might get closer to the straight ahead
version. But the optimizer doesn't know how close it is, it can't hear the crowd cheering.

With C++11 you have lamdas as local functions.
Magnitudes more elegant than you GOSUB-macro-orgy.

In article <t3qqr3$45l$1@dont-email.me>,
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>With C++11 you have lamdas as local functions.
>Magnitudes more elegant than you GOSUB-macro-orgy.

What part of "C++ is off topic here" do you still not get?

As is Perl, Python, and Fortran (among others).

--
1/20/17: A great day for all those people who are sick of being told
they don't know how to spell "you're" (or "there").

> Den 2022-04-12 skrev luser droog <luser.droog@gmail.com>:
> Found this on my disk. I forget where/why it came from but I
> thought it was fun enough to share.
>
>
> % cat gosub.c
> #include <stdio.h>
>
> #define GOSUB(target) do { *stk++ = __LINE__; goto target; case __LINE__: ;} while(0)
> #define RETURN() do{ target = *--stk; goto Goto; } while(0)
>
> int main(){
> int *stk = (int [10]){};
> int target = 0;
> Goto: switch( target ){
> default:
> puts("program begins.");
> GOSUB(test_label);
> puts("program continues.");
> GOSUB(test_label);
> puts("program ends.");
> return 0;
> test_label:
> puts("gosub successful.");
> RETURN();
> }
> }

Just a localized application of the same rather well-known
switch/case-version of Simon Tatham-style coroutine technique.

--
Best regards,
Andrey Tarasevich

Am 21.04.2022 um 08:03 schrieb Kenny McCormack:
> In article <t3qqr3$45l$1@dont-email.me>,
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> With C++11 you have lamdas as local functions.
>> Magnitudes more elegant than you GOSUB-macro-orgy.
>
> What part of "C++ is off topic here" do you still not get?

It's just a recommendation to use a proper language if you wish
sth. like that.

Bonita Montero:

> With C++11 you have lamdas as local functions. Magnitudes
> more elegant than you GOSUB-macro-orgy.

Lambdas, being a functional concept, are alien to a
procedural language. The mixing of functional and procedural
approaches makes a language discordant and more complicated
both to understand and to implement in a complier. C++ is
about a hundred times larger and more complex than C. Since
simplicity is perfection, C++ is inferior to C by the same
factor.

> It's just a recommendation to use a proper language if you
> wish sth. like that.

In this newsgroup the proper language is C, no matter what
the task.

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

On Friday, 22 April 2022 at 09:15:47 UTC+1, Anton Shepelev wrote:
> Bonita Montero:
> > With C++11 you have lamdas as local functions. Magnitudes
> > more elegant than you GOSUB-macro-orgy.
> Lambdas, being a functional concept, are alien to a
> procedural language. The mixing of functional and procedural
> approaches makes a language discordant and more complicated
> both to understand and to implement in a complier. C++ is
> about a hundred times larger and more complex than C. Since
> simplicity is perfection, C++ is inferior to C by the same
> factor.
>
A trivial little lambda in basically procedural code can make
code easier to read. For instance, if you pass a lambda to std::sort,
you can see at a glace which field is being sorted on. If you pass
a function pointer, it is necessary to scroll to the comparison function.
If you write your own sort routine and embed the comparison code,
then that is many times more difficult to implement and verify.

Am 22.04.2022 um 10:15 schrieb Anton Shepelev:
> Bonita Montero:
>
>> With C++11 you have lamdas as local functions. Magnitudes
>> more elegant than you GOSUB-macro-orgy.
>
> Lambdas, being a functional concept, are alien to a
> procedural language. The mixing of functional and procedural
> approaches makes a language discordant and more complicated
> both to understand and to implement in a complier. C++ is
> about a hundred times larger and more complex than C. Since
> simplicity is perfection, C++ is inferior to C by the same
> factor.

C++ is magnitutes more superior to C because it's much easier to
realize complex projects with C++. And lambdas make the code also
much more readable and often faster.

Am 22.04.2022 um 11:16 schrieb Malcolm McLean:
> On Friday, 22 April 2022 at 09:15:47 UTC+1, Anton Shepelev wrote:
>> Bonita Montero:
>>> With C++11 you have lamdas as local functions. Magnitudes
>>> more elegant than you GOSUB-macro-orgy.
>> Lambdas, being a functional concept, are alien to a
>> procedural language. The mixing of functional and procedural
>> approaches makes a language discordant and more complicated
>> both to understand and to implement in a complier. C++ is
>> about a hundred times larger and more complex than C. Since
>> simplicity is perfection, C++ is inferior to C by the same
>> factor.
>>
> A trivial little lambda in basically procedural code can make
> code easier to read. For instance, if you pass a lambda to std::sort,
> you can see at a glace which field is being sorted on. If you pass
> a function pointer, it is necessary to scroll to the comparison function.
> If you write your own sort routine and embed the comparison code,
> then that is many times more difficult to implement and verify.

I not only use lambdas as function objects being passed as a parameter.
I use lambdas when it doesn't make sense to have an external function
because it is only used once to segement the code. And I use lambdas
to have a lot less code to pack redundant code-parts inside a function
inside a lambda. Lambdas are such a giant relief, and with C++20 even
more since you can have templated lambdas.

On Thursday, April 21, 2022 at 12:42:08 AM UTC-5, Bonita Montero wrote:
> With C++11 you have lamdas as local functions.
> Magnitudes more elegant than you GOSUB-macro-orgy.

It's like literally 2 macros. Two meager lines of code, ok 3 for the harness.
If the result is feature comparable to C++ lambdas, then maybe the takeaway isn't
what you think it is.

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

> Bonita Montero:
>
>> With C++11 you have lamdas as local functions. Magnitudes
>> more elegant than you GOSUB-macro-orgy.
>
> Lambdas, being a functional concept, are alien to a
> procedural language. The mixing of functional and procedural
> approaches makes a language discordant and more complicated
> both to understand and to implement in a complier. [...]

Even Algol had nested functions.