jcmvbkbc

; Вывод суммы элементов выше главной диагонали
    mov ah, 2
    mov dl, cl
    int 21h

функция 2 прерывания int21h выводит один символ с кодом в dl. Если код суммирования работает верно, это 2 + 3 + 6 = 11. Символ с кодом 11 -- непечатный, и, даже если бы он был печатным, подозреваю, что это не то, что тебе было нужно. В общем случае нужно переводить полученную сумму в строку цифр и эту строку печатать.

у меня получилось найти только…

Если ты нашёл машинный код, то его длину ты легко получишь посчитав символы, 6 16-ричных цифр -- это 3 байта. Ну или вычтя из адреса следующей инструкции пдрес текущей.
Физический адрес в реальном режиме можно посчитать как cs * 10h + ip. В твоём случае получается 48ff9.
Из твоей записи непонятно, нашёл ты значения регистров или нет, если что, вон они, в среднем окошке в верхнем ряду, а флаги -- в правом.

Почему не переписать вместо этого
add ebx,dword ptr [rbp+ECX*4+10h]

Буквально так написать нельзя, потому что нет такого режима адресации в котором можно было бы использовать вместе Rbp (64-битный) и Ecx (32-битный). Можно было бы написать add ebx,dword ptr [rbp+rcx*4+10h], но для этого счётчик цикла должен был бы быть 64-битным, а он, как мы видим, 32-битный (int i). Т.е. ответ на вопрос "для чего это": для беззнакового расширения 32-битного счётчика цикла в регистр, который можно использовать для доступа к памяти.

Другое дело, что из исходного кода очевидно, что при обращениях к памяти i не выходит из диапазона 0..9, так что разницы между ecx и rcx нет и не может быть. Возможно я что-то упускаю и у компилятора другое мнение на этот счёт, но может быть он просто туповат и не имеет кода который бы мог использовать эту возможность оптимизации, а может такая оптимизация и есть, но она не была включена во время генерации этого кода.

g++  ...   src/core_cm3.c src/system_stm32f10x.c -o build/main

src/core_cm3.c: Assembler messages:
src/core_cm3.c:447: Error: no such instruction: `mrs %eax,psp'

На какой системе ты выполняешь сборку, на x86? Тогда чтобы получить код для arm тебе нужен не g++, а какой-нибудь arm-linux-gnueabi-g++.

помогите понять инструкцию на MASM:
mov dx, es:[bx].StartCluster

Это mov dx, es:[bx + StartCluster], загрузка из базового адреса в регистре + смещения, только в псевдо-С записи. Где-то раньше должна быть определена структура с полем StartCluster, которое используется здесь в качестве смещения.

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

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

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

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