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.
Yes.
I don't know for sure, but I'd be shocked if the answer was no.
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!!
Bytes.
cheers,
Al
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
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.
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
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.
Are there any opcode level details on Cortex yet ? - the links above are large on 'warm fuzzies' and small on real info..
-jg
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
Question 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.
Yes, all good points, which is why seeing opcode and binary details are important. The Cortex is not ARM7 binary compatible, but may have enough commonality that porting tools is not a big issue. Right now, ARM seem to be very short on public release of the important details.
I can understand that those with a big investment in ARM7 might be a little concerned by this.
-jg
I believe it is possible for a hardware memory interface to do this "behind your back," i.e., even though the assembly loads and stores a byte, larger chunks of memory may be read, modified and written back by the memory interface hardware.
I don't know if any ARM chip will do this, and it's really only critical to know about it in shared memory situations...
Regards,
-=Dave
-- Change is inevitable, progress is not.
Hi Jim,
No, sorry. The opcode level details are not release on public domain yet.
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.
Sorry for replying to my own post. It seems it has just been released to customer with NDA (non-disclosure agreement). See
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.
Am I missing something, or is this the height of stupidity. We are selling a processor, but you can't know what's in the instruction set? The time to promulgate that is before the design is complete, in order to get comments from the general public.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
Close to stupidity, but a sad sign of what happens when lawyers out-number engineers in a company.... It means we are expected to believe their marketing hoopla, but cannot actually verify any of the claims.
-jg
Hi guys,
Don't worry. The instruction details will be released to public, it just take time to finish off all the documentation works! :-)
Bear in mind once the design is released to silicon partners, it will take another several months (or even half year) for them to produce the actual silicon chips.
(Honestly I don't know how much of the paper works are in the legal department ;-) )
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.
The answer appears to be "Yes, the height of stupidity. We are not capable of marking any early release documents as 'Preliminary, subject to change'".
This is purely an academic comment on my part.
-- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson
Hi there,
The "early access" architecture specification has been released quite a long time ago (e.g. to ARM partners and development tools vendors). The one on 7 March is an official release. If you read the details of the press release, you will see some development tools vendors has been working with the V7 architecture already.
In the following link, you can find some of the details about the V7 architecture and Thumb-2 instruction set. (see bottom of the page)
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.
thanks Joseph, A quick scan of this info, shows :
They state all this gives you a 5% smaller and 2-3% faster code than Thumb. [presumably those values are averages, maybe even 'marketing-filtered' averages :) ? ]
Variable length opcodes, atomic Bit access, TestZ&Branch will be very familiar to 80C51 users. Thus yes, Cortex will be a better MicroController core than earlier ARMs.
Comment: There is likely to be some confusion in the field, between ARMv7, and ARM7. Reminds me of the Philips XA51, where Philips tried to coat-tail on the large 80C51 market, with a device that was NOT binary compatible.
Time will tell how Cortex flies.
Joseph wrote:
time to finish off all the documentation works!
another several months (or even half year) for them to produce the actual silicon chips.
Hmmm, well one of those papers is dated June 2003, and the Opcodes are defined very early in a processor design. Releasing opcode info is also just a simple text file, so consumes very little actual publishing effort. Of course the silicon follows some time later, but designers can decide what to place on their radar much earlier in a life cycle.
-jg
Hi Jim,
Correct. You need updated development tools. That's why it is important that development tools vendors are involved during development of the V7 architecture.
That's is true for Cortex-M Series. For Cortex-A and Cortext-R series processors, it will support ARM, Thumb and Thumb-2 instruction sets. So some users might still want to separate part of their code as ARM instruction set and other parts as Thumb/Thumb-2 instruction set.
I am not sure how much I can tell you (in case I upset the marketing guys ;-) So I better not to detail these areas.
Time will tell ;) And don't forget that the core size is smaller (lower power consumption). For more advantages of Cortex-M3 core please see
This one I am sure :) But don't forget it is called Cortex-M3. (See next answer)
It will certainly takes time for the market to adapt to the new naming system. Instead of calling it ARM12, the development has now divered to three areas and come with a new naming system: Applications - Cortex-A Real time - Cortex-R Microcontroller- Cortex-M See
I guess people will get soon lazy and just call Cortex-M3 as "M3" (This reminded me of the M3 motorway in UK 8-)
The difficult part is to define the corner cases behaviours. These needed to be clearly documented.
Hope this information helps. If there is any further questions, please post it on comp.sys.arm. There are more ARM people reading that newsgroup and they can help answer questions.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.