We are using Keil C-51 V7.06. There is a structure defined:
typedef struct { unsigned char address_bus_h; unsigned char address_bus_l; unsigned char data_bus; }instbus_raw_t;
instbus_raw.address_bus_h = instbus_raw_local.address_bus_h; instbus_raw.address_bus_l = instbus_raw_local.address_bus_l; instbus_raw.data_bus = instbus_raw_local.data_bus;
memcpy(&instbus_raw,&instbus_raw_local,sizeof(instbus_raw_t));
void *(my_memcpy)(void *s1, const void *s2, size_t n) { char *su1 = (char *)s1; const char *su2 = (const char *)s2; for (; 0 < n; --n) *su1++ = *su2++; return (s1); } my_memcpy(&instbus_raw,&instbus_raw_local,sizeof(struct instbus_raw_t));
"If you have to use assembler rather than 'C' for reasons of code size or speed then you're using the wrong hardware." As I've said before, all generalisations are bad! ;-) IF you are making extremely cheap products in extremely large volumes, the development costs are secondary to the component costs. In such cases, you want the cheapest processor you can possibly find - and you can afford to put in a bit more development effort to squeeze the last ounce of performance, or shoe-horn the code into the smallest possible ROM. However, I do agree that most of the questions here about inline assembler are due to misconceptions...
The only case I can really see for using assembler Sometimes you need to poke around in assembler for some glue logic in startup code before main can even get going. Say, boot code loading an application and restarting into it, or initializing bank switch logic, or that sort of thing. C presumes a certain environment exists, and somethings you need to do things outside of that world's "laws of physics". Other times, you might need assembler to cope with some picky hardware. C doesn't always give you precise control over which bits change at which address on which clock cycle. Speed and efficiency count, too. Often, there's just a couple of routines that can greatly benefit from specialized assembler, and just throwing a bigger processor at the whole project for the sake of a couple of functions is not really the right answer.
"Sometimes you need to poke around in assembler for some glue logic in startup code before main can even get going." Sure, sorry, my comments were really in the context of calling hand optimised assembler routines from 'C'. "Other times, you might need assembler to cope with some picky hardware. C doesn't always give you precise control over which bits change at which address on which clock cycle." Well, I'd argue that this sort of thing shouldn't be done in software - chuck in a PLD or some such to move the timing burden to hardware. "Speed and efficiency count, too. Often, there's just a couple of routines that can greatly benefit from specialized assembler, and just throwing a bigger processor at the whole project for the sake of a couple of functions is not really the right answer." Yes, but as we've seen in this thread the speed and efficiency gains can often be made by rewriting [an existing library function, say] code in 'C' - there may be little to be gained from the move to assembler. Outwith minor modifications to startup.a51 I can only think of one occasion I've had to use assembler on the 8051, and that was to call functions in an on-chip bootloader that required certain values in certain registers. While it was possible to do it in 'C' it fitted into the 'maintain the same code across compiler versions' category. I also take Andy's point about low value high volume product, I've always been fortunate enough to work on high value kit where component cost isn't much of an issue, so I tend to overlook this.
"I also take Andy's point about low value high volume product, I've always been fortunate enough to work on high value kit where component cost isn't much of an issue, so I tend to overlook this." Actually, so do I! But I've been picked up on it a number of times now, so I thought I'd just get my own back! ;-)