Do a web search for "8051 instruction" set; one of the first few hits is pretty good. Let's take one instruction:
ADD A,R2 0x2A
This adds the value in the accumulator with the value in register R2 and stores the result in the accumulator.
The left is the assembly language syntax (assembly language is defined by the assembler, a program that reads it and there is no standard other than perhaps the one used in the processor developers/maintainers documentation, but you can make your own assembly language so long as you get the machine code right. It isn't a standard) and the right is the machine code.
An implementation of an instruction set architecture is a processor that interprets the instructions and acts on them. So for this instruction and this whole instruction set you need some logic that has an accumulator register, a set of other general purpose registers and ways to implement each instruction. CISC like this were likely microcoded for a number of reasons, that opcode would basically address into a table of micro instructions in a rom that would mux in the accumulator to one alu operand and r2 to the other, tell the alu to perform an add, and latch the outputs (result and flags) to their appropriate places, then move on to the next instruction.
Switching to another instruction set this one is thumb a subset of the arm instruction set.
0: 1840 adds r0, r0, r1
2: 1880 adds r0, r0, r2
4: 18c0 adds r0, r0, r3
6: 1900 adds r0, r0, r4
8: 4008 ands r0, r1
a: 4010 ands r0, r2
c: 4018 ands r0, r3
e: 4020 ands r0, r4
This is where the term "encoding" would make sense. Some of the bits indicate to the processor what instruction each one of these is and other bits indicate the operands.
With the documentation that defines an instruction set architecture you can take 100 engineers and get somewhere between 1 and 100 implementations. If I were to take 100 programmers and give them the task of taking an image and increasing the red value of each pixel by 1. You would have a (loose) definition, and I would expect to see 100 different solutions...implementations...
The book you are reading is possibly MIPS related which like a small list of instruction sets has countless implementations. Computer engineers these days often take a course where they have to implement a mips processor. Take the tens of thousands or more engineers taking a class across the planet each year and repeat that every semester you can start to grasp how many mips implementations there are just from college students. The same students in the same class(room) the same semester might be in some way educated to produce similar implementations, more so than others in other schools or perhaps ones using the same text book might have results that look more similar than folks using other text books. There are a number of hardware description languages not limited to vhdl and verilog that can be used which varies the implementations as well. Similar to my image manipulation program above, a language was not specified, so some will choose Python, some C, some Java, etc.
Some instruction sets are open to some extent arm before armv4, mips before a certain point risc-v being created to be open, 8051 which was cloned way back when and now we have many clones (that are likely in your current computer as well as many of the computers between yours and mine across the internet, same goes for z80 clones).
AMD vs Intel x86 processors is a simple way to understand two different implementations of the same ISA.
So then what they are trying to convey is that one implementation might take N clocks to perform an add operation, 0x2A, another implementation might take M clocks to perform that operation, and averaging out across all the instructions allows some form of comparison between the implementations. Its a bit sketchy to think of it that way, but this is a text book not reality. to get to reality you kind of need to pass through something that covers the basics then if very very lucky you get to see the real world implementations and find out all that is involved in executing an instruction and the notion of clocks and performance.
Those MIPS authors like to drive the ABI themselves and ARM has fallen in line with that, but not as severe. Think of the ABI as nothing more than take the 8051 if I have a function fun (int a, int b); one ABI may dictate that the first parameter is passed in r3 and the second in r4 so. some other ABI for the same ISA may dictate that the first parameter is pushed on the stack then the second after that, so when you enter the function you will see the second parameter then the first on the stack (plus perhaps other ISA specific items used for a call).
We see/saw this with x86 over the years, compiler specific then later someone wrote down some specs then compilers started to conform to it. And depending on the architecture and spec some have changed over time. ARM was okay with 32 bit stack alignment then changed to 64 bit later.
If you are a programmer you should be able to take one of the older and/or simpler instruction sets and write a simulator. Very educational. Then you can use readily available tools like assemblers or compilers and make programs that you can run on your instruction set simulator. The compressed risc-v instructions or the arm thumb instructions you could bang out most of a simulator and debug it in a weekend. A full implementation might take another few days. I'm thinking armv2/3 or armv4t not armv7. Then you can use llvm or gnu tools to write programs. Should beyond a shadow of a doubt cover the topic of what is an ISA and what is an implementation. Even if you only implement enough instructions to perform a simple loop, a handful of instructions at best.
