jcmvbkbc

Я пишу ос и у меня возникла проблема

Возникла проблема -- отлаживай.
Разберись, что за адрес у тебя загружается здесь в GDT.

Вот так это можно пофиксить.

Я пишу новую операционную систему и столкнулся с непредвиденным поведением ядра

Обычно в этот момент люди начинают пользоваться отладчиком.

проблема в файле kernel\kernel.asm

Нет. Ядро твоё не запускается, потому что бутлоадер пытается загрузить его поверх собственного кода:

0x00008122:  bb 00 81                 movw     $0x8100, %bx
0x00008125:  50                       pushw    %ax
0x00008126:  b8 00 00                 movw     $0, %ax
0x00008129:  8e c0                    movw     %ax, %es
0x0000812b:  58                       popw     %ax
0x0000812c:  cd 13                    int      $0x13

-- это вызов int 13 из бутлоадера, посмотри на адреса. Вот куда возвращается выполнение после этого int 13:

0x0000812e:  00 00                    addb     %al, (%bx, %si)
0x00008130:  00 00                    addb     %al, (%bx, %si)
0x00008132:  00 00                    addb     %al, (%bx, %si)
0x00008134:  00 00                    addb     %al, (%bx, %si)
0x00008136:  00 00                    addb     %al, (%bx, %si)
0x00008138:  00 00                    addb     %al, (%bx, %si)
0x0000813a:  00 00                    addb     %al, (%bx, %si)
0x0000813c:  00 00                    addb     %al, (%bx, %si)
0x0000813e:  00 00                    addb     %al, (%bx, %si)
0x00008140:  00 00                    addb     %al, (%bx, %si)
0x00008142:  00 00                    addb     %al, (%bx, %si)
0x00008144:  00 00                    addb     %al, (%bx, %si)

Такие дампы ты можешь получить запуская своё ядро в qemu следующим образом:

qemu-system-i386 -hda collector.bin -d in_asm,exec,cpu -D log

Как из файла ассемблера (NASM) запустить exe-шник?

Системным вызовом (т.е. вызовом функции ядра ОС, например execve), либо вызовом библиотечной функции, которая сделает этот системный вызов за тебя (например функции библиотеки C system или функции win32 API CreateProcess).

Не отдельно, а как-будто ассемблерский файл это и есть ос?

Загрузить исполняемый файл в память, если он не статически слинкован -- загрузить все его зависимости (и все их зависимости, соответственно), связать вызовы сделанные через таблицы импорта, выполнить релокации для объектов, которые загружены не по адресам для которых они собраны, очистить bss, выделить стек, инициализировать регистры для первого потока, перейти в точку старта. Обычно ядро делает только загрузку исполняемого образа и динамического линковщика, инициализацию bss, выделение стека и запуск первого потока, а дальше динамический линковщик делает всё остальное в юзерспейсе.

Не понимаю, откуда эта ошибка появляется

Здесь написано, что create_huge_matrix принимает два аргумента, и второй имеет такой же тип, как тип элементов внутреннего вектора:

template <typename T>
void create_huge_matrix(std::vector<std::vector<T>>& matrix, T lowerLimit);

а здесь первый аргумент типа std::vector<std::vector<double>>, а второй -- int:
create_huge_matrix(matrix_s, 5);

а здесь вообще только один аргумент:
create_huge_matrix(matrix_p);

перегрузка оператора должна скалярно умножать два массива. Под этим подразумевается, например: массив1 - 3,2; массив2 - 5,1, скалярное умножение: 3*5 + 2*1 = 17

LabArray operator* (const LabArray& other) {
      double sum = 0;
        for (int i = 0; i < size; ++i) {
          sum += Array[i] * other.Array[i];
        }
      return sum;
    }

Если результатом должно быть число и возвращаешь ты double, то почему тип возвращаемого значения -- LabArray?

isdigit

проверяет, является ли символ цифрой или нет. Помогло бы вам, если бы вы получали из стандартного ввода строку и сами переводили её в число. Но нет, операция

int count_students;
  cin >> count_students;

вводит не строку, а число.

Чтобы проверить, был ли ввод успешным или нет можно вызвать cin.fail(), типа того:

cin >> count_students;
  if (cin.fail()) {
    cout << "Неправильные входные данные. Попробуйте еще раз.";
    cin.clear();
    cin.ignore();
    goto Step1;
  }

lsusb и lspci не видят его

и это правильно, потому что, судя по dmesg, это i2c устройство подключенное к i2c-контроллеру висящему на шине PCI (вот к этому: 00:15.1 Serial bus controller: Intel Corporation Cannon Point-LP Serial IO I2C Controller #1 (rev 30)).

Классический способ состоит в использовании системного вызова ptrace с кодами запроса PTRACE_ATTACH для присоединения к процессу, PTRACE_PEEKTEXT и PTRACE_POKETEXT для чтения и записи его памяти и PTRACE_DETACH для отсоединения.

код работает только для 2 строк , а как записать что бы для всех которые будет вводить пользователь?

заменить
int k[2]={};
на
int k[100]={};

Ne sovsem ponyatno kak ispravit

смотреть не туда, куда ты смотришь сейчас (не на определение COMPILE_TIME_ASSERT, с ним всё ок, оно такое, чтобы генерировать ошибку компиляции, когда какое-то условие в коде не выполняется), а в строку

../deps/source-sdk-2013/mp/src/public/tier0/threadtools.h:1130

где этот assert сработал, и разбираться с ней.

файл становится пустым после скрипта

sed 's/${search%$'\n'}/${replase%$'\n'}/g' $file > $file

неудивительно, >$file делает файл пустым ещё до вызова sed. Чтобы редактировать файл на месте у sed есть ключ -i:

sed 's/${search%$'\n'}/${replase%$'\n'}/g' -i "$file"

А в чем заключаются эти ошибки, я не могу понять

Когда ты на С++ пишешь строки подряд, вот так:

"push edi"  
"push esi"
"mov edx,lenS"
...

они склеиваются в одну строку. Когда ассемблер видит команду "push edipush esimov edx, lenS..." он резонно недоумевает.

как их исправить

Вставить символы конца строки \n или другие разделители инструкций в ассемблерный код.
Ты же просил пример кода, вот же он, он компилируется и работает, воспользуйся им. Если непонятно что там написано, задавай вопросы.