AVR Freaks

Seriously,  you must select your logic for what you want to do e.g.

if (value == 'a')
  do something;
if (value == 'b')
  do something;
...  

is different to

if (value == 'a')
  do something;
else if (value == 'b')
  do something;
else if ...

Using switch-case construct is if ... else if ... else ...

i.e. only one case is executed.

People worry about the "look".   Instead you should worry about the "logic"

The Compiler will do an excellent job in translating exactly what you asked it to do.

In your situation with multiple "consecutive cases" you will be amazed how well Compilers translate it.

David.

Punters do not have enough confidence in modern compilers.

GCC does an excellent job.   You should just give it straightforward code and it will generate efficient code.

Once you start tying its hands you will suffer.

Incidentally,  C compilers selected best code for switch in the 1980s.    And they have improved since then.

If you think you can do a better job,  study the generated ASM in a Simulator.   Danish people are very good at this.

David.

I occasionally stop by this sub-forum, but usually stay out of the discussions as I am a hacker at best, don't know C, and don't know much about structures and inheritance and this, that, and the other that real programmers know and understand well.

That said, it seems to me that one of the key differences between the long series of  If … Then … statements and the series of If … Else If … Else If … Else If … … Else … End If approaches is that the second method automatically incorporates a limit testing on the input variable, (A to H in this case).

The Else … section can automatically capture an error when the input is outside of the expected range.

Otherwise one might either have a separate valid range test before entering the block, or put a Flag within each If … Then... to indicate that at least one section of the code had successfully been executed.

Even though adding an instruction to set a Flag within each If … Then … would take 8 lines of code, (A through H), the execution time is minimal, as it is only actually executed once, for which ever section it actually processed.

Clearing the Flag at the start and testing it at the end would take a couple lines of code.

The Else If...  Else...  approach just handles that for you, automatically and seamlessly.

As the OP is interested in speed, one might expect the Else If to be a tad bit faster, (unverified, one would have to check the generated code), as a series of If … Then … have to set up the test for each test, while the Else If variant might well keep the comparison variable stored within a register and not have to keep setting it up for each test.

My last comment, before crawling back under my rock..., is just a reminder to the OP that it is generally best to get the overall program up and running, and then worry about optimizing bottle-neck sections of code, if needed.

Often times, at the end of the day, it just isn't needed or worth the effort.

Digital Signal Processing and Video GLCD driving are two obvious exceptions where highly optimized routines certainly come into play.

JC 

The big difference id that the Else If drop the rest of the IF's when it find a true If.

And by the way the  If … Else If … Else If … Else If … … Else … End (and the compare are known at compile time) , the GCC will make a switch case (with break).

 Danish people are very good at this.

No I guess I'm the only one :)

Ah, that'll teach me to stick my nose in where it doesn't belong.

I missed the "Default" block at the end, I guess I should have read the code more carefully.

And yes, the other nice feature about the Else If construct is the early exit from the long list of If Then's , once one is executed.

Basic has the same constructs.

If ... Then ...

If ... Then …, Else ...

If .. Else If … Else If … Else If …, etc. Else.

It also has a "Select Case" statement, similar to the Switch statement discussed above.

Except for all of those crazy braces and "double operators" I suspect the two languages are more similar than not.

I had to open my compiler's help and look for an On Goto statement.

