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));
"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! ;-)