CS reset to 0 creates a loop

[mihe]

Hello everybody,

just a simple question that bugs me. In this code below, the loader loops on "MOV CS, AX" (AX = 0), even when CS was already 0 so no changes happened to the register.

I assume something is triggered behind (maybe some microcode does something on IP when CS is changed?) but I just wanted to understand why.

I am aware the solution is just not reset it, but I would like to understand the behavior so I can change the CS value in the future with guarantees of knowing what I am doing.

Any hint, observation, suggestion or comment will be very welcomed !

Thanks in advance!!!!







After this, it goes back to the MOV instruction, and CS is 0 again... but it just loops there.

[Octocontrabass]

That's not a valid instruction. It's causing an invalid opcode exception, and since you haven't installed a handler for that, the handler installed by the BIOS is running. The BIOS handler does nothing and returns to the invalid opcode, which causes the same exception again, and loops forever.

If you need to set CS, use a far JMP.

[mihe]

That's not a valid instruction. It's causing an invalid opcode exception, and since you haven't installed a handler for that, the handler installed by the BIOS is running. The BIOS handler does nothing and returns to the invalid opcode, which causes the same exception again, and loops forever.

If you need to set CS, use a far JMP.

Thanks for the explanation! It is clear now. However, this makes me question why NASM assembler did not complain. Does this mean that this operation is allowed in some other scenarios (maybe different mode)?

Thanks!!

[alexfru]

However, this makes me question why NASM assembler did not complain. Does this mean that this operation is allowed in some other scenarios (maybe different mode)?

It's possible it worked on something ancient like the 8086/8088. They had POP CS. But then the opcode for POP CS was reused as a prefix for new 80186/80286 instructions. This page suggests the move worked.

[Octocontrabass]

I'm not sure why NASM didn't complain. Possibly they didn't feel the need to catch this specific situation.

And yes, it did work on the 8086 and 8088. It's not especially useful though. You can't use it in a bootloader to set CS, since you don't know what IP will be.

[mihe]

Thank you both for your answers.

[CorruptedByCPU]

First of, why didn't you stop the code by using "jmp $" instruction at line 19?
Second, why there is no loop in "print_real" procedure at line 32? It just leaves this procedure after "lodsb" instruction and do nasty things. Just first look at this code makes me angry
Third, please try to study my code of bootloader. It's well commented. https://gitlab.com/akasei/Zero/tree/master
Fourth, I'm glad that You use Bochs Enchanced Debugger. It's very powerfull tool

[mihe]

First of, why didn't you stop the code by using "jmp $" instruction at line 19?
Second, why there is no loop in "print_real" procedure at line 32? It just leaves this procedure after "lodsb" instruction and do nasty things. Just first look at this code makes me angry
Third, please try to study my code of bootloader. It's well commented. https://gitlab.com/akasei/Zero/tree/master
Fourth, I'm glad that You use Bochs Enchanced Debugger. It's very powerfull tool

Thanks for the tips Akasei.

The rest of the code was still work in progress, so do not pay much attention to it

[pvc]

I've just tried it with nasm, yasm and as. None of them complained. Not even a warning. I've never noticed that. Nice catch.