I strongly suggest that you reconsider your goal and here's why:
I first learned 6502 Assembly Language on the BBC Microcomputer (Model B, 32K). It had an awesome BASIC implementation that included a macro assembler. We had them at school so I wrote all sorts of mischievous programs that would do things like direct screen buffer manipulation to make a Lemming walk across each screen, around the room (they were networked) if the machines hadn't been used for 10 minutes. It resulted in fits of giggles among my Year 7 friends.
When I got a Commodore 64 at home, I learned that it had a 6510 CPU which also ran 6502 assembly language but with some interesting extras. I had to buy an assembler (came on a cartridge) and invoke the programs via BASIC. With grand visions of writing a best-selling game, I eventually managed to create several demos that bit-twiddled video display hardware registers on interrupt to do interesting colour bar effects that animated to funky chip music. Impressive, but not that useful.
I then got an Acorn Archimedes A310 which had an ARM2 CPU so I used the same awesome BASIC implementation with built-in macro assembler as the BBC Micro (same heritage). I managed to put together a couple of games which an arty friend provided graphics for, plus some sinusoid-based trippy demos. Both of these were hard work to program and bad code could take down the machine (accidentally trip hardware reset register, etc), losing everything if I hadn't saved (to floppy!).
At University I was introduced to C++ and thus C. I was able to use it to program Sun/Solaris and some other large mainframe computers. I have no idea what CPU architectures these machines ran on - I never needed to use assembler or read machine code as the C++ tools gave me the power I needed to produce professional applications.
After Uni, I worked on Windows and several flavours of Unix. C and C++ worked on all these machines and eventually Java did too.
I then worked on Windows and Dreamcast using C++ with DirectX with comprehensive tool chain for debugging.
I then took a job working with ARM-based chipsets for Smart TVs (in 2000). Although my experience with ARM2 may have been relevant here, the job was C based. I found that all the poking about with hardware that I'd done on the Archimedes could also be done in C using straightforward bit-twiddling operations. Part of my role was to migrate the code base to Windows, Playstation 2, Linux, other TV and mobile chipsets. All of these platforms were available with both a C compiler (often GCC) and some level of API to write to the underlying machine - the embedded world is rarely a kernel O/S. I didn't ever need to know the full machine code for any particular platform beyond writing a boot loader and mini-BIOS, both of which jumped into C code at the first available opportunity (after setting up trap vectors, ensuring endian-ness and instruction-mode and establishing a stack).
For fun, I develop iOS applications on the little spare time I have at home. It uses Objective-C and an API that works across multiple chipsets. Apparently they're ARM-based, but I've never seen any machine code in my development.
While its' a fascinating exercise to learn assembly language, there are now much higher-level tools and languages that allow you to be an order-of-magnitude (or two) more productive.
I'd advise you make this a hobby/side-interest rather than a main goal.