<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Re: So What</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/26961/re-so-what</link><description> 
 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</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Re: So What</title><link>https://community.arm.com/thread/58697?ContentTypeID=1</link><pubDate>Sat, 02 Oct 2010 20:14:10 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:804fc9fd-dccf-4010-9e0b-e0f050a428b3</guid><dc:creator>Teeb E</dc:creator><description>&lt;p&gt;&lt;p&gt;
From our friends at cygnal(now si labs)&lt;/p&gt;

&lt;p&gt;
But wait, there&amp;#39;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.&amp;quot;&lt;/p&gt;

&lt;p&gt;
&lt;a href="http://www.cygnal.org/ubb/Forum4/HTML/000603.html"&gt;www.cygnal.org/.../000603.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
So is it big endian or little endian? It is both. Everyone
wins.&lt;/p&gt;

&lt;p&gt;
So the compiler companies get to pick what they want, and stick
with it.&lt;/p&gt;

&lt;p&gt;
Let us all go home happy.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Re: So What</title><link>https://community.arm.com/thread/58695?ContentTypeID=1</link><pubDate>Tue, 28 Sep 2010 05:20:33 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:1f4ffaff-06f8-4ecb-a94e-8f64919bf8bc</guid><dc:creator>Jack Sprat</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;There is no need to reply, I won&amp;#39;t repeat myself yet again for
you. I&amp;#39;m done with your belligerent lack of understanding. I don&amp;#39;t
care if you&amp;#39;re an ignorant user or an incompetent employee. I was
assuming this forum was for advancment of the tools and not endless
rhetoric.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I think congratulations are in order - while you don&amp;#39;t quite win
the prize for &amp;#39;most imaginitive fantasist of the month&amp;#39; you certainly
top the recent entires in the &amp;#39;I got caught out talking rubbish but
I&amp;#39;ll doggedly defend it&amp;#39; category.&lt;/p&gt;

&lt;p&gt;
Well done!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Re: So What</title><link>https://community.arm.com/thread/116037?ContentTypeID=1</link><pubDate>Mon, 27 Sep 2010 01:23:39 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:0396b6b2-9274-46c2-a155-fce9334a4de3</guid><dc:creator>Per Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
&amp;quot;Leaving that alone, ONE byte has NO endianness, [...]&amp;quot;&lt;br /&gt;
Watch out. There is byte endianness - the traditional big-endian and
little-endian - but there is also bit endianness, normally called bit
numbering.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Re: So What</title><link>https://community.arm.com/thread/104268?ContentTypeID=1</link><pubDate>Mon, 27 Sep 2010 01:19:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:1a711514-f1f6-41e0-b3a4-d24fc062f867</guid><dc:creator>Per Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
&amp;quot;Endianness is independant of memory access width, see 68008 and
8088 as examples.&amp;quot;&lt;/p&gt;

&lt;p&gt;
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&amp;#39;s a 16-bit processor
with an 8-bit wide data bus from the memory controller.&lt;/p&gt;

&lt;p&gt;
68008 isn&amp;#39;t an 8-bit processor either.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
For the 8051 you decided to group the one-byte opcode with the
first byte of the address. Let&amp;#39;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.&lt;/p&gt;

&lt;p&gt;
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&amp;#39;t perform a 16-bit memory
transfer, then the processor core lost the ability to have an
endianness.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
But this all started with a talk about efficiency. Where is the
efficiency?&lt;/p&gt;

&lt;p&gt;
If I write:&lt;/p&gt;

&lt;pre&gt;
SFR_LOW = my_16_bit &amp;amp; 255;
SFR_HIGH = (my_16_bit &amp;gt;&amp;gt; 8) &amp;amp; 0xff;
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
or&lt;/p&gt;

&lt;pre&gt;
SFR_HIGH = my_16_bit / 256;
SFR_LOW = my_16_bit &amp;amp; 256;
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
or&lt;/p&gt;

&lt;pre&gt;
SFR_16 = my_16_bit;
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
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&amp;#39;t matter if shifts, logic-and, modulo or div is used.
And the register write is still two 8-bit accesses.&lt;/p&gt;

&lt;p&gt;
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&amp;#39;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.&lt;/p&gt;

&lt;p&gt;
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:&lt;/p&gt;

&lt;pre&gt;
p = get_8(p,&amp;amp;my_8_bit_field);
p = get_16(p,&amp;amp;my_16_bit_field);
p = get_8(p,&amp;amp;my_second_8_bit_field);
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
Didn&amp;#39;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.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Re: So What</title><link>https://community.arm.com/thread/104263?ContentTypeID=1</link><pubDate>Sun, 26 Sep 2010 04:02:13 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e52de7b8-a454-4ae6-844a-eb8853dff1db</guid><dc:creator>&amp;#178;erik malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Endianness is independant of memory access width&lt;/i&gt;&lt;br /&gt;
if so, what is the endianness of 1 bit wide memory access?&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
If you could access e.g. T0 as 16 bits there would be endianness,
but you can&amp;#39;t.&lt;/p&gt;

