I've learned the Assembly programming of the 8086 Intel processor in the college. I'm now trying to revise it.
I've heard that Assembly is required in Automotive Embedded Systems so I want to know which way to learn it is the best? I don't need to waste time as I want to get a job.
Does revising the Assembly of the 8086 really help? Or moving to something like the 32bit x86 Assembly is better?
Your title asks an entirely different question than the body. Generally you should ask one straightforward question.
No, there is no general assembly syntax - or actually there is, but you probably don't mean that, assembly syntax is generally:
[<label>:] <opcode> <operands> [<comment>]
or similar.
For x86 there are two common syntaxes in fact - Intel and AT&T (with multiple variants of Intel syntax from different assemblers, including totally different directives for lines that aren't instructions), but they and others are more or less of that form.
But what you probably meant is is there a general assembly language instruction set. If that is the case then no there is not. That is not the same thing as syntax. Like a natural language, machine languages have syntax, vocabulary, and semantics - how the words are ordered, what words are available, and what they mean. The point about assembly language is that there is a one-to-one relationship between the assembly mnemonics and the machine-code instruction set. Therefore there are as many assembly languages as there are processor architectures.
Does revising the Assembly of the 8086 really help? Or moving to something like the 32-bit Assembly is better?
16-bit 8086 assembler is seldom used (outside of teaching as in your case), and x86 in general is not generally an automotive device if that is what you are interested in. "32-bit Assembly" is not a thing, unless you are specifically referring to 32-bit x86 assembly.
Learning an assembly language is useful for understanding the fundamentals of how a computer works - that is probably why you were taught an obsolete instruction set, because the aim is not to be able to code in it, but rather to comprehend the fundamental principles. That in turn can result in writing better high-level language code that compiles to smaller, faster machine language code. It can also be useful in debugging high-level code - sometimes you need to step at the instruction level to understand why the compiler-generated code does not do what you expect. But for that you only need to be able to read assembly, not to write it.
Assembly language for large bodies of code that could be implemented in systems level language such as C or C++ is unnecessary and unproductive. Not only is the compiler an expert in the target machine code instruction set, so you don't have to be, but a high-level language is also more likely to be supported by a wide range of tools for testing, validation, static analysis, security analysis, performance analysis and error detection. The code will also be more maintainable, more reusable, and be able to benefit from a wider range of third-party libraries.
Also look at it this way, so you are an expert in PIC assembly for example, but your next job is for an ARM Cortex-M, now you are no longer an expert, and will write far worse code than the compiler will generate, and take far longer doing it. Then you are unemployed.
Over a large code base, a modern optimizing compiler may well do a better job of making efficient asm than a human could or would, outside of a few important loops which you can come back and tune (either by tweaking the C or rewriting that one loop in asm). Inlining and constant-propagation are hard in asm, but compilers are excellent at it. This is especially true for processors that are good compiler targets and that compiler developers have spent a lot of time on, like x86 or ARM.