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, see 68008 and 8088 as examples."
Bad example. If you take an 8088 it has an 8-bit bus. But 16-bit instructions. One single instruction will perform a 16-bit read or write because it is not an 8-bit processor. It's a 16-bit processor with an 8-bit wide data bus from the memory controller.
68008 isn't an 8-bit processor either.
And returning to your previous claim about byte order of the jump address for a 3-byte instruction. Most processor have fixed op-code lengths. So they may have a 16-bit opcode and 0, 2 or 4 byte data following. Then that data will be aligned and have a well-defined endianness.
For the 8051 you decided to group the one-byte opcode with the first byte of the address. Let's continue then with your 8088 that you decided is ok as a good processor to compare with. The 8088 has op-codes of varying length - one of the reasons it gains very good code density. But many of the opcodes have extension bytes. For example to switch from the DS segment to ES. Would that extension byte then suddenly change the processor between big-endian and little-endian? Must be so, since you think you can group individual bytes two-and-two and have the first byte of the op-code the low byte of a little-endian number while the first byte of a following number will be the big part to group with the opcode.
Little or big-endian does not care about the byte order in the opcode. It is only a question of how a larger register is read/written to memory. As soon as you can't perform a 16-bit memory transfer, then the processor core lost the ability to have an endianness.
When it comes to things like 16-bit timers on an 8-bit processor without 16-bit read/write, the chip designer may have many reasons for selecting the byte order of the individual 8-bit registers. If a write to the low byte starts a timer, then the code must write high byte before low byte. If a write to the high byte stats the timer, then the code must write the low byte first. But that is issues outside the scope of the processor being big or little-endian.
But this all started with a talk about efficiency. Where is the efficiency?
If I write:
SFR_LOW = my_16_bit & 255; SFR_HIGH = (my_16_bit >> 8) & 0xff;
or
SFR_HIGH = my_16_bit / 256; SFR_LOW = my_16_bit & 256;
SFR_16 = my_16_bit;
the compiler should be able to perform the writes with the same efficiency. Splitting the 16 bits into two bytes is easy to detect, and it shouldn't matter if shifts, logic-and, modulo or div is used. And the register write is still two 8-bit accesses.
But when writing to a 16-bit timer register where a specific byte starts the timer, or latches the other byte into a temporary buffer, a global compiler switch can't help you with the specific byte order used by that specific timer register implemented by that specific chip vendor. But a developer writing portable code and coding two 8-bit reads or writes will get the correct result.
Sharing binary structures with a PC program? Each individual C compiler has different alignment rules. You might play with __packed or similar on the PC. But it is just so trivial to write protable code:
p = get_8(p,&my_8_bit_field); p = get_16(p,&my_16_bit_field); p = get_8(p,&my_second_8_bit_field);
Didn't take any real time to code. Does work with any C compiler. Does work even if the PC is replaced by a PDA with a 68000 processor or a smartphone with an ARM.
With 25+ years of experience, you should know that the PC can swallow all info the 8051 can send, and decode the data many times faster than the 8051 can produce it.