This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Time to update your compiler

It's time to do some work on you're compiler. It generates the same code it did 20 years ago. I have to do tricks, instead of writing normal portable code, to get it to generate good code or just use inline assembler. This of course is nothing new, I've been telling you this for almost a decade. Keep in mind that all Intel processors are little endian and that you're compiler generates big endian code, why? You should at least offer a compiler switch to select endianness. Why don't you support C++ and MISRA? Oh and BTW IAR does all of the above TODAY! So clearly they haven't been standing still. (Notice who wrote the paper.)

www.eetimes.com/.../The-Inefficiency-of-C--Fact-or-Fiction-

Parents
  • If you want optimum code out of Keil you don't have a choice but to deal with DPTR.

    I asked for a demonstration of necessity of two things, and you answer with a vague claim regarding only one of them. why even bother? Is it really that hard to just admit that you're wrong?

    I'll repeat: DPTR is not little-endian in any meaningful way. There's nothing you can do with DPH and DPL that would change in any way if their locations were exchanged --- or, for that matter, if they were moved to completely random locations each.

Reply
  • If you want optimum code out of Keil you don't have a choice but to deal with DPTR.

    I asked for a demonstration of necessity of two things, and you answer with a vague claim regarding only one of them. why even bother? Is it really that hard to just admit that you're wrong?

    I'll repeat: DPTR is not little-endian in any meaningful way. There's nothing you can do with DPH and DPL that would change in any way if their locations were exchanged --- or, for that matter, if they were moved to completely random locations each.

Children
No data