Is there a robust way to implement an ASM table like structure in C

Papabravo

Joined Feb 24, 2006
22,083
I didn't say every situation is going to be like that. Did I?
....
It was an implicit statement. I have my own tales of unexpected and bizarre compiler behavior requiring unusual and counter intuitive workarounds. On the other hand I have written many thousands of lines of code that have compiled and executed reliably over many decades. I think you might be able to make a similar statement. I did say that one should verify their assumptions especially on a "new" piece of code or the use of a new revision of the compiler.
 

takao21203

Joined Apr 28, 2012
3,702
Use a lookup table

Code:
#include <stdio.h>
#include <stdlib.h>

int main(void)
{

   unsigned LATAbits = 0;
   unsigned LATBbits = 0;
   unsigned LATCbits = 0;

   unsigned *latch[] = {&LATAbits, &LATCbits, &LATBbits};
   unsigned  bits[]  = {  0,  7,  2};

   printf("A: %u\n", LATAbits);
   printf("B: %u\n", LATBbits);
   printf("C: %u\n", LATCbits);

   int phase = 1;
   printf("phase = %i\n", phase);

   *latch[phase] |= 1 << bits[phase];

   printf("A: %u\n", LATAbits);
   printf("B: %u\n", LATBbits);
   printf("C: %u\n", LATCbits);

   return EXIT_SUCCESS;
}
pretty much the only way to go if you deal with a larger number of IO ports.
It would be dirty like nothing to maintain a complicated mess of staggering gotos or switch statements.
Also as mentioned the execution time is different each.

I have used it sometimes, for instance when I want random IO ports and random external device, just configure all via tables.

Its a bit slow tough but depends on the individual IC. I can imagine on PIC32 its not neccessarily that slow. But couldnt verify as for now.
 

John P

Joined Oct 14, 2008
2,063
I really think that with a microcontroller, it's usually acceptable to put in a few lines of assembly code if the compiler isn't doing what you want. When I do this, I often include the equivalent C code as a comment, as a reminder of what's mean to be happening. The arguments for not working in assembly are as good as they ever were, but I wouldn't make a fetish of it. Tortured C syntax can be as confusing as assembly, anyway.
 

Thread Starter

Robin66

Joined Jan 5, 2016
281
You'd put in an adjustment of PCLATH and a series of BSF and GOTOs? Something along these lines?
Code:
asm("ADD PCLATH, phasex2 ,0");
asm("BSF LATA, 0");
asm("GOTO finished");
asm("BSF LATB, 7");
asm("GOTO finished");
asm("finished");
 
Last edited:

takao21203

Joined Apr 28, 2012
3,702
You'd put in an adjustment of PCLATH and a series of BSF and GOTOs? Something along these lines?
Code:
asm("ADD PCLATH, phasex2 ,0");
asm("BSF LATA, 0");
asm("GOTO finished");
asm("BSF LATB, 7");
asm("GOTO finished");
asm("finished");
Its perfectly possible and called computed GOTO.
Its also seen as hardcoded. Usually when libraries come into play, for a larger project or when you reuse the code,
later youll be confronted with a mess. The hardcoded values will be hidden somewhere and eventually the information how and why,
is either absent or hidden too.

Using tables you have it all in one place and usually in a separate file.
Moreover, it could be loaded from external sources.

Importantly, a hardcoded piece can not be changed by the user or only in a very cumbersome way (aka reprogramming executeable memory).
The table could be in RAM mind that, and be based on user input, and sometimes thats just what you need or it would be more desireable.

Also hardcoded will be different according to the IC but table interpreter will almost be all the same for different IC.
 

WBahn

Joined Mar 31, 2012
32,925
It was an implicit statement. I have my own tales of unexpected and bizarre compiler behavior requiring unusual and counter intuitive workarounds. On the other hand I have written many thousands of lines of code that have compiled and executed reliably over many decades. I think you might be able to make a similar statement. I did say that one should verify their assumptions especially on a "new" piece of code or the use of a new revision of the compiler.
It wasn't very strongly implied since I didn't say that this behavior WILL happen, did I? I said, quite explicitly, the RELYING on the compiler optimizations for critical pieces of code is dangerous and that it CAN cause problems.

You clearly have no problem with locking yourself, and anyone that ever maintains code that you've written, to a particular version of a particular compiler. Or with recommending that others blindly do the same. We can agree to disagree and let the TS choose which path they want to take.
 
Top