Hi. A question somewhat (or rather) silly: can I manipulate individual bytes with an ARM processor? (LPC213x to be more specific) In other words, will the statement: char buffer[16]; occupy 16 8 bit bytes or 16 32 bit words? TIA. Elder.
Does ARMs support bytes?
Started by ●March 8, 2005
Reply by ●March 8, 20052005-03-08
On 2005-03-08, Elder Costa <elder.costa@terra.com.br> wrote:> A question somewhat (or rather) silly: can I manipulate individual bytes > with an ARM processor?Yes.> (LPC213x to be more specific)I don't know for sure, but I'd be shocked if the answer was no.> In other words, will the statement: > > char buffer[16]; > > occupy 16 8 bit bytes or 16 32 bit words?The former. Wouldn't it have been easier to just compile it and see for yourself? -- Grant Edwards grante Yow! I'm a GENIUS! I at want to dispute sentence visi.com structure with SUSAN SONTAG!!
Reply by ●March 8, 20052005-03-08
Elder Costa wrote:> Hi. > > A question somewhat (or rather) silly: can I manipulate individual bytes > with an ARM processor? (LPC213x to be more specific) > > In other words, will the statement: > > char buffer[16]; > > occupy 16 8 bit bytes or 16 32 bit words?Bytes. cheers, Al
Reply by ●March 8, 20052005-03-08
Grant Edwards wrote:> On 2005-03-08, Elder Costa <elder.costa@terra.com.br> wrote: > > >>A question somewhat (or rather) silly: can I manipulate individual bytes >>with an ARM processor? > > > Yes. > > >>(LPC213x to be more specific) > > > I don't know for sure, but I'd be shocked if the answer was no. > > >>In other words, will the statement: >> >>char buffer[16]; >> >>occupy 16 8 bit bytes or 16 32 bit words? > > > The former. > > Wouldn't it have been easier to just compile it and see for > yourself?There is an issue in ARMS with efficent memory use, I think has to do with non aligned access, so an array of bytes is OK, but a RECORD that has mixed size types, may need to have packers. Their new cortex claims to be more efficent at RAM usage :) -jg
Reply by ●March 9, 20052005-03-09
In article <422e5278$1@clear.net.nz>, Jim Granville <no.spam@designtools.co.nz> wrote:> Grant Edwards wrote: > > On 2005-03-08, Elder Costa <elder.costa@terra.com.br> wrote: > > > > > >>A question somewhat (or rather) silly: can I manipulate individual bytes > >>with an ARM processor? > > > > Yes. > > There is an issue in ARMS with efficent memory use, I think has > to do with non aligned access, so an array of bytes is OK, but > a RECORD that has mixed size types, may need to have packers.I think you're getting confused about the capability of the core versus the constraints that the C compiler might choose to impose on structures versus what happens when you do unaligned loads. What follows does depend rather on the capabilities of the memory system in use (eg. you don't always have the luxury of individual byte strobes so it may not be possible to write a single byte), and the pragmas/compiler options (eg. you may have asked it to pack structs in order to save RAM at the expense of larger and slower code). I'll also apologise in advance about nonsense pseudo 'C'. For example if you have a structure along the lines struct { char one; long four; char array[3]; short two; } I'd expect that could take 16 bytes when there's only 10 useful bytes (38% waste) being stored as what would be implied is struct { char one; char padding[3]; long four; char array[3]; char padding; short two; short paddingtonextstruct; } The reason for the padding to 16/32 bit boundaries is to make the code required to access them simpler and faster. You might instead write, or get the compiler to shuffle to give struct { char one; char array[3]; long four; short two; } which is only 12 bytes (so 17% waste). If you remove all the packing, then non aligned half and word wide loads would need to be broken up into a set of LDRB's and ORR's/MOV's. Anyway, the point being that unless your memory system forbids it, or you have the "abort when unaligned access happens" turned on LDRB can load from any address, LDRH can load from any address on 16 bit alignment, LDR/LDM can load from any address on 32 bit alignment. There's a little extra fun with LDR where you can have unaligned loads proceed, but they barrel shift the bytes by 8 times the number that was in the bottom 2 bits of the address. A little light reading of the ARMARM will explain in more detail... Sprow.
Reply by ●March 10, 20052005-03-10
In article <396q68F5spq0jU1@individual.net>, Elder Costa <elder.costa@terra.com.br> wrote:>A question somewhat (or rather) silly: can I manipulate individual bytes >with an ARM processor? (LPC213x to be more specific) > >In other words, will the statement: > >char buffer[16]; > >occupy 16 8 bit bytes or 16 32 bit words?It'll occupy 16 8-bit bytes (or 4 32-bit words), but it's possible that a statement such as buffer[3] = x; will end up reading the 32-bit word containing that byte, modifying the word, and then writing it back. That is, the processor would have to read/write only aligned words, and do byte-level manipulation only on values in registers. I don't actually know if this is true for the ARM. It is true for some architectures and untrue for some other architectures. -- Wim Lewis <wiml@hhhh.org>, Seattle, WA, USA. PGP keyID 27F772C1
Reply by ●March 10, 20052005-03-10
Jim Granville wrote:> There is an issue in ARMS with efficent memory use, I think has > to do with non aligned access, so an array of bytes is OK, but > a RECORD that has mixed size types, may need to have packers. > > Their new cortex claims to be more efficent at RAM usage :) > > -jg >Hi there, You can do byte transfers in ARM cores. ARM11 already support unaligned data accesses. It is a part of the V6 architecture. The new Cortex cores will provide better code density and performance from the Thumb-2 instruction set. For more details see http://www.arm.com/products/CPUs/ARM_Cortex-M3.html and http://www.arm.com/products/CPUs/archi-thumb2.html regards, Joseph This e-mail message is intended for the addressee(s) only and may contain information that is the property of, and/or subject to a confidentiality agreement between the intended recipient(s), their organisation and/or the ARM Group of Companies. If you are not an intended recipient of this e-mail message, you should not read, copy, forward or otherwise distribute or further disclose the information in it; misuse of the contents of this e-mail message may violate various laws in your state, country or jurisdiction. If you have received this e-mail message in error, please contact the originator of this e-mail message via e-mail and delete all copies of this message from your computer or network, thank you.
Reply by ●March 10, 20052005-03-10
Joseph wrote:> The new Cortex cores will provide better code density > and performance from the Thumb-2 instruction set. > For more details see > http://www.arm.com/products/CPUs/ARM_Cortex-M3.html > and > http://www.arm.com/products/CPUs/archi-thumb2.htmlAre there any opcode level details on Cortex yet ? - the links above are large on 'warm fuzzies' and small on real info.. -jg
Reply by ●March 10, 20052005-03-10
On Thu, 10 Mar 2005 07:07:48 +0000 (UTC), Wim Lewis <wiml@hhhh.org> wrote:>> char buffer[16];> It'll occupy 16 8-bit bytes (or 4 32-bit words), but it's possible > that a statement such as > > buffer[3] = x; > > will end up reading the 32-bit word containing that byte, modifying > the word, and then writing it back.ARM has instructions to load bytes (with or without sign extension) and store bytes. IME I have never come across a compiler doing this. To the OP: reading the document DDI0100E "ARM Architecture Reference Manual" is highly recommended. Vadim
Reply by ●March 10, 20052005-03-10
"Jim Granville" <no.spam@designtools.co.nz> skrev i meddelandet news:42309577$1@clear.net.nz...> Joseph wrote: > > The new Cortex cores will provide better code density > > and performance from the Thumb-2 instruction set. > > For more details see > > http://www.arm.com/products/CPUs/ARM_Cortex-M3.html > > and > > http://www.arm.com/products/CPUs/archi-thumb2.html > > Are there any opcode level details on Cortex yet ? - the > links above are large on 'warm fuzzies' and small on real info.. > > -jgQuestion is how successful the Cortex cores will be over time. Should anyone in the semiconductor industry be interested in paying money for an ARM Ltd core which is not an ARM? I mean compared to lets say the MIPS, Tricore, PowerPC, Coldfire or whatever. The value of the Cortex is much lower than that of the ARM Anyone can build a better core than the ARM, but you wont get access to the tools/customer base unless you do a lot of things right. The AVR team has managed to introduce a new architecture which became popular, The consisten flash approach helped, like the OTP did help the PIC. but it is harder in the high end. You need O/S. It is possible to introduce new cores if you know how, but look how Motorola failed with the M-Core. They have some success with Coldfire where the price has dropped, but as long as you meet the pricing, people go ARM. Should anyone in the tools business be interested? No customers yet. Before anyone releases a general purpose micro, there wont be enough market to finance tools unless ARM pays up, but I think they rather sell their own compiler. It will certainly be of some academic interest. -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.
