jcmvbkbc

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

На то, что ты в прагме сказал, что будешь редуцировать в 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 который возвращает эта функция.

third = string(buffer1);
fourth = string(buffer2);

Должно быть

third = string(buffer1, size3);
fourth = string(buffer2, size4);

поскольку строки прочитанные в buffer1 и buffer2 не 0-терминированные.

И отдельно

char buffer1[size3];
…
char buffer2[size4];

это не по стандарту С++, компилируется и работает только из-за расширений GNU.

wcout << endl << "Результат: " << encrypt(s);

ты потерял L перед "Результат" и выводишь в wcout обычную строку.

А перед этим выводишь в cout. Приведи всё к выводу в wcout.

Стандарт C++ об этом говорит вот что:

Mixing operations on corresponding wide- and narrow-character streams follows the same semantics as mixing such operations on FILEs, as specified in the C standard library.

А стандарт С в свою очередь говорит вот что (C11 7.21.2:4):

Each stream has an orientation. After a stream is associated with an external file, but
before any operations are performed on it, the stream is without orientation. Once a wide
character input/output function has been applied to a stream without orientation, the
stream becomes a wide-oriented stream. Similarly, once a byte input/output function has
been applied to a stream without orientation, the stream becomes a byte-oriented stream.
Only a call to the freopen function or the fwide function can otherwise alter the
orientation of a stream. (A successful call to freopen removes any orientation.)

Byte input/output functions shall not be applied to a wide-oriented stream and wide
character input/output functions shall not be applied to a byte-oriented stream.

Помогите мне, пожалуйста, решить эти проблемы

При условии правильной настройки переменных окружения достаточно заменить setlocale(LC_ALL, "ru"); на setlocale(LC_ALL, "");.

почему просто 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

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

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