CPU Registers x86-64

[glauxosdever]

Hi,


About a year ago, I created the CPU Registers x86 page. Since this page explains only 32-bit registers, someone (Roman) copied this page to form the CPU Registers x86-64 page, with just some additions. Still, many sections remained the same as in the original page. After a lot of time of inactivity, I finally added the notice about the factual inaccuracy of the CPU Registers x86-64 page. Since I have no experience with x86-64 yet, I'm unable to correct this page, so it would be nice if anyone with the relevant experience did it.


Regards,
glauxosdever

[Octocontrabass]

About a year ago, I created the CPU Registers x86 page.

Why did you separate the general purpose registers into "general purpose", "pointer", and "index" sections?

[Solar]

?

eax, ebx, ecx, edx are general purpose registers.

ebp, esp, eip are pointer registers.

esi, edi are index registers.

I don't see anything wrong there.

[Octocontrabass]

EAX, ECX, EDX, EBX, ESP, EBP, ESI, and EDI are general purpose registers. They can all be used interchangeably for all instructions that take explicit operands. Separating them implies that there is some difference in how they function, but they all work the same way.

[SpyderTL]

I think that I would keep them separate.

It is true that they can all be used as operands, but there are plenty of instructions that specifically target some of these registers, like push, pop, cmps, enter, etc.

This pretty much dictates that you don't use, say, ESI and EDI for simple math, unless you have no other choice.

[alexfru]

EAX, ECX, EDX, EBX, ESP, EBP, ESI, and EDI are general purpose registers. They can all be used interchangeably for all instructions that take explicit operands. Separating them implies that there is some difference in how they function, but they all work the same way.

