Dual data pointer registers problem

Wow. It's just amazing how a thread can develop during your drive home from work.

This thread has been hopelessly hijacked, and as usual became a much more interesting thread :)

Erik Malund said: "There are about 4711 "given derivatives" with about 47111 'unique features' and to support them all is not feasible with the size of the '51 market. "
I can appreciate your point, but I think you are missing one thing here that I want to make clearer: Nobody is demanding full simulation for every of the many 8051 derivatives on the market. That has never been said in this thread. My whole point is that, If you decide to provide simulation support for a chip feature, then you must do it faithfully. There are many chips that are not fully simulated, with several peripheral subsystems that are simply not simulated. That's not so big a problem, and is normally noted in the model implementation notes. HOWEVER, if a feature is implemented, then it must be implemented right, or else you just can't rely on the tool you are using. That is a bug. And this is ok also, because every software or firmware has bugs. Hopefully, the vendor will come up with a future software release that fixes the bug.

What I don't agree in Erik statements is that one should be 'grateful' for the toolset functionality, and simply ignore the bugs. The companies I worked for have spent tens of thousands of dollars on Keil tools every few years to purchase development tools that were believed solid and dependable. Surely we have not counted on Keil's benevolence or goodwill, but on their craftsmanship and keenness. We must depend on their products to make our products to ship with less bugs.

But there is an inversion of values here: we do not expect to have rights on a perfect product because we have paid for it. On the contrary, we decide to buy it because we have evaluated it, and decided that despite the few bugs, it is worthy. Product excellence comes before the purchase decision. And that is all about it: should it be discovered later that it is an empty promise, and a better alternative available, customers would not buy it for the next system development. On that perspective, I would definitely question the decision to purchase a toolset that has a very poor quality for the evaluation and educational versions.

As a matter of fact, that is not what happens to Keil tools. They have their idiosyncrasies, a few nasty bugs, sometimes questionable optimizer code, but that is just the drill on every dev toolset that will ever be. Fact is that we have been using Keil tools for quite a long time, and have been able to ship quite large firmware written with it.

Wow. It's just amazing how a thread can develop during your drive home from work.

This thread has been hopelessly hijacked, and as usual became a much more interesting thread :)

Erik Malund said: "There are about 4711 "given derivatives" with about 47111 'unique features' and to support them all is not feasible with the size of the '51 market. "
I can appreciate your point, but I think you are missing one thing here that I want to make clearer: Nobody is demanding full simulation for every of the many 8051 derivatives on the market. That has never been said in this thread. My whole point is that, If you decide to provide simulation support for a chip feature, then you must do it faithfully. There are many chips that are not fully simulated, with several peripheral subsystems that are simply not simulated. That's not so big a problem, and is normally noted in the model implementation notes. HOWEVER, if a feature is implemented, then it must be implemented right, or else you just can't rely on the tool you are using. That is a bug. And this is ok also, because every software or firmware has bugs. Hopefully, the vendor will come up with a future software release that fixes the bug.

What I don't agree in Erik statements is that one should be 'grateful' for the toolset functionality, and simply ignore the bugs. The companies I worked for have spent tens of thousands of dollars on Keil tools every few years to purchase development tools that were believed solid and dependable. Surely we have not counted on Keil's benevolence or goodwill, but on their craftsmanship and keenness. We must depend on their products to make our products to ship with less bugs.

But there is an inversion of values here: we do not expect to have rights on a perfect product because we have paid for it. On the contrary, we decide to buy it because we have evaluated it, and decided that despite the few bugs, it is worthy. Product excellence comes before the purchase decision. And that is all about it: should it be discovered later that it is an empty promise, and a better alternative available, customers would not buy it for the next system development. On that perspective, I would definitely question the decision to purchase a toolset that has a very poor quality for the evaluation and educational versions.

As a matter of fact, that is not what happens to Keil tools. They have their idiosyncrasies, a few nasty bugs, sometimes questionable optimizer code, but that is just the drill on every dev toolset that will ever be. Fact is that we have been using Keil tools for quite a long time, and have been able to ship quite large firmware written with it.