jcmvbkbc

во-первых компилятор даёт предупреждение, … , но ошибки не производит. Я спокойно линкую файл недо-драйвера с основным ядром, (конечный результат - .efi),

Дело в том, что у EFI-приложений нет динамической линковки, а неопределённый символ после копирования из .so в .efi просто ссылается в никуда. Если вывести неопределённые символы для bootx64.so, то inportb будет среди них:

objdump -t bootx64.so | grep UND
0000000000000000         *UND*  0000000000000000 inportb

В qemu результат вызова этой функции выглядит так:

Trace 0: 0x7fb15d338e80 [0000000000000000/000000007e6e22de/0x40c2b0]
----------------                      
IN: 
0x7e6e2081:  bf 60 00 00 00           movl     $0x60, %edi
0x7e6e2086:  b8 00 00 00 00           movl     $0, %eax
0x7e6e208b:  e8 90 57 00 00           callq    0x7e6e7820

Trace 0: 0x7fb15d3390c0 [0000000000000000/000000007e6e2081/0x40c2b0]
----------------                      
IN: 
0x7e6e7820:  af                       scasl    (%rdi), %eax
0x7e6e7821:  af                       scasl    (%rdi), %eax
0x7e6e7822:  af                       scasl    (%rdi), %eax
0x7e6e7823:  af                       scasl    (%rdi), %eax
0x7e6e7824:  af                       scasl    (%rdi), %eax
0x7e6e7825:  af                       scasl    (%rdi), %eax
0x7e6e7826:  af                       scasl    (%rdi), %eax
0x7e6e7827:  af                       scasl    (%rdi), %eax
0x7e6e7828:  af                       scasl    (%rdi), %eax
0x7e6e7829:  af                       scasl    (%rdi), %eax
0x7e6e782a:  af                       scasl    (%rdi), %eax
0x7e6e782b:  af                       scasl    (%rdi), %eax
…

С другой стороны, если предоставить такую функцию:

unsigned char
inportb(unsigned short port)
{
        unsigned char v;
        asm volatile ("in {%1|%b0}, {%b0|%1}\n" : "=a"(v) : "d"(port));
        return v;
}

то она прекрасно вызывается и возвращает значение.

Можно добавить опцию -zdefs в команду линковки чтобы получать ошибку линковки при наличии ссылок на неопределённые символы.

Чтобы посмотреть, какой именно код выполняется, я запускаю qemu с монитором в консоли (дополнительным ключом -monitor stdio). Я нажимаю ESC когда в QEMU запускается tianocore и выбираю Boot Manager -> EFI Internal Shell, а там пишу fs0:efi\boot\bootx64.efi, после этого в мониторной консоли включаю логгирование (командами logfile log, log in_asm,exec), после чего нажимаю enter в консоли EFI. После этого можно смотреть в файл log и искать в нём знакомые байты из objdump.

По сути pic должен генерировать прерывания 18 раз в секунду

По сути не PIC, а таймер. А в твоём коде не видно ни как ты инициализировал таймер, ни что таймерное прерывание разрешено в PIC.

Второй вариант инициализации не работает

Ну да, не работает. Таким образом можно инициализировать только первый элемент union. Есть ещё вот такой вариант инициализации, начиная с C++20.

GetWindowText() записывает в массив char'ов через символ

GetWindowText(obj.hEDIT,(LPWSTR)&msg, sizeof(msg));

Если это массив char, то надо использовать GetWindowTextA и не приводить указатель на массив к типу LPWSTR.

Последний аргумент GetWindowText, кстати, это не размер буфера, а количество символов в нём, так что туда надо (было бы) передавать не sizeof(msg) а sizeof(msg)/sizeof(*LPWSTR).

У меня есть два make-файла, первый вызывает второй.
Мне хотелось бы получить некоторые данные из второго make-файла.

Не предусмотрено такое логикой make, разве что через eval это можно накостылить. Обычно, когда нужна тесная связь между разными Makefile, один из них подключают в другой (и получают большой логический Makefile поделённый на несколько файлов).

Например, в них нет файла kernel/sched.c

например git log -- kernel/sched.c легко объяснит, что с этм файлом случилось.

насколько критично, что я буду изучать ядро по данной книге, т.е. по устаревшей версии ядра?

совсем не критично, потому что то, что написано в книге имело место в прошлом, а с помощью git можно проследить, что с тех пор изменилось.

"11 22 22 33 33 33"
Должно вывестись:
"11 occurs 1 times
22 occurs 2 times
33 occurs 3 times"
но "33 occurs 3 times" не выводится в консоль. В чем может быть причина?

if (val == currVal) ++cnt;
            else 
            {
                std::cout << currVal << " occurs " << cnt << " times " << std::endl;

В том, что после 3го "33" по-прежнему выполняется ветка if (val == currVal) ++cnt;.

Перемещение по стрелками и буквам ( j k ) вниз и вверх не работает.

в любом файле или в одном конкретном? Может быть этот файл состоит из одной единственной строки? Что о нём говорит wc -l <имя файла>?

не могу понять как это записать, потому что у меня при двух условиях приходится добавлять к элементу массива две единицы, если введено число

ты написал что-то непонятное.

надо сравнить если символ не входит в диапазон 31h-39h, то надо идти дальше по элементу массива

это можно сделать например так:

metka:  

    mov ax,0
    mov al, StringT[si]
    sub al, 49

    jl next      # перейти к следующей цифре, если код текущей меньше '1'
    cmp al, 9
    jnl next     # перейти к следующей цифре, если текущая больше 9

    mov bl, al
    shl bl, 1 ;умножение на 2, т.к. размер адреса - 2 байта
    
    xor ax, ax
    
    mov dx, offset List[bx]
    mov ah, 09h
    int 21h
next:
    add si, 1
    loop metka

Почему вылезает сообщение «make: «build» не требует обновления»?

ну и для ответа на оригинальный вопрос: потому что правило

build: $(SOURCES)

говорит, что каталог build зависит только от исходных файлов. Команды mv *.o ./build и rm -rf build/* делают его новее исходников, поэтому make считает, что обновлять его не надо.

Так происходит, потому что подстановки в bash нерекурсивные. Т.е. если результат подстановки создаёт новую конструкцию, с которой произошла бы подстановка, будь она записана в исходном тексте скрипта, bash не будет её интерпретировать. Это ограничение можно обойти с помощью функции eval, которая интерпретирует свой параметр по всем правилам bash. Т.е. пример из вопроса можно записать так:
du -sh ~ --exclude=$(eval echo $HOME/{$excludes})
Оборотная сторона такого решения -- $excludes становится частью скрипта, и если он контролируется извне, туда легко можно всунуть rm -rf /* как побочный эффект.

(cons 1
   (cons
     (cons 2 (cons 3 '()))
     (cons (cons 4 (cons 5 '())) '())))

Я не нашёл ничего почитать, но нашёл рекомендацию использовать llvm-mca, и для вариантов кода использующих SSE/AVX она дала мне показатели производительности которые совпали с наблюдаемыми на практике. Cоответственно, при желании можно почитать исходники llvm-mca (и добраться до модели пайплайна где-то в недрах llvm).

Почему пятый вариант не выполняется в 4 раза быстрее, чем первый?

Потому что скорость выполнения связана со сложностью опкодов. Так, выполнение vmulpd в пятом варианте занимает 4 такта и полностью перекрывается с остальными инструкциями цикла, так что даже нет смысла делать его короче, меняя add+cmp+jne на sub+jne.