Re: a GCC question

	I would guess that for smaller numbers of cases, GCC is deciding
that it is more efficient to use a series of "if" statements for a
decision tree instead of a switch statement.  You can explicitly code it
as such, e.g.,

if (bi->dispDeviceDepth == 32)
...
else if (bi-dispDeviceDepth == 16)
...
else if
...
else abort();

(BTW you do not provide a default case for some illegal value in your
switch statement.)

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Sat, 5 Aug 2000, David Edelsohn wrote:

	I would guess that for smaller numbers of cases, GCC is deciding
that it is more efficient to use a series of "if" statements for a
decision tree instead of a switch statement.  You can explicitly code it
as such, e.g.,

if (bi->dispDeviceDepth == 32)
...
else if (bi-dispDeviceDepth == 16)
...
else if
...
else abort();

Ah, that works, though the code doesn't work for some other unknown
reasons now, probably due to something along the line of things Olaf was
talking about recently.  Thanks!

Is there other kind of C constructs besides a switch statement which uses
.rodata or some such internally that you know of?  If the use of .rodata
is explicit like for the case of printk("I'm in .rodata."), we can fix the
reference dynamically pretty easily, but not the internal one like for the
case of a switch statement.

(BTW you do not provide a default case for some illegal value in your
switch statement.)

The default action is to do nothing, so there is no default case in there.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Sat, Aug 05, Takashi Oe wrote:

On Sat, 5 Aug 2000, David Edelsohn wrote:

quoted

	I would guess that for smaller numbers of cases, GCC is deciding
that it is more efficient to use a series of "if" statements for a
decision tree instead of a switch statement.  You can explicitly code it
as such, e.g.,

if (bi->dispDeviceDepth == 32)
...
else if (bi-dispDeviceDepth == 16)
...
else if
...
else abort();

Ah, that works, though the code doesn't work for some other unknown
reasons now, probably due to something along the line of things Olaf was
talking about recently.  Thanks!

Can you send me a diff against the current Benh kernel?
I just inserted these (useless) printk() to a non called function and
now it works so far for me.

find_pci_device_OFnode(unsigned char bus, unsigned char dev_fn)
{
/*      char blubber[60] = ""; */
        struct device_node* np;
        unsigned int *reg;
        int l;
/*      printk("I am just a dummy ...\n");  */
        for (np = allnodes; np != 0; np = np->allnext) {
                int in_macio = 0;
                struct device_node* parent = np->parent;
                while(parent) {
                        char *pname = (char *)get_property(parent, "name", &l);
        printk("I am just another dummy ...\n");
        printk("I am just another dummy ...\n");
                        if (pname && strcmp(pname, "mac-io") == 0) {
                                in_macio = 1;
                                break;
                        }

Bit ugly.


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Sun, 6 Aug 2000, Olaf Hering wrote:

Can you send me a diff against the current Benh kernel?

You mean his 2.2.x tree?  Or does he have 2.4.x tree somewhere?  I'm only
working with 2.4.x.

I just inserted these (useless) printk() to a non called function and
now it works so far for me.

find_pci_device_OFnode(unsigned char bus, unsigned char dev_fn)
{
/*      char blubber[60] = ""; */
        struct device_node* np;
        unsigned int *reg;
        int l;
/*      printk("I am just a dummy ...\n");  */
        for (np = allnodes; np != 0; np = np->allnext) {
                int in_macio = 0;
                struct device_node* parent = np->parent;
                while(parent) {
                        char *pname = (char *)get_property(parent, "name", &l);
        printk("I am just another dummy ...\n");
        printk("I am just another dummy ...\n");
                        if (pname && strcmp(pname, "mac-io") == 0) {
                                in_macio = 1;
                                break;
                        }

Bit ugly.

I bet you get the same effect (working kernel) by placing the printk()s
elsewhere.  I know something strange (to me) is going on, but I haven't
found anything wrong in objdump of prom.o.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/