ARM Assembly Language Programming(arm.com)
arm.com
ARM Assembly Language Programming
http://www.arm.com/miscPDFs/9658.pdf
39 comments
>> "He spent weeks taking us through diagrams of the x86's instruction decode hardware. I was convinced that any processor that had to expend so much of its silicon just decoding instructions was doomed, not my best insight."
I haven't found figures, but I'd be willing to bet there's far more ARM devices in the world than x86. x86 didn't die, but it's not in the same league as ARM in terms of success.
Agreed though, the x86 is an absolute dog mainly because of the backward compatibility. Tacking on 32 bit instructions with prefixes, It's a mess.
I haven't found figures, but I'd be willing to bet there's far more ARM devices in the world than x86. x86 didn't die, but it's not in the same league as ARM in terms of success.
Agreed though, the x86 is an absolute dog mainly because of the backward compatibility. Tacking on 32 bit instructions with prefixes, It's a mess.
ARM core sales are measured in billions per year.
I have a particular fondness for ARM assembly. It's a beautiful instruction set, with a minimal elegance and internal consistency.
My only experience of a "normal job" was between school and university, writing import/export filters for a DTP application written entirely in ARM assembly. It was quite a year.
If you want to get into ARM assembly, this is the original and best:
http://www.peter-cockerell.net/aalp/
I still have one of the original paper copies. 1987 was a long time ago, but the legacy of those heady years is still strong.
My only experience of a "normal job" was between school and university, writing import/export filters for a DTP application written entirely in ARM assembly. It was quite a year.
If you want to get into ARM assembly, this is the original and best:
http://www.peter-cockerell.net/aalp/
I still have one of the original paper copies. 1987 was a long time ago, but the legacy of those heady years is still strong.
The PDF is password protected, restricting copy/paste and print functions.
The old ColorSync trick ( http://www.macosxhints.com/article.php?story=200512231728165 ) has long been disabled by Apple, but the link offers some other ideas for OS X (including GhostScript).
Freeware PDF Unlocker for Windows (which includes and uses GhostScript) proved effective at removing the restrictions (though bookmarks are broken in the process): http://hotshare.net/file/106490-50163782f0.html
The old ColorSync trick ( http://www.macosxhints.com/article.php?story=200512231728165 ) has long been disabled by Apple, but the link offers some other ideas for OS X (including GhostScript).
Freeware PDF Unlocker for Windows (which includes and uses GhostScript) proved effective at removing the restrictions (though bookmarks are broken in the process): http://hotshare.net/file/106490-50163782f0.html
Thanks, this seems like a nice book.
As it happens, I've been learning ARM assembly in the recent weeks; just for fun so far. I've mostly used some instruction set references or ARM cheatsheets I found on the web.
Having written mostly m68k assembly before (well, 6502 too...) I knew a bit how to read ARM assembly but I wanted to learn it throughoutly and gain such insight into the instruction set that can only be achieved by writing non-trivial programs with it. Before that I wanted to learn x86 assembly but I soon gathered I'll have better use for my time than that.
I like ARM instruction set quite a lot: it's nicely coherent, has nicely orthogonal features (such as conditional instructions), and doesn't seem to be ridden with despicable backwards-compatibility hacks like x86 assembly.
I like that for once something as good as this has significant marketshare in mobile cpus. Just wondering if they could gradually creep into the market for desktop cpus as well.
As it happens, I've been learning ARM assembly in the recent weeks; just for fun so far. I've mostly used some instruction set references or ARM cheatsheets I found on the web.
Having written mostly m68k assembly before (well, 6502 too...) I knew a bit how to read ARM assembly but I wanted to learn it throughoutly and gain such insight into the instruction set that can only be achieved by writing non-trivial programs with it. Before that I wanted to learn x86 assembly but I soon gathered I'll have better use for my time than that.
I like ARM instruction set quite a lot: it's nicely coherent, has nicely orthogonal features (such as conditional instructions), and doesn't seem to be ridden with despicable backwards-compatibility hacks like x86 assembly.
I like that for once something as good as this has significant marketshare in mobile cpus. Just wondering if they could gradually creep into the market for desktop cpus as well.
A word of warning. Get in the habit of thoroughly commenting your assembly early on, or you likely never will. If you start by commenting too much, you can gradually bring it down. If you start commenting sparsely (or like me, not at all), it's considerably more difficult to increase it.
That said, you picked a good first ISA to learn seriously. ARM has some very cool features, even if it does have its serious faults (poor floating point/vector support, even where it's available). Learning x86 will be trivial from there; the only difficult thing is knowing what the side-effects of functions are, as x86 is horribly inconsistent in that regard.
Good luck!
That said, you picked a good first ISA to learn seriously. ARM has some very cool features, even if it does have its serious faults (poor floating point/vector support, even where it's available). Learning x86 will be trivial from there; the only difficult thing is knowing what the side-effects of functions are, as x86 is horribly inconsistent in that regard.
Good luck!
ARMv7 has a SIMD unit (NEON) that easily outshines SSE and Altivec. Floating point support is also good nowadays.
Or, better said, the instruction set NEON outshines SSE and Altivec. The actual vector unit is a bit lacking performance-wise by comparison, which shouldn't be particularly surprising given that it runs on 100 times less power.
True, but there's nothing to say future implementations will not be faster. Adding more execution units is "easy". Fixing an instruction set is not.
>it's nicely coherent, has nicely orthogonal features
Obviously with exceptions, especially with the instructions added after armv4.
For instance, the allowed addressing modes vary depending on instruction: ldr allows a 12 bit offset, ldrd only an 8 bit, ldm and vld allow none, though vld allows a strided increment. Only ldr* non-exclusive allow a register offset.
Thumb-1/2 and exclusive load/store change things a bit more, but they aren't generally stuff to care about unless you're doing kernel or compiler programming. Also, none of the neon instructions can be conditionally encoded, but there isn't much reason to do that.
As for desktop arm, a massively multicore machine would be nice, but the average user doesn't care much about desktop CPU power consumption nor make good use of more than two cores. Netbooks have to watch out though.
Obviously with exceptions, especially with the instructions added after armv4.
For instance, the allowed addressing modes vary depending on instruction: ldr allows a 12 bit offset, ldrd only an 8 bit, ldm and vld allow none, though vld allows a strided increment. Only ldr* non-exclusive allow a register offset.
Thumb-1/2 and exclusive load/store change things a bit more, but they aren't generally stuff to care about unless you're doing kernel or compiler programming. Also, none of the neon instructions can be conditionally encoded, but there isn't much reason to do that.
As for desktop arm, a massively multicore machine would be nice, but the average user doesn't care much about desktop CPU power consumption nor make good use of more than two cores. Netbooks have to watch out though.
In that case I fully recommend that you also check out Steve Furber's "ARM System-on-Chip Architecture" as a very readable introduction to ARM assembler and an easy way to learn about the microarchitecture and design philosphy of early ARM processors (ARM7 and ARM9) [Furber was one of the original engineers that worked on the first ARM design].
The architecture has come along quite a bit since those days so if you'd like the most up to date release you need to look for the ARM v7AR Architecture Reference Manual which you can get (with a click-through) here: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406b/in...
This will cover you up to the latest cores like Cortex-A8 inside the Beagleboard and Cortex-A9. Enjoy!
The architecture has come along quite a bit since those days so if you'd like the most up to date release you need to look for the ARM v7AR Architecture Reference Manual which you can get (with a click-through) here: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406b/in...
This will cover you up to the latest cores like Cortex-A8 inside the Beagleboard and Cortex-A9. Enjoy!
"I like that for once something as good as this has significant marketshare in mobile cpus. Just wondering if they could gradually creep into the market for desktop cpus as well."
It is going to be hard to displace x86 desktops, but I'm looking forward to ARM-based "netbooks" and pocket-sized computers like the Nokia N900. See Ubuntu job postings and Google's ChromeOS - I believe this presages ARM-based small and tiny mobile computers.
The big question is whether the Atom (and whatever AMD is working on) will be able to reduce their chipSET power to compete with the ARM SOC power numbers before ARM grows up into that market (growing up is always easier than growing down).
It is going to be hard to displace x86 desktops, but I'm looking forward to ARM-based "netbooks" and pocket-sized computers like the Nokia N900. See Ubuntu job postings and Google's ChromeOS - I believe this presages ARM-based small and tiny mobile computers.
The big question is whether the Atom (and whatever AMD is working on) will be able to reduce their chipSET power to compete with the ARM SOC power numbers before ARM grows up into that market (growing up is always easier than growing down).
> Just wondering if they could gradually creep into the market for desktop cpus as well.
Much like I was hoping that PPC would dethrone IA-32 back in the day (I think Linux, OS/2, and NT were all just about ready to support it) but it seems economies of scale are everything.
I'd buy an ARM and a desktop motherboard just to mess around with, but I've literally never seen a local screwdriver shop that carried them even for smoke tests. I guess they're doing fine without hobbyists.
Much like I was hoping that PPC would dethrone IA-32 back in the day (I think Linux, OS/2, and NT were all just about ready to support it) but it seems economies of scale are everything.
I'd buy an ARM and a desktop motherboard just to mess around with, but I've literally never seen a local screwdriver shop that carried them even for smoke tests. I guess they're doing fine without hobbyists.
The Beagle Board is probably the closest thing there is to a desktop MB that uses the Cortex chips.
Arm is creeping toward bigger market share trough netbooks -- if if can succeed there, it will become more available as a desktop choice.
Lacking that, just go buy a Nokia n900 (or an used n810 or something), and code for it.
Lacking that, just go buy a Nokia n900 (or an used n810 or something), and code for it.
I've been using ARM assembly language since the early 1990s. It's a beautiful instruction set, far nicer than the 8080 and Z80 I started with (and which can still be seen in the x86 line) and the m68k line I contracted for.
I've built robots with and compilers for Z80s, and programmed embedded m68k for food, but it was the ARM family that I remember with particular fondness. Every instruction being conditional, clean registers, orthogonal instructions. Simply fun to program.
I've built robots with and compilers for Z80s, and programmed embedded m68k for food, but it was the ARM family that I remember with particular fondness. Every instruction being conditional, clean registers, orthogonal instructions. Simply fun to program.
I became interested in ARM assembly after reading the x86 assembly Forth tutorial that was recently posted on HN. Lacking an ARM processor, though, I'm wondering what emulation options are available? I'm looking for a dead-simple setup that will let me test and run whatever toy ARM assembly programs I write.
Free ARM Emulators
http://www.thefreecountry.com/emulators/arm.shtml
Any specific recommendations from that set? I was looking at Qemu earlier but I'm curious to hear from HN folks who have had experience with these emulators.
Check out the Amiga emulator UAE - it's been ported to virtually everything (Linux, OS X, Windows, DOS, BeOS, Palm OS, and much more, including AmigaOS!) and is under active development (WINUAE, anyway):
http://www.thefreecountry.com/emulators/amiga.shtml http://en.wikipedia.org/wiki/UAE_(emulator)
http://www.thefreecountry.com/emulators/amiga.shtml http://en.wikipedia.org/wiki/UAE_(emulator)
From the webpage it seems that UAE emulates the m68k, not the ARM processor.
Qemu is pretty good, but ARMv7 emulation isn't quite complete yet. Anything compiled by gcc will probably run though.
Why does it say [scribd] in the Hacker News title?
PDF links automatically give a scribd link after the original.
Okay, then there's two issues here:
1. Adding something in square brackets after a title looks like a format hint (e.g. [pdf]) and not a seperate, clickable link
2. With Safari (Mac and iPhone) the second link just gives me the PDF file on the arm.com site. Is scridb unsupported on these platforms? Is its purpose purely adding a redirect? What value does this add?
1. Adding something in square brackets after a title looks like a format hint (e.g. [pdf]) and not a seperate, clickable link
2. With Safari (Mac and iPhone) the second link just gives me the PDF file on the arm.com site. Is scridb unsupported on these platforms? Is its purpose purely adding a redirect? What value does this add?
[pdf]
Isn't that true of everything that comes from scribd?
It doesn't come from scribd. scribd automatically scrape every PDF they find and put it on their site. They do this without considering that many of the PDFs have copyright notices, and require the copyright holder to pay a lawyer to issue a formal C&D before they do anything about it.
I think what they do is reprehensible and I think they're scum. I don't know why the powers that be at HN automatically add the link to scribd.
I think what they do is reprehensible and I think they're scum. I don't know why the powers that be at HN automatically add the link to scribd.
Google does the same thing, but no one ever speaks up about that. Realistically speaking, if you don't want your content to be scraped by such services, put it behind a login page. We as content owners need to stop fighting against technology; it's not a battle that can (or should, really) be won.
Google provides search so people can find your site, and then sends people to your site.
Scribd do neither - they appear to take your content, put it on their own site, and provide nothing in return.
I, as a content owner, expect that a copyright notice should be respected, and I don't expect to have to track down every copy and sue the plagarists and thieves. I've certainly stopped providing PDF references to HN because they aid and abet such theft.
I'm not averse to technology, and I freely provide much of my written material for free, on my sites. I just expect to have people come to my sites to read them, and not have parasites like scribd steal the material without remorse or recompense.
Scribd do neither - they appear to take your content, put it on their own site, and provide nothing in return.
I, as a content owner, expect that a copyright notice should be respected, and I don't expect to have to track down every copy and sue the plagarists and thieves. I've certainly stopped providing PDF references to HN because they aid and abet such theft.
I'm not averse to technology, and I freely provide much of my written material for free, on my sites. I just expect to have people come to my sites to read them, and not have parasites like scribd steal the material without remorse or recompense.
Google also gives you a link to view it on their site. The only difference between Google's PDF viewer and Scribd's is that most people don't link to a Google PDF page.
No, this goes beyond indexing, referral, and reformatting. This is copyright infringement, plain and simple; Scribd monetizes your content by showing ads on the same page!
Don't want your content co-opted? Here's an idea: keep it off the Internet.
So, let me see if I understand what you're saying.
What you're saying is that when I write something, and want people to read it, it's not enough to use the law and put a copyright notice on it.
What you're saying is that if I publish it, even if I've done what the law requires and marked it as mine, anyone can copy it and publish it without my permission.
And will.
Further, there's a company that will do this wholesale. They'll take loads and loads of other people's stuff, put ads next to it, give no additional indication that they didn't produce it, and make money from other people's work.
Yup. Thus we have progress.
What you're saying is that when I write something, and want people to read it, it's not enough to use the law and put a copyright notice on it.
What you're saying is that if I publish it, even if I've done what the law requires and marked it as mine, anyone can copy it and publish it without my permission.
And will.
Further, there's a company that will do this wholesale. They'll take loads and loads of other people's stuff, put ads next to it, give no additional indication that they didn't produce it, and make money from other people's work.
Yup. Thus we have progress.
For better or worse, yes, that's an accurate assessment.
You don't want to live in a world where what you describe is impossible, and neither do I.
And if it's not impossible, it will happen.
You don't want to live in a world where what you describe is impossible, and neither do I.
And if it's not impossible, it will happen.
Scribd was seed funded by Y Combinator.
http://www.crunchbase.com/company/scribd
http://www.crunchbase.com/company/scribd
Which explains why HN puts the link on every PDF. Thank you.
It won't make any difference, and probably no one cares, but I still think what scribd does is ethically and morally wrong.
I'll shut up about it now.
It won't make any difference, and probably no one cares, but I still think what scribd does is ethically and morally wrong.
I'll shut up about it now.
A nicely documented overview and introduction.
- It was the first language I wrote real programs in, back in the late 80's on the Acorn Archimedes desktop machines it was originally built for. The A in ARM originally stood for Acorn, not Advanced.
- Writing ARM demos I was always jealous of the Amiga's blitter, but then I discovered STMIA could store multiple registers pretty darn fast.
- I chose to go to Manchester University purely because Steve Furber, one of the chip's designers, would be a lecturer on my course.
- He spent weeks taking us through diagrams of the x86's instruction decode hardware. I was convinced that any processor that had to expend so much of its silicon just decoding instructions was doomed, not my best insight.
- The instructions' simplicity did make it easy to build low-power versions however, hence its ubiquity in mobile devices. Steve seemed as surprised by this as anyone, it definitely didn't seem like a design goal at the start.
- His main research project was a clockless version of the ARM chip, with asynchronous logic, called Amulet, really interesting technology that never caught on: http://en.wikipedia.org/wiki/AMULET_microprocessor
- ARM is the only British-born computer technology company I can think of that achieved lasting international success. I'd welcome any other examples.