We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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));
For a bit of amusement I compiled the following code under v7.01 optimisation level 9:
unsigned char data *my_data_memcpy(unsigned char data *dest, unsigned char data *src, unsigned char n) { unsigned char data *temp=dest; while(n) { *temp=*src; temp++; src++; n--; } return(dest); }
Ah, yes, sometime I just cannot helpmyself from getting into assembler... In fact, the C version could probably be slightly improved by using
do { ... }while(--n != 0);
"Finally I also noticed that the return(0); in Graham's function generates a MOV R7,#00H instruction as well as a RET, which is a shame." Like I always say: if you need some assembler, have it properly as an assembler module - don't mess about with inline assembler in 'C' source files! Graham's function actually contains four lines whose sole function is to suppress compiler warnings. Luckily, the compiler happens to be smart enough to spot that the 1st three are irrelevant, and optimises them out. That just leaves the "spurious" RET. Using the SRC directive is a great way to create 'C'-compatible assembler source - with all the right calling & naming conventions, parameter passing, etc - but once you've done that, the 'C' file is of no further use; so throw it away!
Maybe a bit off topic, but I just wanted to share a thought. Take a look at the webpage of a new programming language called D: http://www.digitalmars.com/d/overview.html Here is a quote: Modern compiler technology has progressed to the point where language features for the purpose of compensating for primitive compiler technology can be omitted. (An example of this would be the 'register' keyword in C, a more subtle example is the macro preprocessor in C.) We can rely on modern compiler optimization technology to not need language features necessary to get acceptable code quality out of primitive compilers. Yet a lot of discussions around the use of C in microcontroller programming boil down to how to get more optimal code from a particular C compiler. Is it that Keil's compilers have not caught up with the latest and greatest in compiler technology? Or am I too picky? - mike
Is it that Keil's compilers have not caught up with the latest and greatest in compiler technology? Can you give me an example (manufacturer and version) of a compiler that is the latest and greated in technology. That way, I can let you know if we've caught up with them. Jon
"Or am I too picky?" You're too picky. In my opinion: If you have to use assembler rather than 'C' for reasons of code size or speed then you're using the wrong hardware. The only case I can really see for using assembler is when you need to make sure the code doesn't change across compiler versions.
Yes, I agree, statements like these have to be supported by facts. I use the C166 compiler, and there are not too many compilers for that architecture. And from what I heard Keil's C166 is the best available. But what I meant was that so many times when I look at the code generated by C166 I can't help but notice so obvious optimizations not performed by the compiler. Let's look at a real-world example:
#include <intrins.h> long l[2]; long read_long_atomically(int i) { long tmp; long *ptr; ptr = &l[i]; _atomic_(0); tmp = *ptr; _endatomic_(); return tmp; } Compiler listing: MOV R5,R8 SHL R5,#02H MOV R4,#l ADD R4,R5 ATOMIC #02H MOV R6,[R4] MOV R7,[R4+#02H] MOV R4,R6 MOV R5,R7 RET
SHL R8,#4 ADD R8,#l ATOMIC #02H MOV R4,[R8] MOV R5,[R8+#2] RET
In this case, I agree with you. However, most functions are not quite that trivial. It's easy to create the perfect optimizing compiler if you guarantee that all function it compiles are small and are not too complex. The problem arises when you have functions that are insanely complex. Then, the compiler still must do a good job. As it is, the small functions like you demonstrate would be the ones that I would first write in C (to get working) and later go back in write in assembly (if needed). Jon
"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.
It's easy to create the perfect optimizing compiler if you guarantee that all function it compiles are small and are not too complex. I'm sure a lot of users would appreciate a compiler command line option called "perform near-perfect optimization on simple functions". If it's easy, why not do that? I seem to remember that the OpenWatcom compiler even allows the user to specify the amount of virtual memory to use in optimization. Basically the amount of available memory pretty much determines how good a job the compiler does at optimizing complex functions. Ah, well... - mike
"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! ;-)