For one thing, not all of them are byte-accessible/addressable (unless we're talking 64-bit mode with e.g. SIL, BPL).
For another, not all 16-bit regs can be used for memory accesses.
So, some generality is lost.
I'm being a little picky.

[Octocontrabass]

It is true that they can all be used as operands, but there are plenty of instructions that specifically target some of these registers, like push, pop, cmps, enter, etc.

Plenty of instructions specifically target EAX, and a few of those also target EDX. Why not put EAX and EDX in their own section?

For one thing, not all of them are byte-accessible/addressable (unless we're talking 64-bit mode with e.g. SIL, BPL).

That's when xchg comes in handy. However, the separation also exists on the page for 64-bit registers.

For another, not all 16-bit regs can be used for memory accesses.

The registers you can use for 16-bit addressing are SI, DI, BP, and... BX. The separation doesn't match this use case.

[Combuster]

Wouldn't it be a better idea overall to merge the pages into one?

[SpyderTL]

Plenty of instructions specifically target EAX, and a few of those also target EDX. Why not put EAX and EDX in their own section?

I think we can all agree to putting a single register in a "category" by itself is missing the whole point of "categories"... in the same way that putting all registers in one category labeled "general purpose" doesn't make sense.

We could argue that the osdev wiki has too many, or too few categories, but I don't see how putting everything in one category because they are all "articles", or having one category per article would help anyone. If your argument is that ESP is similar enough to EAX to put them in the same category, I can see your point. I just happen to disagree that, for someone just starting to learn about registers, putting them all together makes a whole lot of sense.

But it is a wiki. You can always change it if it makes more sense to you.

[SpyderTL]

Wouldn't it be a better idea overall to merge the pages into one?

If you were new to assembly, I think putting all of the 16-bit, 32-bit and 64-bit registers on the same wiki page would be a little confusing. And we have plenty of users who are new to assembly...

[glauxosdever]

Hi,


I think the way I had split the General Purpose Registers to Index and Pointer categories is at worst acceptable, at best it will help newbies understand the differences between them, as Solar, SpyderTL and alexfru have pointed out.

The issue is in the x86-64 page, which is anyway the cause for which I started this thread. I explained what is wrong with it in my first post.

By the way, is it possible that anyone with experience with other architectures documents registers that these architectures have?


Regards,
glauxosdever

[iansjack]

TBH I would go straight to the Intel manuals for this sort of information. I'm not sure that putting these details on a Wiki page is not counterproductive as it may discourage people from reading the manuals or a proper tutorial. I realize that the manuals are large, but this information is in the introductory chapter which, really, everyone should read.

I'm not in favour of oversimplification.

[glauxosdever]

Hi,


I agree that is useful, if not mandatory, to read the Intel manuals when writing an operating system. On the other side, I think it's good to have a quick reference about registers, in the same way we have several pages about the different processor modes, the different structures used in these modes and many other things easily found in the Intel manuals.

Then there are even more pages about other hardware, filesystems, executable formats... All of these have their respective specifications, in the same way you can find the information about registers in the Intel manuals. So, why having a wiki in the first place, when everything (or almost everything) can be found in other places? (rhetorical question)

For the record, I added the CPU_Registers_x86 and CPU_Registers_x86-64 pages to a new category. I think these pages will be better organised this way.


Regards,
glauxosdever

[iansjack]

So, why having a wiki in the first place, when everything (or almost everything) can be found in other places? (rhetorical question)

Well, I'd say that the point of a technical Wiki like this is to record information not easily found elsewhere rather than just reproducing - or, worse, producing a precis of - official documentation. It can certainly be useful to expand on that documentation when it is rather sparse (although the Intel manuals could hardly be called sparse when it comes to describing the programmer's model of the processor). When the Wiki is liable to encourage people not to read the official documentation then I feel it is doing a disservice. Another use, of course, is to give information that is not easily found elsewhere; some technical documentation can be difficult to find - again, this can hardly be said of the Intel programmer's manuals.

We often see in these forums the results of people following minimal information; I think giving a crib sheet of the processor registers is minimal information which gives no real idea of how the processor works and how to program it. If you need to know it you will read the manual and very soon learn it; it's really not that complicated a piece of information. It's like giving a crib sheet of the controls in my Hyundai i30 - I don't need it as I use the thing every day. Just my opinion.

Now a page that gave brief comparative details of all the commonly met processors might be a lot more useful, helping people choose which processor looked interesting to them, but it would need to cover things like instruction sets and addressing modes rather than just listing registers.

[embryo2]

I think we can all agree to putting a single register in a "category" by itself is missing the whole point of "categories"... in the same way that putting all registers in one category labeled "general purpose" doesn't make sense.

There could be many categories. This type of relation is called many-to-many. And it can be very useful. Not always, of course, but sometime it can simplify person's understanding of an instruction or even some algorithm involving categorized register.

Human's way to remember things is about making a network of entities using brain's neurons. The wider/richer network is the better understanding the person has. Many categories could add to the richness. But it should be a useful richness and not just some space filling information. It is possible to give some historic perspective of the register evolution and show that there was just one register for arithmetic operations and it was caller accumulator (short form - A, it was "accumulating" some result value until it finally moved somewhere else - in memory or port address), it was just 4 bit wide. Next there was some progress and the need for another register arrives. Next with another progress step the width was extended to 8 bits and so on. So we had A, next B, next BL and BX, next EBX was added and finally the RBX arrived along with R8-15. But even today we still have the same accumulator register in the form of the RAX/EAX registers. Today there are many registers, but the history (or the legacy?) plays it hard and insists on using the RAX/EAX for some operations. So, the "accumulator category" is alive and sound even today.

We can see something similar with the index registers, with pointer registers and with other "general purpose" registers. And from the other side we can use registers like ESP for calculations or as a temporary storage while treating it as a really general purpose thing. The only problem with it - it's too complex and error prone to use it in such a way. But the situation is different with another pointer register - the EBP. It can be used perfectly as a plain general purpose register with some minor exclusions. And only historical legacy of function call implementation remembers us about the role of the EBP. Would there be no legacy code there will be no need for EBP's special role (and it's the case for "legacy free" implementations of OSes).

So, I just think it's very useful to get the idea of why some registers exist and why they are the way they really are. But one note should be mandatory - it's about Intel's legacy. Other processors can have their own exciting history with special registers and many interesting design decisions.