In Bascom it is called On Value, (On variable Goto/Gosub label1 [, label2...] [, Check]

Interestingly, the [, Check] forces a check on the range of the variable and the number of subroutines to either Goto or Gosub, so that the stack isn't corrupted.

That must be a carry over from the earlier days of the compiler, as I can't, at the moment, think of other such cases within the language where the instruction itself has an optional error checking feature.

As the variable is 0 based, and I don't think setting the default base to 1, (Config Base instruction, (useful for arrays, sometimes)), changes that, I suspect that the On Value instruction was the source for many "bugs", and lead at some point to the range checking option.

Perhaps others use the instruction a lot, but I suspect it also might be an old instruction just given the Goto option for jumping about the code.

Perhaps the instruction was created when Gotos were still more commonly used.

I don't think I've used a Goto in years, and it seems there are other constructs that are available and easier to debug.

Live and learn.

I now know a smidgen more about C, and about another Basic instruction I've never used. 

Last comment for the OP, again, is that if the frequency of occurrence of the variable, A through H, is not uniformly distributed, then it makes sense to put the variable that occurs most often first in the list, to improve the speed of the program, (the stated goal).  i.e. if "C" occurs 1/2 the time, then make it the first variable tested, don't blindly put the variables in alphabetical order.

Somewhat off topic:

I am amazed at the number of instructions in Bascom, (and ZBasic).

My last project about filled at 32K chip, and I'll bet I used less than 10% of the available instructions, (or even less!).

While looking for anything with a Goto in it, I spotted LoadWordAdr, which loads the Z register and sets RampZ (if available).

That's another one I've never used, and haven't really got a clue as to when it might be useful.

Last comment, speaking of languages...

My next door neighbor is also a physician, a cardiologist.

The other day he asked me what I know about Phython, as he now wants to learn it.

He hasn't programmed since high school / college on his Atari system.

My Uncle, a retired radar engineer, is in his mid-80's and still programs in Fortran.

If I ever retire I'm going to be a very busy person, with a long list of projects to do, and a couple of languages to learn!

JC

There were lots of resulting "features" when you squeeze everything into an interpreter.

It was pretty clever that they managed to achieve such a lot with minimal RAM and ROM.   It was enough to impress the home computer enthusiast.

Nowadays you use the power of a PC to compile an efficient program that can run on the minimal RAM and ROM.

i.e. you use GB of resources to create a HEX that runs on a 2kB ATtiny25

David.

It's a little advanced, but you could use a table of function pointers.  This is from google result for "C language  table  function pointers"

Take your letter selection and subtract 0x61 to get an (zero-based) index that is based on the (lower-case) alphabetical letter; i.e. 'a'=0, 'b'=1, 'c'=2, etc...

This number is your jump index into a table of function pointers.   When you select "b", execution will jump to the code found at the beginning address of do_something_B.

void (*pf[])(void) = {do_something_A, do_something_B, do_something_C, do_something_D,

do_something_E, do_something_F, do_something_G, do_something_H };

void test(const INT jump_index)
{
    /* Call the function specified by jump_index */
    pf[jump_index]();
}

The above code declares pf[] to be an array of pointers to functions, each of which takes no arguments and returns void. The test() function simply calls the specified function via the array. As it stands, this code is dangerous for the following reasons.

• pf[] is accessible by anyone
• In test(), there is no bounds checking, such that an erroneous jump_index would spell disaster

A much better way to code this that avoids these problems is as follows

void test(uint8_t const ump_index)
{
    static void (*pf[])(void) = {fna, fnb, fnc, ..., fnz};

    if (jump_index < sizeof(pf) / sizeof(*pf))
    {
        /* Call the function specified by jump_index */
        pf[jump_index]();
    }
}

The changes are subtle, yet important.

• By declaring the array static within the function, no one else can access the jump table
• Forcing jump_index to be an unsigned quantity means that we only need to perform a one sided test for our bounds checking
• Setting jump_index to the smallest data type possible that will meet the requirements provides a little more protection (most jump tables are smaller than 256 entries)
• An explicit test is performed prior to making the call, thus ensuring that only valid function calls are made. (For performance critical applications, the if() statement could be replaced by an assert())

This approach to the use of a jump table is just as secure as an explicit switch statement, thus the idea that jump tables are dangerous may be rejected.

above is from   https://barrgroup.com/Embedded-S...

Kind of back to the thread

I remember that one of the C compilers for the 8051 (I think it was the BSO), (sometimes) implemented a hard to debug but efficient way (switch was on a 8bit var.):

It would add a constant so the result would give 0 if there was a match:

if first value to check for was 0x10 it would simply add 0xe0 (that is ok and simple).

if 2. value now was 0x30 it would add 0xf0 (because 0xe0+0x30+0xf0=0x(2)00 )   

etc.

Not directly related to this, but have just been watching Inventing the Impossible: The Big Life Fix  (on BBC2) people with interest in invention should see it.

It reminded me a bit of medical frontiers on NHK.  

And I will add:

And partly the instruction set it's compiled for.

Well, that might explain why vending machines are often so hard to use; designed by the client! I hate it when the client, instead of telling what it is supposed to do, tells me how to do it.

OK, so can I vent about another user interface on a home appliance?

We have a dish washer in the kitchen that is located under a counter, near the sink.

It has 12-15 push buttons across the front panel, (a single horizontal row across the front of the device).

What they are is written in a small font, and the front of the appliance is vertically oriented, not tilted up to read it.

Every time I want to turn it on I have to bend over and read the small fonts to push the wash mode and then the start button.

I'd put a big colorful mark on them, but I'm afraid my wife wouldn't like that option.

JC

Edit:

OK, so I'll admit, bending over to read the controls is a small price to pay so as not to have to wash and dry all of the dishes myself...

But really, how hard would it have been to have the control panel tilted upwards?

JC