Re: So What

All that hot air and rambling, but you still fail to say anything of any value.

My five year old daughter can produce far more cogent arguments with far less words.

Let's take an engineering approach to all of this - can you summarize in exactly two short sentences what you actually expect Keil to do, given that you were told by people that I consider informed that the endiness issue is not relevant. By the way, I was not impressed by that article you posted a link to - I wouldn't use a language such as C++ in a mission critical system UNLESS I trust myself and my colleagues to be C++ experts. There are so many pitfalls in the way of a novice, that it is just a bad idea (I think). I also did not understand why you implicitly associate code quality with C++ - use PC-lint - a great tool that I use at work - and forget about it.

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

they woukld be if the '51 had 16 bit memory acces, but sice it doesn't the is no endianness.

If this had been e.g. the XA then RCAP2 would have an endianness, but for the '51 it is two separate bytes and thus no endianness applies.

Erik

they woukld be if the '51 had 16 bit memory acces, but sice it doesn't the is no endianness.</>

Endianness is independant of memory access width, see 68008 and 8088 as examples.

I've already done that:

I would like a compiler flag to select endianness as well as C++ enhancements that make sense.

I have PC-Lint, it's ok but it's an extra step and it doesn't get you C++ classes, polymorphism, encapsolation, overloading, strong type checking and inline functions to name a few.

Just take a look at 'Embedded C++ Technical Committee Draft, Version WP-AM-0003, 13 October 1999'
www.caravan.net/.../

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.

That's 4 lines of information that has nothing to do with the question I asked, where a simple "No." would have sufficed.

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).

Correct in itself, but completely unrelated to endianness. Alignment is one thing, and endianness is another.

let's see that's low byte at lowest address, high byte at highest address, oh yeah little endian.

It would be if there were two ways to address the same data, both as bytes and as bigger units. As-is, the numerical values of SFR addresses are utterly irrelevant in an 8051, because you can't do any useful computations on them. That's direct addressing for you.

Yes it is critical to put the low byte into the low register and the high byte into the high register or your program
Of course it is --- but that has nothing to do with endianness. This is about the function of the SFR, not its address. The code would work and look exactly the same if the address of TH0 were lower than that of TL0.

It would be unprofessional to disclose

So the way you're "disclosing" the name of tool vendors in here is what you consider the zenith of professionalism, in comparison. Really? Well, somehow that figures.

I know of no Intel part that was not little endian
Oh, but you do! You just resolutely ignore the fact that the 8051 is exactly that, because it is effectively no-endian. The very fact that it's even possible for a tool vendor to make their C compiler big-endian is a strong hint about that --- but of course there's no way you could ever admit that.

Just take a look at 'Embedded C++ Technical Committee Draft, Version WP-AM-0003, 13 October 1999',

Why would anybody want to look at an 11 year old failed initiative that has been dead in the water for 8 of those years?

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

"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;

or

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.

"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.

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.

I think congratulations are in order - while you don't quite win the prize for 'most imaginitive fantasist of the month' you certainly top the recent entires in the 'I got caught out talking rubbish but I'll doggedly defend it' category.

Well done!

From our friends at cygnal(now si labs)

But wait, there's more. The 8051 family CPU designers also had a choice to make regarding 16 bit quantities, namely addresses. Maybe you care, maybe not. But for completion, 16 bit addresses (targets of LCALL/ LJMP) are stored BIG endian in code space. Those same addresses are stored LITTLE endian on the STACK. Go figure."

www.cygnal.org/.../000603.html

So is it big endian or little endian? It is both. Everyone wins.

So the compiler companies get to pick what they want, and stick with it.

Let us all go home happy.