jcmvbkbc

Как это можно пофиксить?

Можно внести поле SDL_RendererRenderer в структуру struct structTile.

Что мне стоит делать дальше?

Изучать обе параллельно.

какие минимальные знания С++ должны быть, чтобы начать изучать Unreal Engine 5

Понимание синтаксиса и способность читать документацию.

На что он ругается?

На то, что ты в прагме сказал, что будешь редуцировать в norm_b_square, а в цикле работаешь с *norm_b_square. А если ты имел в виду одноимённый norm_b_square из функции main, то нет, нельзя так сослаться на автоматическую переменную из другой функции.

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

В чем тут фокус?

Нет никакого фокуса. std::tm -- это завёрнутая в namespace std struct tm, древняя структура из чистого C.

Я думаю, что пара gmtime + timegm -- это простое, понятное, сравнительно портабельное и довольно быстрое решение:

#include <time.h>

enum time_floor_level {
    YEAR, MONTH, DAY, HOUR, MINUTE,
};

time_t time_floor(time_t t, enum time_floor_level level)
{
    struct tm tm;

    gmtime_r(&t, &tm);

    switch (level) {
    case YEAR:
        tm.tm_mon = 0;
    case MONTH:
        tm.tm_mday = 1;
    case DAY:
        tm.tm_hour = 0;
    case HOUR:
        tm.tm_min = 0;
    case MINUTE:
        tm.tm_sec = 0;
    }
    return timegm(&tm);
}

; устанавливаем сегмент стека
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-файл и так стартует со всеми сегментами указывающими в одно и то же место.

зачем там реализуют разные модули, типа кеша, вроде в каком-то даже увидел конвеер исполнения команд, предсказатели переходов. И прочие. К примеру кеш, тлб, зачем он там нужен. если все как бы просиходит внутри машины?

Фронт-енды QEMU реализуют большую часть наблюдаемого поведения моделируемого ими процессора. Одно большое исключение -- это процессорный кеш: QEMU не моделирует поведение процессорного кеша. TLB во многих архитектурах доступен для прямого чтения/записи через команды процессора, нельзя сказать что он "внутри машины".

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

Покажи пример, обсудим конкретику?

Ассоциативная память. Если там внутри делается таблица адресов, виртуальных адресов. То к примеру для адресного пространства 4гб, будет 2^32 это будет в 32 раза дольше.

Это какие-то очень странные допущения и прикидки, а то, что они не учитывают такие параметры как размер TLB и его ассоциативность, показывает их безосновательность.

Короче, в итоге для поиска адреса в супер жесткой виртуальной машине, будет до 32 операции сравнений по словарю, потом суммарно где же в кешах каждого уровня, куча прочих проверок .... .

Нифига. В QEMU есть два уровня TLB -- один, моделируемый процессорным фронт-ендом, второй -- собственный TLB QEMU softmmu независимый от эмулируемого процессора, поиск по которому встроен в генерируемый JIT (который в QEMU называется TCG) код. Собственный TLB QEMU прямого отображения, т.е. поиск в этом TLB -- это всегда проверка одного элемента массива и загрузка одного отображения в случае успеха. Например вот так генерируется код для этого на хосте x86. В случае неудачи происходит вызов функции поиска в архитектурно-зависимом TLB. Вот так этот вызов генерируется, а вот пример его реализации во фронт-енде. Поскольку этот TLB моделирует конкретную архитектуру его ассоциативность может варьироваться в широких пределах, или он может вообще отсутствовать. В случае промаха или отсутствия TLB поиск может либо продолжаться дальше в таблицах страниц, например так, либо фронт-енд генерирует исключение доступа к памяти, например так.

В итоге операций при поиске трансляции для виртуального адреса может быть гораздо больше чем 32, которые ты предположил, в случае промахов, но цена промахов амортизируется тем, что чем более они дороги, тем более они редки. Но, конечно, задача намеренно обращающаяся к никогда не повторяющимся страницам памяти будет иметь очень низкую производительность при выполнении в QEMU softmmu.

В 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....

./configure CC=arm-linux-gnueabi-gcc-7 --host=aarch64-linux-android //тут ОК
make // gcc: command not found

Если конфигурирование прошло успешно, то система сборки должна использовать CC который был ей дан на этапе configure. То что где-то вызывается gcc это либо результат ошибки конфигурирования, либо баг в системе сборки проекта.

Мне надо ссылку делать в bin на arm-linux-gnueabi-gcc-7, или это костыль в данном случае

Если arm-linux-gnueabi-gcc-7 успешно вызывается из консоли по имени, то ничего делать не надо.
gcc -- это хостовый компилятор, ты же не на arm-хосте компилируешь? Если gcc перестал вызываться из консоли -- это отдельная проблема, к кросс-компиляции не имеющая отношения.

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

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

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

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

Что означает ошибка «Error: relocation ... cannot be used with -shared»

Эта ошибка значает, что такой объектник содержит код, работа которого зависит от адреса по которому он будет размещён. Так называемый position-dependent code. Альтернатива -- position-independent code, такой, который выполняется одинаково, независимо от адреса, а все данные и константы, которые зависят от адреса, если таковые есть, вынесены из кода в отдельный изменяемый сегмент. Такой код генерируется компилятором если его вызывать с правильным флагом (например gcc -fpic). Из-за того что динамические библиотеки могут быть загружены в процесс по любому адресу существует требование, что код в них должен быть position-independent. Поэтому объектники скомпилированные как position-dependent обычно не могут быть слинкованы в динамическую библиотеку.

В данном случае запись о релокации с типом R_AARCH64_TLSLE_ADD_TPREL_HI12 говорит (частью TLSLE, где LE означает Local Executable) о том, что код объектника в котором она находится был намеренно собран с рассчётом на то, что объектник будет частью исполняемого файла, а не динамической библиотеки. Здесь можно почитать об отличиях моделей адресации TLS, в частности о модели Local Exec в разделе 4.4.

Почему возникает free(): double free detected

Потому что в этом классе не реализован конструктор копирования (а так же перемещения и операторы присваивания, но это пока не вызывает таких же ошибок). В результате при копировании объекта класса String копия получает то же значение str что и оригинал с которого она скопирована, в деструкторе копия удаляет str оригинала, а потом это же делает оригинал в своём деструкторе. См. правило трёх/пяти.

почему так происходит?

Потому что str и word -- это переменные размером в один символ, а в строке char delimeters[6] = " .,!?;" отсутствует 0-терминатор. Поэтому
- scanf("%s", &str); вылезет за пределы str если ввести здесь что угодно.
- strcat(&word, &c); вылезет за пределы word если в c будет не пустая строка. А в c будет неизвестно что, потому что c = getchar() не добавляет в эту строку 0-терминатор.
- strchr(delimeters, c); может вернуть что угодно, если c не входит в delimiters.

Можно заменить URLDownloadToFileA на URLOpenBlockingStream и читать данные из интерфейса IStream который возвращает эта функция.