&lt;p&gt;
BTW the SFRs are NOT memory they are &amp;#39;memory mapped I/O&amp;#39; so T0 is
a straight 16 bit counter, an neither you nor I have any idea what
its &amp;#39;endianness&amp;#39; is in the internal logic of a given derivative.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Re: So What</title><link>https://community.arm.com/thread/104269?ContentTypeID=1</link><pubDate>Sat, 25 Sep 2010 09:09:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:07d8a242-c254-40eb-9d42-9ddd7bbfc801</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Just take a look at &amp;#39;Embedded C++ Technical Committee Draft,
Version WP-AM-0003, 13 October 1999&amp;#39;,&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
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?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Re: So What</title><link>https://community.arm.com/thread/58694?ContentTypeID=1</link><pubDate>Sat, 25 Sep 2010 08:58:26 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:bfd2a810-cc0e-4145-bdc2-213eca4ed136</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&lt;b&gt;Care giving a citation of an actual statement by Intel,
about the MCS51 architecture, that backs up your claim?&lt;/b&gt;&lt;br /&gt;
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&amp;#39;s at heart.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
That&amp;#39;s 4 lines of information that has nothing to do with the
question I asked, where a simple &amp;quot;No.&amp;quot; would have sufficed.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;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).&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Correct in itself, but completely unrelated to endianness.
Alignment is one thing, and endianness is another.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;let&amp;#39;s see that&amp;#39;s low byte at lowest address, high byte at
highest address, oh yeah little endian.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
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&amp;#39;t do any
useful computations on them. That&amp;#39;s direct addressing for you.&lt;/p&gt;

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

&lt;p&gt;
&lt;i&gt;It would be unprofessional to disclose&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
So the way you&amp;#39;re &amp;quot;disclosing&amp;quot; the name of tool vendors in here is
what you consider the zenith of professionalism, in comparison.
Really? Well, somehow that figures.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;I know of no Intel part that was not little endian&lt;/i&gt;&lt;br /&gt;
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&amp;#39;s even possible for a tool vendor to make their C compiler
big-endian is a strong hint about that --- but of course there&amp;#39;s no
way you could ever admit that.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Re: So What</title><link>https://community.arm.com/thread/78670?ContentTypeID=1</link><pubDate>Sat, 25 Sep 2010 08:55:02 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:cb6d9978-5292-496a-80aa-fe60871e0b53</guid><dc:creator>Jay Dowling</dc:creator><description>&lt;p&gt;&lt;p&gt;
I&amp;#39;ve already done that:&lt;/p&gt;

&lt;p&gt;
I would like a compiler flag to select endianness as well as C++
enhancements that make sense.&lt;/p&gt;

&lt;p&gt;
I have PC-Lint, it&amp;#39;s ok but it&amp;#39;s an extra step and it doesn&amp;#39;t get
you C++ classes, polymorphism, encapsolation, overloading, strong
type checking and inline functions to name a few.&lt;/p&gt;

&lt;p&gt;
Just take a look at &amp;#39;Embedded C++ Technical Committee Draft,
Version WP-AM-0003, 13 October 1999&amp;#39;&lt;br /&gt;
&lt;a href="http://www.caravan.net/ec2plus/"&gt;www.caravan.net/.../&lt;/a&gt;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Re: So What</title><link>https://community.arm.com/thread/78671?ContentTypeID=1</link><pubDate>Sat, 25 Sep 2010 08:31:13 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:0a9f45b9-5443-46cd-8bdc-37ccb987b205</guid><dc:creator>Jay Dowling</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;they woukld be if the &amp;#39;51 had 16 bit memory acces, but sice it
doesn&amp;#39;t the is no endianness.&amp;lt;/&amp;gt;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;Endianness is independant of memory access width, see 68008 and
8088 as examples.&lt;/i&gt;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Re: So What</title><link>https://community.arm.com/thread/58693?ContentTypeID=1</link><pubDate>Sat, 25 Sep 2010 04:54:17 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:367aeb06-d4bb-4eb5-a656-e2b078009326</guid><dc:creator>&amp;#178;erik malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;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&amp;#39;s see that&amp;#39;s low byte
at lowest address, high byte at highest address, oh yeah little
endian&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
they woukld be &lt;b&gt;if&lt;/b&gt; the &amp;#39;51 had 16 bit memory acces, but sice
it doesn&amp;#39;t the is no endianness.&lt;/p&gt;

&lt;p&gt;
If this had been e.g. the XA then RCAP2 would have an endianness,
but for the &amp;#39;51 it is two &lt;b&gt;separate&lt;/b&gt; bytes and thus no
endianness applies.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Re: So What</title><link>https://community.arm.com/thread/58702?ContentTypeID=1</link><pubDate>Sat, 25 Sep 2010 04:14:48 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f3ee58b6-7446-4de8-86ee-f322fc5db5a4</guid><dc:creator>Tamiryan Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
Let&amp;#39;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&amp;#39;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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Re: So What</title><link>https://community.arm.com/thread/58704?ContentTypeID=1</link><pubDate>Sat, 25 Sep 2010 00:51:54 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3e0ad14c-88a3-4fd2-abdd-872fd7e315a1</guid><dc:creator>Big Yawn</dc:creator><description>&lt;p&gt;&lt;p&gt;
All that hot air and rambling, but you still fail to say anything
of any value.&lt;/p&gt;

&lt;p&gt;
My five year old daughter can produce far more cogent arguments
with far less words.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>