Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!ames!ucbcad!ucbvax!decvax!savax!elrond!adb
From: adb@elrond.UUCP (Alan D. Brunelle)
Newsgroups: comp.lang.c
Subject: Re: X3J11: Why no labelled loops?
Message-ID: <674@elrond.UUCP>
Date: Thu, 5-Mar-87 16:39:50 EST
Article-I.D.: elrond.674
Posted: Thu Mar  5 16:39:50 1987
Date-Received: Sat, 7-Mar-87 22:37:36 EST
References: <1710@plus5.UUCP> <388@cognos.UUCP> <545@mntgfx.MENTOR.COM>
Organization: Calcomp Display Products Division, Hudson, NH, USA
Lines: 63
Summary: Suggested 'correct' way to handle your pet peeve

In article <545@mntgfx.MENTOR.COM>, franka@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       				  |
|									  |
\-------------------------------------------------------------------------/