jcmvbkbc

Почему компиляторы не используют инструкции повторения REP movs?

чего это "не используют"? Используют.

Она должна быть в миллиард раз быстрее

Инструкция которую не нужно читать из памяти, но которая сама лезет в память дважды на каждом цикле своего выполнения не может быть "в миллиард раз быстрее" других реализаций той же логики.

VIDEO_BUFFER_SEGMENT = 0xA000
VIDEO_BUFFER_OFFSET = 0xFA00
VIDEO_SEGMENT = 0xA000
VIDEO_OFFSET = 0x0000

как ты думаешь, сколько памяти в сегменте VIDEO_BUFFER_SEGMENT доступно начиная со смещения VIDEO_BUFFER_OFFSET и что там идёт дальше?

Если в твоём коде сделать вот такие изменения, то всё работает:

diff --git a/lib/video.inc b/lib/video.inc
index 3a26f43e2f79..d7054e194da9 100644
--- a/lib/video.inc
+++ b/lib/video.inc
@@ -3,8 +3,8 @@ VIDEO_INC equ 0
 
 include "memory.inc"
 
-VIDEO_BUFFER_SEGMENT = 0xA000
-VIDEO_BUFFER_OFFSET = 0xFA00
+VIDEO_BUFFER_SEGMENT = 0x6000
+VIDEO_BUFFER_OFFSET = 0x0000
 VIDEO_SEGMENT = 0xA000
 VIDEO_OFFSET = 0x0000
 VIDEO_SIZE_DB = 0xFA00
@@ -79,11 +79,11 @@ macro video!flip {
        mov ax, VIDEO_SEGMENT
        mov bx, VIDEO_BUFFER_SEGMENT
        mov es, ax
-       mov ds, ax
+       mov ds, bx
        mov cx, VIDEO_SIZE_DB
        cld
        mov si, VIDEO_BUFFER_OFFSET
-       xor di, VIDEO_OFFSET
+       mov di, VIDEO_OFFSET
        rep movsb
        pop ds es
 }
diff --git a/os.asm b/os.asm
index 1949e95b4e99..e5ebb3d280aa 100644
--- a/os.asm
+++ b/os.asm
@@ -91,9 +91,9 @@ kernel.routine.startup:
 kernel.routine.video:
        cli
        video!fill 0x4E
-       ;video!window 30, 40, 100, 60, 0x1A, 0xFF, 13 , 0x1F
-       ;video!cursor
-       ;video!flip
+       video!window 30, 40, 100, 60, 0x1A, 0xFF, 13 , 0x1F
+       video!cursor
+       video!flip
        sti
        ret

mov al, [bp+12]
  mov bl, al
  mov cl, 3
  shl al, cl

  sbb dh, dh
  cbw
  mov dl, [bp+8]
  mov al, [bp+10]

Этот кусок кода из обработчика перемещений мыши должен делать знаковое расширение 9-битных координат, но я вижу, что в существующем коде в обработчик перемещений всегда приходят нули в координатах x и y, а из-за этого знакового расширения отрицательные dx и dy всегда становятся равными -256. Если добавить вызов функции initialize (0xc205) прерывания 0x15 в mouse.init с 3-байтными пакетами:

kernel.routine.mouse.init:
  push es bx
  int 0x11
  test ax, 4
  jz kernel.routine.mouse.init.error
  mov ax, 0xC205
  mov bh, 3
  int 0x15
  jc kernel.routine.mouse.init.error
  mov ax, 0xC203
  mov bh, MOUSE_RESOLUTION
  int 0x15
  jc kernel.routine.mouse.init.error

то у меня всё начинает работать как ожидалось.
Кстати в ответе на SO по твоей ссылке вызов этой функции есть, непонятно зачем ты его выкинул.

как получить доступ к этому регистру?

lea (%rip), %rax (в синтаксисе at&t) получает адрес следующей инструкции

Зачем он для такой строчки на 69, 70ой строчке добавляет к j такую странную константу.

В конечном коде выглядит действительно загадочно. Если вызывать компилятор с ключом -fdump-tree-all (фиг знает, как сделать это на godbolt.org, я проверял локально), то уже в самом первом дампе можно увидеть, что if (arr[j - 1] > arr[j]) превращается в это:

if (*(arr + ((sizetype) j + 1073741823) * 4) > *(arr + (sizetype) ((unsigned int) j * 4)))

1073741823 -- это 0x3fffffff, 30 единичных бит, т.е. 30-битная -1. Дальше j + 1073741823 превратилось в

add     r3, r3, #1073741824
subs    r3, r3, #1

т.е. в j + 1073741824 - 1. После умножения на 4 старшие два бита j теряются, но в чём смысл использования 30-битной -1 вместо 32-битной -- мне непонятно.
Поскольку константа появляется ещё до начала архитектурно-зависимых преобразований, она фигурирует в выводе для всех 32-битных архитектур поддерживаемых gcc. Интересно, что это началось между gcc-4.6 и gcc-5, до этого в этом месте генерировался просто sub r3, r3, #1. Ещё интересно, что даже с -O2 эта константа остаётся в сгенерированном коде, а исчезает только с -Os. Выглядит как регрессия.

проблема заключается в том, что я не знаю, как получить состояние машины в момент прерывания, чтобы его сохранить.

Возможно тебе следует выяснить, что это конкретно за "состояние машины" которое ты собираешься сохранить, возможно это поможет тебе его найти.

У тебя тут три разных вопроса.

Моя программа запускается в bosh но не реагирует на прерывания клавиш

А какую реакцию ты ожидаешь? Введённый символ ты не печатаешь, si ты не перезагрузил, так что puts_loop загружает из памяти следующий 0 и тоже ничего не печатает. Можно сделать так чтобы увидеть, что int 16h таки работает:

keyboard_loop:
        mov ah, 0
        int 16h
        mov ah, 0Eh
        int 10h
        jmp puts_loop

iso образ созданный dd не запускается в VB

А почему ты думаешь, что из mbr можно создать iso с помощью dd? Его вообще-то надо в правильное место поместить, не абы куда. Например это можно сделать так: mkisofs --no-emul-boot -o test.iso -b test.bin . где test.bin -- это твой бинарник бут-сектора.

а загрузочная флешка не отображается в BIOS

Это видимо следствие из того, как ты сделал iso который закатал на флэшку.