| ??? 03/04/09 00:10 Read: times |
#163044 - It's not what I'd choose, but it is a matter of perefernce Responding to: ???'s previous message |
Per Westermark said:
Richard Erlacher said:
The dual data pointers with automatic increment/decrement, and automatic alternation between them, if you want/need it, is not something I'd expect to see on an ARM anytime soon. Why do you think the ARM needs it? I didn't mean to imply that an ARM needs it. I simply said I didn't expect so convenient a feature to appear on an ARM. With every register a potential pointer, the compiler don't have to think single or double. It has nothing to do with single or double, but, rather with convenience and performance. The Maxim/Dallas part fetches a byte, and increments the pointer, all in 30 ns. The auto-alternate in the 8051 is smart, but it is a hack since the instruction set doesn't have any bit to select which register to use. Acually, it has an SFR that determines which to use, so a single instruction will do the trick. Further, there's a bit that makes it switch, automatically, between the two DPTR's on every use of DPTR. All real processors have indexed reads with automatic increment/decrement. Yes, but we're not talking "real" processors here ... we're talking microcontrollers. There are some things, however, that will likely cause 'C' and other HLL's to cough, for example moving an array from external XRAM to internal XRAM at the same physical address. I can't imagine am elegant way to do that in any HLL since it requires the pointers to have the same value and I'd expect the compiler to complain. Keil doesn't have support for it, but what you are talking about is basically the based pointers used by Borland to get a 16-bit near pointers that addressed code (__cs) or stack (__ss) which in the 16-bit and 32-bit segmented modes of the x86 processors do represent different memory areas with identical offsets. I didn't realize I was talking about that ... but neither of the data pointers is stack-related. This feature is on the Maxim/Dallas DS89C4x0, with either 16KB or 64KB of code space and 1 KB of on-chip XRAM. What a HLL can do is very much a factor of the ingenuity of the developers of the compiler, and the number of users paying for the compiler maintenance. Well, I doubt that using HLL produces much sensible code, though it might run after a bit of work, from the average 'C' programmer who could pull down a fancy salary working on PC's. These aren't PC's however. They're microcontrollers. Have a look at the code generated for a modern x86 processor. I don't think you would find it too funny to try and match it other than for very small code blocks. The big factor here is that the x86 market is huge, so the people with the good compilers have a lot of money available for development and testing. Keil charges a lot for their C51 compiler, but will still only collect peanuts compared to the x86 compiler vendors. And there is limited interest in investing too much into a compiler for a processor that has been on the market for so long as the 8051 has. It will continue to live for a lot of years more, but compiler vendors are looking at the new processors. I don't find HLL's appropriate for small code, and that's all that one can fit into a typical 805x. Now, If I use a port to expand the address space, even with the limitation that imposes, it might make sense to use HLL of one sort or another. The stuff I do is mostly tables. Those have to be generated before they're incorporated into the code set. The executable code is pretty small, seldom over 8K lines of ASM, and often much smaller. 'C' isn't going to allow me to time my code precisely, which is almost always a necessity, nor is it going to keep it small. I can't justify having a client pay for 10K copies of an MCU with 32 or even 64 KB of code space on-chip when a compiler produces 16385 bytes when I could write it in ASM and use no more than 16384. I can't justify using a loop that takes 20 microseconds to execute when I need, and easily could write one that takes 5. I doubt that happens all the time, but it has happened, and you can't predict it won't. RE |
