[LCP]Address of a label

[Chirag Kantharia]

On Thu, 21 Feb 2002 10:18:40 -0000, Vincent Penquerc' wrote:
| GCC has computed gotos, which you may find about in the docs.
| I don't know how they work, so I can't explain those here.
| A more portable solution would be to put each case's code in a
| separate function, store their pointers in a table, and call
| the one indexed by your switch parameter. This only works if
| you have non scattered cases though, or you'll get a huge table.

Hello Vincent,

Thanx for your mail. Yes, I'd thought of that approach as well.
Fortunately, my cases are sequential, and I would not have to waste too
much of memory for the array. More below.


On Thu, Feb 21, 2002 at 09:17:20AM -0500, Mike & Penny Novack wrote:
|     Vincent has really hit he crux of this. Unless the (possible) values
| of your switch represent a dense set this would be more trouble than
| it's worth because every POSSIBLE value needs a destination (off course
| all the "error" ones do the same thing). In other words, your array
| would have to be as large as the "space" represented by ALL possible
| values of the switch. Of course all us old assembler programmers know
| about "computed jump tables".

Hello Mike and Penny,

Thanx for your response. The code which I'm writing is for a JVM, and
the switch statement is the byte interpreter switch. That is, I have a
list of opcodes, in a char *, and I have to execute those bytecodes.
These opcodes go from 0x0 to 0xCA, and they are sequential.

|     Maybe you are asking the wrong question? (in terms of what you want
| to accomplish). How different are your actions? The sense in which I
| mean this in what way does "something 1" depend upon "switch value 1".
| Rather than using the data to select the action, is there any way you
| can make a single action "data dependent"?

No, I cannot make that assumption.

|     The other thing to keep in mind is to look at run time efficiency
| the correct way. Is this something done repeatedly? (if not, no point
| trying to speed it up). The other is that run time efficiency does NOT
| depend upon the number of lines of code. Let me explain that.

Yes. It's the main interpreter code for the bytecode and so that's the
main code of the JVM, apart from the class loader.

|     Here you have a "case statement" which is defined to process
| sequencially. For 200 cases, 100 tests on average if all are equally
| likely. BUT -- are they uniformly likely. If in fact the first couple
| cases (in terms of the order you place them) are much more likely than
| the others, then THAT determines the average behavior of the code ---
| your optimization would gain little if "case1" were many times as likely
| as all the rest combined. And there are other alternatives. Two hundred
| possible cases CAN be done with 8 tests (it's less than 256) -- lots of
| lines of coding expressed as a "binary if" but only 8 tests executed in
| any one pass through.

Yes, I'd thought of that too; ie, sorting the opcodes on the basis of
their usage. The ones that are used most frequently, to be placed near
the top of the switch statement. But that wouldn't be a very good method
of doing things; cos it would be based more on heuristics, than concrete
info.

|     Remember, the behavior of "case" is more general than  a "jump
| table" (you don't HAVE to have a "break" after each) which is why it
| isn't implemented as one.

Right. I'd sent the query to a few other mailing lists as well, where I
got the following solutions:

1. This one is allowed only in GCC (it's a GNU extension):

void * ptr;
...
ptr = &&label;
...
goto *ptr;

2. This one is quite good idea, and portable too.

#define label(x) do_something ## x

   goto label(1);

do_something1:
  ...
do_something2:
  ...



chyrag.
-- 
Chirag Kantharia, symonds.net/~chyrag/
Linux scrooge 2.4.17 #1 Wed Jan 16 17:07:25 IST 2002 i686 unknown