X3J11: Why no labelled loops?

[Alan D. Brunelle]

In article <545 at mntgfx.MENTOR.COM>, franka at mntgfx.MENTOR.COM (Frank A. Adrian) writes:
> Now for my pet peeve.  Why can't you take the address of a label?  This
> would be useful in writing threaded code interpreters and in doing high
> performance code.  As far as I know, there is no work around for this
> problem.  E.g.,
>     label   *jump_table[] = { &exe_seg_0, &exe_seg_1, ... };
>     while (!halt_flag) {
>         /* do something to load the byte code */
>         goto *jump_table[byte_code];
> exe_seg_0:
>         /* stuff */
>         continue;
...
> 
> I know that some of you will be saying how is this different than a switch
> statement?  It is different in three ways
>  1) A switch statement will often be converted to a series of if-then-else
>     on many machines.  With this method, I have control over how the code is
>     executed.  I also control range checking.
>  2) I can convert the byte codes for an interpreted language into addresses
>    of the actual routines at load time (can you say direct threaded code, boys
>  and girls?), so that the array lookup of the above is unnecessary.  This also
>     avoids the routine call overhead which is the closest way to do this in C
>     currently.
>  3)  It allows me to dynamically construct code in an array an execute it
>     without resorting to assembly code linkages (this is very important for
>     doing incremental compiling / bytecode conversion easily).
> This construct is not difficult to implement on linkers, it is not any more
> hazardous than the goto statement itself, and it introduces a capability into
> the language which is not currently there and for which no fast workaround
> exists.  In fact, I wonder why this idea has not been implemented before...
> 
  Would it not be better to use what C already offers? How about implementing
  this with routines rather than goto's? 

  If you declare an array of pointers to functions, then when you have
  your byte_code then:

  (*func)[byte_code](params);

  will do exactly what your want with the added overhead of a procedure
  call. (DON'T flame me on the syntax - look it up....)

  These arrays can be built sort of dynamically (remember if you 
  have a function foo, then &foo is a sort of constant (decided and
  link/load time)), and it is very clear what is going on...I have
  used this technique many times (Ever simulate a M68000? break the
  32 bit instructions down into small 2 to 4 bit patterns, then 
  use the above to call a routine to further break it down...)

  al

/-------------------------------------------------------------------------\
|                                                                         |
| Alan D. Brunelle							  |
| 									  |
| uucp:    ...decvax!elrond!adb           "To do all the talking and not  |
| phone:   (603) 885-8145                  to be willing to hear anything |
| us mail: Calcomp/Lockheed DPD            is greediness."		  |
|          (PTP2-2D01)                          Democritus 		  |
|          Hudson NH    03051-0908       				  |
|									  |
\-------------------------------------------------------------------------/