Still, I am a

N E W B I E

I hardly understand a lot of the stuff you are saying. Why not keep it simple first?

Just do it. Install a 32 bit OS using QEMU or similar and just do it.

What johnsfine says is all true, but ignores that there are other architectures than X86 Linux. There are many architectures for which assembly is either the best or only choice, as well as other architectures which are easier to learn and experiment with. Many of these are supported with emulators such as Qemu, which further simplifies the process (overlooking a small amount of initial setup pain, maybe).
It think it bears emphasizing that there is a difference between learning a CPU instruction set, and learning assembly language programming. Much of the idiom of assembly language programming is transportable across CPUs. Even though the instruction sets may vary, the concepts are fairly consistent, and simply understanding how low level language constructs compare to relatively higher level languages is a valuable piece of knowledge.
I would tend to put more emphasis on interfacing assembly language to a high level language compiler, than to an OS. I say this as a matter of pragmatism, as well as a matter of academics. Being able to code a function/subroutine in assembler, and understanding the use of the interface to a high level language is not significantly unlike the interface to an OS. On many architectures, there is no OS, but there may well be a C compiler, or other compiler. It may also be useful to code in assembler for such things as optimization of code (I know GNU C is hard to beat, but not all compilers are GNU C), or to access hardware in ways not supported by a high level language.
I say all of this to suggest that MTK358 examine the real reason(s) for wanting to learn assembler coding, and base his choice of training architecture on his needs/wants, more than on what future there is in assembly language for Linux X86.

--- rod.

For example, the original PC keyboard had a microcontroller (I think I8039, don't remember already) and all the firmware was written in assembly. Probably still is - the keyboard remains remarkably the same - a few added keys don't count, key matrix is simply scanned.

Also, compilers are still either terrible or don't even try to use SSE. Even though there's a huge win *just by treating the SSE or MMX registers like really fast memory*.

WTF is SSE and MMX?

They are two (actually more than two) versions of "Single Instruction Multiple Data" instruction sets included in modern X86 chips.

http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
http://en.wikipedia.org/wiki/MMX_%28instruction_set%29

I believe MMX can be ignored as an obsolete predecessor of SSE. But I never used MMX much even when it wasn't obsolete, so I'm not certain there aren't a few useful features one might still want despite having SSE to use instead.

In addition to being SIMD, SSE is also the better way to do ordinary floating point operations.

X86 (modern CPUs) and X86_64 (all CPUs) have two entirely separate floating point instruction sets, a legacy floating point instruction set and an SSE floating point instruction set.

GCC in X86 defaults to using Legacy. GCC in X86_64 defaults to using SSE. SSE is usually better. That is often the reason a 64 bit application runs faster than a 32 bit application.

I believe an asm programmer can use either or both floating point instruction sets (but I switched to SSE long ago and haven't used Legacy floating point in asm since).

They are not that terrible; there are vendor supplied performance libraries using SIMD; I am using certain SIM-based routines coded in pure "C", and they do perform better than equivalent generic ones.