jcmvbkbc

как и почему это работало тогда, а вот в досбоксе неработает?

int 2f -- это multiplex interrupt, портал к дополнениям выполняющимся вокруг DOS. Функция 0x1600 -- это конкретно тест "имеются ли в наличии сервисы windows", см. Почему это должно работать в досбоксе, там же нет виндовых сервисов?

Вопрос номер раз: как такое вообще произошло?

Насколько я понимаю STM32F207xx не поддерживает инструкцию uxtah, потому что это инструкция Thumb2 не реализованная в CortexM3.

Вопрос номер два: как такое фиксить?

Подозреваю, что ключом -march=, вероятно -march=armv6.

; устанавливаем сегмент стека
mov ax, s_seg
mov ss, ax
; устанавливаем сегмент данных
mov ax, d_seg
mov ds, ax

пишет segment relocate

Ну правильно пишет, вот же у тебя код хочет загрузить в ax то s_seg, то d_seg как константы, откуда он их возьмёт без релокаций? Если хочешь com-файл, то либо пиши вместо этого mov ax, cs ; mov ds, ax, либо вообще этот код выкинь, потому что com-файл и так стартует со всеми сегментами указывающими в одно и то же место.

В risc вроде там куча csr регистров

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

на разных компиляторах одна си операция ассемблируется то в комбинацию lui + addi, то в комбинацию auipc +addi

Ты указал ARM в тегах, но у ARM нет инструкций lui и auipc. Такие инструкции есть у RISC-V.
Если ты посмотришь в The RISC-V Instruction Set Manual, раздел 2.4 Integer Computational Instructions, то увидишь, что опкод lui загружает константу собранную из 20 битов непосредственного значения из инструкции и 12 нулевых младших битов в целевой регистр, а auipc прибавляет такую же точно константу к PC и загружает в целевой регистр результат сложения, и в этом вся разница между ними.

где какая используется не совсем понимаю.

lui используется для генерации констант, которые не зависят от того, где расположен код, а auipc для генерации констант, которые двигаются вместе с кодом. Т.е. Если ты хочешь вызвать функцию, которая находится дальше чем ±2К от точки вызова, ты можешь сгенерировать её адрес инструкцией auipc, и полученный код будет работать одинаково, независимо от того, по какому адресу он будет размещён. А если тебе надо поместить в регистр константу, например 0x12345678, то ты можешь это сделать парой инструкций lui rd, 0x12345 ; addi rd, rd, 0x678 и значение константы будет всегда одинаковым, вне зависимости от того, где будет этот код.

Каким образом одинаковые адреса различаются. Или они просто не могут быть одинаковыми(типа ос позаботиться)?

Если есть MMU и он используется ОС, то есть и виртуальные адреса и они могут быть одинаковыми у разных процессов. Если MMU нет или он не используется, то ОС размещает все процессы в одном адресном пространстве, нет смысла говорить отдельно о виртуальных адресах, поскольку они равны физическим, адреса выделяемые ОС разным процессам могут быть как одинаковыми (например несколько процессов запущенных из одного исполняемого образа могут использовать один и тот же код и константные данные), так и разными (например изменяемые данные разные у всех процессов, а стеки разные у всех потоков).

Как они в tlb обрабатываются, если вдруг они реально могут быть одинаковыми, и там нету ни каких дополнительных индексов процесса)

Выбери конкретную процессорную архитектуру -- обсудим. у многих RISC-архитектур есть ASID, который идентифицирует адресное пространство и записывается вместе с виртуальным адресом в TLB. Но в любом случае ASID -- это просто оптимизация для повышения производительности, когда он отсутствует или переполняется ОС должна сбрасывать содержимое TLB при переключении адресного пространства.

У ARM есть регистры TTBR с примерно той же функцией, что и cr3 в x86.
У RISC-V есть CSR satp, содержащий ASID и базовый адрес корневого каталога страничных таблиц. Об этом можно прочитать в разделе 4.1.12 Supervisor Address Translation and Protection (satp) Register спецификации The RISC-V Instruction Set Manual Volume II: Privi....

Почему нужно 512-356 байт нулями заполнять, почему нельзя продолжить дальше. Ведь следующая после 86*4 байт инструкция(или переменная) будет выровнена

А вот еслы бы ты тупо взял и прочитал документацию на директиву .p2align, то у тебя таких вопросов не было бы. Потому что никто не заполняет 512-356 байт после. .p21lign выравнивает текущий адрес по заданной степени двойки. Обычно для этого есть аппаратные причины, например базовый регистр таблицы векторов прерываний может иметь 9 младших бит зафиксированных в 0. Или вот по границе страницы MMU выравнивают данные в ELF-файлах, чтобы можно было установить отдельно разрешения RX для кода и констант и RW для изменяемых данных.

для получения элемента допустим table[index_nBit] можно применять операцию ИЛИ вместо сложения. Что быстрее. В этом ли дело

Нет, не в этом.

почему просто 20 бит не берется по порядку

Официальный ответ на этот вопрос прямо написан в спецификации RV32I Base Integer Instruction Set, в разделе 2.3 "Immediate Encoding Variants" на странице 13:

By rotating bits in the instruction encoding of B and J immediates instead of using dynamic hard-
ware muxes to multiply the immediate by 2, we reduce instruction signal fanout and immediate
mux costs by around a factor of 2

для кого авторы постарались придумать такую ерунду

для реализаторов спецификации в железе

Почему компиляторы не используют инструкции повторения 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. Выглядит как регрессия.