Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ubc-vision.CDN
Path: utzoo!utcsrgv!ubc-vision!manis
From: manis@ubc-vision.CDN (Vincent Manis)
Newsgroups: net.lang.c
Subject: Re: Using &LABEL
Message-ID: <585@ubc-vision.CDN>
Date: Tue, 25-Sep-84 00:22:53 EDT
Article-I.D.: ubc-visi.585
Posted: Tue Sep 25 00:22:53 1984
Date-Received: Wed, 19-Sep-84 13:37:44 EDT
References: <15@tikal.UUCP>
Organization: UBC Vision, Vancouver, B.C., Canada
Lines: 21

The decision as to whether to use jump tables
rather than a linear scan of a value/address table
is certainly a fairly trivial thing for any compiler
to do, and one should most certainly not expect programmers
to have to think about it. The BCPL/370 compiler written at
Cambridge about 1970 did that properly, and I can see no
reason why any C compiler would find it hard to do.

Essentially, you measure the "packing factor" of an indexed jump 
table, and if it is lower than some figure (say 50%, but it
would depend on how precious address space and CPU cycles are),
you select the linear scan, and if the packing factor is greater 
than 50% you use the indexed jump.

The packing factor is computed by determining the range
(max case value-min case value) and dividing by the number
of entries.

I personally can see absolutely no use whatsoever for &label, 
(&function, on the other hand is extremely useful), and would
be quite happy to see its existence deferred indefinitely.