| ??? 03/03/09 18:52 Read: times |
#163027 - It is not that clean and clear Responding to: ???'s previous message |
Andy Neil said:
I said:
Any 'C' compiler that claims to support the 8051 architecture but doesn't provide an easy, direct way to access all of the 8051's memory areas really isn't worthy of the name - and should be ditched! If a compiler that claims to support the 8051 architecture doesn't give you 'C' language acces to the 8051's memory spaces - ie, XDATA, CODE, DATA, IDATA, SFR - then it's pretty worthless for 8051 development. I didn't say that it had to provide access to all features - and I didn't mean to! The beauty of the 8051 architecture is that this is pretty much the only language extension that is required - because everything is effectively memory-mapped, once you have that, you do inherently have access to all the MCU's features. (I'm including SFR space as a "memory space" here). That's as good an approach as any. Richard Erlacher said:
That's because the authors seldom know, particularly in advance of their development, what the MCU's features are. They don't need to - since the instruction set and memory spaces remain the same. Many of them have on-chip XRAM, but it's enabled/disabled in different ways. But it's just a matter of appropriately accessing the appropriate SFRs - so, again, once you have that support, there's nothing else required of the compiler And, without that support, the compiler is, indeed, useless. Yes, but that's where it becomes messy ... How many of them support the use of both data pointers on MCU's that have them? Again, it's mostly just a matter of manipulating an SFR - so no problem provided that's there. How many support the MAC in the some of the SiLabs parts? Isn't that just a matter of more SFRs? Have you looked at that MCU series, and how they handle SFR paging? How many support the use (read/write) of internal FLASH? Some of them do; in others, it's just one of those things not suited to HLL Well, as you probably know, I'm not convinced that HLL's in general are suited to the task of programming microcontrollers, particularly those with small code and data memory resources. As it happens, the one 805x-family member that I find particularly interesting has features that have no support from the popular 'C' compilers at all. It has dual data pointers and many extremely useful things can be done much better using the pair rather than one at a time, yet 'C' compilers don't really allow for convenient specification of which DPTR is used for which task, nor do they support matters such as use of internal XRAM for one function, while using external XRAM located at the same address for others. These functions are manageable in ASM because it's easy to set the SFR enviroment for each function with a minimum of overhead. That's not the case with the generic MCU 'C'-compiler. Moreover, the ones that handle the MCU features well, don't handle ALL the available MCU features well, hence, force you to deal with them in ASM anyway. By the time I finish with such tasks, I find it better, with code that's smaller and faster, not to mention much easier to understand, once one has grasped the architecture of the task, if the entire thing is written in ASM with generous application of macros. perhaps 'C' will allow you to do it, too, but, after all, it's going to take 10x as much effort, and will be 10x as large, and 10x as slow That's not necessarily true in general, and is complete nonsense in the specific case at hand here; ie, accessing XDATA from 'C'. Accessing XDATA in Keil 'C' is a lot less effort for the programmer, and no more effort or code size for the processor. That is undoubtedly true for the degenerate case, where there's only one block of XRAM, internal or external, but, what about the DS89C4x0's, which have 1 KB of internal XRAM and also can access 64KB of external XRAM as well. The internal XRAM is located at 0x0000. If you define a variable to be in one location, how do you use that same physical address when it's in external memory? Can you make Keil's 'C'-51 aware of this? How would you copy from internal space at 0x0000 to external space at 0x0000 or vice-versa in 'C'? (Do You see what I mean about messy?) When your code size is very small, say, 2-3 KB, yet your table space is quite large, say, 56 KB, the overhead imposed by a HLL compiler can impose a significant cost in performance and in code size. It doesn't matter in such a case, where the memory resides, but once things get just a bit off-center, as they often do with the wide diversity of MCU's and features within them, which make us choose one MCU variant over another, things are no longer so simple. Yes, HLL's make the code more maintainable, but that's only true if the code is very thoroughly documented, and a line of 'C' often requires more doc than a line of ASM. Even then, there's no real guarantee that the "next guy" will bother to learn anything substantial about the specifics of the MCU in question, at least until circumstances force him to do so. Just look at the many complaints about 'C' code that doesn't work because the coder hasn't read and understood the MCU datasheet that we see here! MCU programmers should have their MCU architecture in memory, right down to the SFR bit definitions, and certainly including all of the instruction set. If they have that level of familiarity, I believe they can do the job MUCH better in ASM than they could in any HLL. RE |
