[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[LCP]Address of a label
- Subject: [LCP]Address of a label
- From: linuxcprogramming@lists.linux.org.au (Chirag Kantharia)
- Date: Thu Mar 7 01:14:16 2002
- In-Reply-To: <3C762DCB.7030602@oracle.com>
- References: <20020221145919.A14681@epigonaudio.com> <002801c1baf2$dcd0adc0$2b44aac7@computer> <20020222095821.C800@epigonaudio.com> <3C762DCB.7030602@oracle.com>
On Fri, Feb 22, 2002 at 11:38:51AM +0000, David Spencer wrote:
| The only disadvantage to a switch that I can think of is that I *think*
| it is implemented as an if/else if ladder, so for a switch statement
| with 200 equally probably cases you will have on average 100 comparisons
| per bytecode, which could be a little inefficient. An optimising
| compiler might spot the fact that it is sequential and implement a
| computed goto and/or jumptable but you'd have to examine the assembler
| output to be sure.
Hi David,
Thanx for your mail. Yes, what you say is true. The above is the only
disadvantage of using a switch(), and that's exactly, what made me think
of alternatives. I'm not advocating usage of gotos, but I also think,
that, there might be very few situations, where goto might be just more
efficient.
But as you say, an optimizing compiler might spot this sequential cases,
and implement a jumptable, instead of a switch(), which is what I found
out yesterday. At least on Linux, gcc -S for a huge switch, reports only
one cmp. I'm yet to check on other platforms.
| A computed goto equivalent could be done with an array of structs:
| struct bytecodes
| {
| void (*func)();
| } multiplexer[200];
Yes. I'd thought of this as well. I'd written about it, in my mail.
chyrag.
--
Chirag Kantharia, symonds.net/~chyrag/
Linux scrooge 2.4.17 #1 Wed Jan 16 17:07:25 IST 2002 i686 unknown