@Paul Glover correctly explained the working of those system call values as being addresses that contain jump instructions to the actual OS routines.
The asm instructions themselves are also numbers, and their 'arguments' or 'operands' are numbers too.
When trying to understand how these machine-level (as opposed to OS level) mechanisms work, some analogy to the physical world might help.
Suppose you have a car. There are three pedals, a lever for selecting a gear, and a steering wheel. Suppose that pedals can only be up or down, there are a maximum of 7 gears, and 4 states of the steering wheel. That setup would give you an 8-bit car ;)
Now the engineer who builds that car gets to decide about how to wire it. My proposal would be:
Wheel Pedals Gears 0 0 locked 0 0 0 roll (nop) 0 0 0 no gear 1 1 straight 1 0 0 change gear 1 1 1 7 = reverse 1 0 left 0 1 0 brake 0 0 1 1. 0 1 right 0 0 1 accelerate 0 1 0 ... 1 1 0 2., ..., 6. So, 'accelerate while turning left in 2nd gear' would have an assembled opcode of
1 0 0 0 1 0 1 0 == 0x8A ie. (wheel << 6) | (pedals << 3) | (gears) = encoded instruction. Any opcodes having more than one pedal bit set would be invalid, except for the combination of 'change gear' and 'brake'.
Or maybe, the gear is only an operand when actually changing gears, and the opcode for simply 'accelerate while turning left in current gear' is 0x88. Or maybe, the engineer is not me (I'm not), the bits are placed differently, and diffferent opcodes result.
The point is, the engineer decides, and once it's built, the bits are 'wired' to have precise meaning, and the way they are loaded specifies the manner in which they must be chained to produce numbers that are valid instructions.
You should think of the bits as switches, or the user interface of the CPU itself. Quite similar to a church organ, where you have levers that determine which sets of pipes get the air pressure applied through playing notes on the keyboard.
As to the relation of assembler text and actual machine code:
- each text representation of an instruction usually has one single way to be encoded.
- each encoded instruction can have an arbitrary number of ways to write it textually, such as for JNE and JNZ, which both check the Zero flag and jump if it's not set (and produce the same encoded instruction), but represent different reasons to do it (previous operation result != 0 vs. previous comparison non-equal) as a way to simplify understanding the source code for humans.
- There may be valid machine instructions that have no text representation at all.
If you want to fully understand instruction encoding for any given platform, there's no way around the instruction reference.