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.
Care giving a citation of an actual statement by Intel, about the MCS51 architecture, that backs up your claim? What is your problem? Have you ever read a data book from any manufacturer of an 8051 device? There are dozens of manufactures that have made 8051s and hundreds of versions of the part. A part may be an 8051, 8052, 80C51, 80C52, 8031, 8032, 80C31, 80C32, 8751, 87C51, 87C51... but they are all still 8051's at heart.
Nonsense. The vast majority of 8051 registers are single bytes. Endianness can't even be defined for those. So much for "all registers".
It would seem basic electronics is beyond you, READ up on endianness it is not exclusive of 8-bit data or address space. Least significant applies to bits, nibbles, bytes etc. For little endian the least significant bit has the lowest address (even), the least significant byte has the lowest address (even). For a multibyte word an even address (modulo the word size) can be a byte or word address while an odd address can only be a byte address (although there are a very few ISA that can violate this general rule).
capture 2, timer/counter 2 No such thing on an actual 8051. I'm sorry, I thought I was hoping you were someone intellgent that can grasp that when referring to the 8051 I meant the whole family not just the differences between an 8051 and an 8052 or an 8031 and 8032. RCAP2L (0xCA even, AKA low byte) RCAP2H (0xCB, AKA high byte) have always been in the 8052 (as well as TL2 0x8C, TH2 0x8D).
timer/counter 0-2 Care explaining how a 16-bit timer stored in SFR addresses 8A and 8C (with a rather unrelated other SFR in between, at 8B) is little endian in any "CRITICAL" way?
TL0 0x8A, TL1 0x8B, TH0 0x8C, TH1 0x8D, RCAP2L 0x8A, RCAP2H 0x8B, TL2 0x8C, TH2 0x8D, DPL 0x82, DPH 0x83, P0 0x80, P1 0x90, P2 0xA0, P3 0xB0, ACC (or A) 0xE0, B 0xF0 ... let's see that's low byte at lowest address, high byte at highest address, oh yeah little endian. The addresses are always increasing for the higher register in the pair. They aren't always sequential because of address decoding and limited transistor count when the parts first came out but it all makes sense. And the grouping of TL0, TL1, TH0, TH1 make perfect sense when you're writing to them because of the way they operate. Yes it is critical to put the low byte into the low register and the high byte into the high register or your program will not operate as intended except when the low and high bytes are the same. And again, yes all those register are in there.
Which of the roughly 500 different data books describing 8051 variants in particular?
Pick one, they're all basically the same but I prefer Intel ones.
Oh, right, you wont't/can't divulge the particulars. Sure. And just because you're paranoid doesn't mean THEY are NOT out to get you. It would be unprofessional to disclose, but that's probably beyond you too.
forces little endian alignment Nobody can force that, because that's a meaningless combination of words. Only to you who doesn't understand endianness.
So do you work for Keil and are the person that got it backwards in the first place and are now trying to defend that mistake?
A couple posts before you were trying to discredit me as being too young to know what big-/little endian is about, and now I'm supposed to be none less than the Evil Mastermind that ruined your world? Could you make up your mind? It was just a question to hopefully explain your delusions. Mastermind, you? Never.
Did it ever occur to you that if all the world disagrees with you, this might be because you're plain and simply wrong? They don't, try reading.
I know of no Intel part that was not little endian. They have made parts that can do both little endian and big endian because they were going after the 68K and PowerPC controlled networking segments which incidendtly are big endian because of the TCP/IP protocol stack. But it would be crazy to think they would make parts that couldn't talk to each other in their native endianness. The x86 and 8051 play just fine together when you don't use Keil's compiler but when you do you have to byte swap all multibyte data elements. It's not too much to ask that Keil have a switch for endianness since they don't do it properly by default. It's not difficult to do and other 8051 compilers are either little endian or both.
There is no need to reply, I won't repeat myself yet again for you. I'm done with your belligerent lack of understanding. I don't care if you're an ignorant user or an incompetent employee. I was assuming this forum was for advancment of the tools and not endless rhetoric.
Endianness is independant of memory access width if so, what is the endianness of 1 bit wide memory access?
Leaving that alone, ONE byte has NO endianness, and if all you can get is ONE byte then plain logic tell you that what you get has no endianness.
If you could access e.g. T0 as 16 bits there would be endianness, but you can't.
BTW the SFRs are NOT memory they are 'memory mapped I/O' so T0 is a straight 16 bit counter, an neither you nor I have any idea what its 'endianness' is in the internal logic of a given derivative.
Erik
"Leaving that alone, ONE byte has NO endianness, [...]" Watch out. There is byte endianness - the traditional big-endian and little-endian - but there is also bit endianness, normally called bit numbering.
But the trap here is to assume that they are related and need to follow each other. Some big-endian processors numbers bits from most significant to least, while some numbers them from least significant to most. In short - bit numbering should not be used as any argument for byte order endianness.