Return to Answer

That video probably tries to add a bit too much definition into blurry terminology, at least my opinion.

In fact, all three ways he describes are ways of creating machine code, and, at the same time, programming in assembly - He just uses different tools.

Classically, people used the term machine code to denote inputting hex (or, more rarely, decimal or octal) binary representations into a computer to generate programs. In order to determine what bytes make up the program, they would have used an assembler to make sense what the instructions actually are.

Here, it doesn't really make a difference whether you make up the instructions in your head, on paper, or in a text file that's run through a program - Somehow, everyone building a machine code program tends to think in assembly language, whether the actual translation takes place in a computer (the "assembler") or in your head doesn't make much of a difference (the latter one simply takes up more calories...). While I still remember that "0c9h" is "ret" on a Z80 and will probably never forget, most of the other opcode-to-instruction translations were forgotten once I used assemblers regularly - and is probably useless knowledge today anyhow. More complicated Z80 instructions (like LD A, (IX+7), for example), I never even tried to "head-assemble".

So, in my mind, you're always programming in assembly, regardless of whether you use your in-built (gray-matter), notes on paper, a machine code monitor, or an external (silicon-based) assembler. If you're simply inputting hex numbers from somewhere, well you're not programming.

That video probably tries to add a bit too much definition into blurry terminology, at least my opinion.

In fact, all three ways he describes are ways of creating machine code, and, at the same time, programming in assembly - He just uses different tools.

Classically, people used the term machine code to denote inputting hex (or, more rarely, decimal or octal) binary representations into a computer to generate programs. In order to determine what bytes make up the program, they would have used an assembler to make sense what the instructions actually are.

Here, it doesn't really make a difference whether you make up the instructions in your head, on paper, or in a text file that's run through a program - Somehow, everyone building a machine code program tends to think in assembly language, whether the actual translation takes place in a computer (the "assembler") or in your head doesn't make much of a difference (the latter one simply takes up more calories...). While I still remember that "0c9h" is "ret" on a Z80 and will probably never forget, most of the other opcode-to-instruction translations were forgotten once I used assemblers regularly - and is probably useless knowledge today anyhow. More complicated Z80 instructions (like LD A, (IX+7), for example), I never even tried to "head-assemble".

So, in my mind, you're always programming in assembly, regardless of whether you use your in-built (gray-matter), notes on paper, a machine code monitor, or an external (silicon-based) assembler. If you're simply inputting hex numbers from somewhere, well you're not programming.

Unless you're doing very weird stuff like self-modifying code (somewhat low on that scale, at least on 8-bit CPUs) or jumping into the middle of another multibyte instruction to have the CPU re-interpret already existing code (pretty much top of weirdness scale). These "dirty tricks" would be very much discouraged today and would probably be considered rather a "puzzle than a program" because they lead to heavily un-readable code. Back in the day, they were, however, relatively more common. But even then, you would have thought in assembly, and rather have the opcodes as a second thought "overlay".

That video probably tries to add a bit too much definition into blurry terminology, at least my opinion.

In fact, all three ways he describes are ways of creating machine code, and, at the same time, programming in assembly - He just uses different tools.

Classically, people used the term machine code to denote inputting hex (or, more rarely, decimal or octal) binary representations into a computer to generate programs. In order to determine what bytes make up the program, they would have used an assembler to make sense what the instructions actually are.

Here, it doesn't really make a difference whether you make up the instructions in your head, on paper, or in a text file that's run through a program - Somehow, everyone building a machine code program tends to think in assembly language, whether the actual translation takes place in a computer (the "assembler") or in your head doesn't make much of a difference (the latter one simply takes up more calories...). While I still remember that "0c9h" is "ret" on a Z80 and will probably never forget, most of the other opcode-to-instruction translations were forgotten once I used assemblers regularly - and is probably useless knowledge today anyhow. More complicated Z80 instructions (like LD A, (IX+7), for example), I never even tried to "head-assemble".

So, in my mind, you're always programming in assembly, regardless of whether you use your in-built (gray-matter), notes on paper, a machine code monitor, or an external (silicon-based) assembler.

That video probably tries to add a bit too much definition into blurry terminology, at least my opinion.

In fact, all three ways he describes are ways of creating machine code, and, at the same time, programming in assembly - He just uses different tools.

Classically, people used the term machine code to denote inputting hex (or, more rarely, decimal or octal) binary representations into a computer to generate programs. In order to determine what bytes make up the program, they would have used an assembler to make sense what the instructions actually are.

Here, it doesn't really make a difference whether you make up the instructions in your head, on paper, or in a text file that's run through a program - Somehow, everyone building a machine code program tends to think in assembly language, whether the actual translation takes place in a computer (the "assembler") or in your head doesn't make much of a difference (the latter one simply takes up more calories...). While I still remember that "0c9h" is "ret" on a Z80 and will probably never forget, most of the other opcode-to-instruction translations were forgotten once I used assemblers regularly - and is probably useless knowledge today anyhow. More complicated Z80 instructions (like LD A, (IX+7), for example), I never even tried to "head-assemble".

So, in my mind, you're always programming in assembly, regardless of whether you use your in-built (gray-matter), notes on paper, a machine code monitor, or an external (silicon-based) assembler. If you're simply inputting hex numbers from somewhere, well you're not programming.

That video probably tries to add a bit too much definition into blurry terminology, at least my opinion.

In fact, all three ways he describes are ways of creating machine code, and, at the same time, programming in assembly - He just uses different tools.

Classically, people used the term machine code to denote inputting hex (or, more rarely, decimal or octal) binary representations into a computer to generate programs. In order to determine what bytes make up the program, they would have used an assembler to make sense what the instructions actually are.

Here, it doesn't really make a difference whether you make up the instructions in your head, on paper, or in a text file - Somehow, everyone building a machine code program tends to think in assembly language, whether the actual translation takes place in a computer (the "assembler") or in your head doesn't make much of a difference (the latter one simply takes up more calories...). While I still remember that "0c9h" is "ret" on a Z80 and will probably never forget, most of the other opcode-to-instruction translations were forgotten once I used assemblers regularly - and is probably useless knowledge today anyhow. More complicated Z80 instructions (like LD A, (IX+7), for example), I never even tried to "head-assemble".

So, in my mind, you're always programming in assembly, regardless of whether you use your in-built (gray-matter), notes on paper, or an external (silicon-based) assembler.

That video probably tries to add a bit too much definition into blurry terminology, at least my opinion.

In fact, all three ways he describes are ways of creating machine code, and, at the same time, programming in assembly - He just uses different tools.

Classically, people used the term machine code to denote inputting hex (or, more rarely, decimal or octal) binary representations into a computer to generate programs. In order to determine what bytes make up the program, they would have used an assembler to make sense what the instructions actually are.

Here, it doesn't really make a difference whether you make up the instructions in your head, on paper, or in a text file that's run through a program - Somehow, everyone building a machine code program tends to think in assembly language, whether the actual translation takes place in a computer (the "assembler") or in your head doesn't make much of a difference (the latter one simply takes up more calories...). While I still remember that "0c9h" is "ret" on a Z80 and will probably never forget, most of the other opcode-to-instruction translations were forgotten once I used assemblers regularly - and is probably useless knowledge today anyhow. More complicated Z80 instructions (like LD A, (IX+7), for example), I never even tried to "head-assemble".

So, in my mind, you're always programming in assembly, regardless of whether you use your in-built (gray-matter), notes on paper, a machine code monitor, or an external (silicon-based) assembler.