Qreen, Обычно начинать надо с Technical Reference Manual. Да, это документация от производителя процессора.
Берете модель конкретного вашего процессора и ищите по нему доку.
Например, если процессор АРМ, то начинаете с документации от производителя железки (АРМы много кто делает, кроме самого АРМа), а там будут ссылки на документацию от АРМ, а у АРМа то же целая пачка этих документов.
С интелом проще - они сами делают свои железки, так что вся документация в одном месте.
У вас есть несколько ядер проца - запустите на каждом ядре какой-либо код, вот вам и многопоточность.
Но для ОС, нужен как минимум планировщик, который сможет по таймеру на каждом ядре отдельно снимать один поток с выполнения и запускать другой.
Структуры, описывающие потоки, надо хранить в какой-то потокобезопасной (а лучше lock-free/wait-free) очереди с приоритетами. Планировщик, снимая поток с выполнения на конкретном ядре, добавляет его в конец очереди, извлекает из очереди самый приоритетный первый поток и ставит его на выполнение на данное ядро.
unk1nD000, Не плохо для первого раза!
Каталоги можете сразу создавать, с перенаправлением вывода ошибок в nul. На существующие каталоги md просто ругнется.
Rag’n’ Code Man, Может лучше сразу использовать более современные инструменты типа cmake или чего-то в этом роде (их сейчас много)?
Но, конечно, базовые принципы makefile надо знать, т.к. много проектов собирается на них.
В случае массива указателей вполне работает двойная индексация [i][j], но размеры, конечно, придется контролировать самому.
В целом использовать вложенные вектора проще и в духе С++.
Что есть какой-то выбор?
Указав конкретный проц, вы уже выбрали архитектуру. Вопрос не актуален.
Если вы про выбор между x86 и x86_64, то х86 на более менее современных процах (выпущенных не более 10 лет назад) не актуален, конечно, при определенных дополнительных условиях по железу (но это не ваш случай явно).
Вообще, помнится, когда я последний раз использовал makefile, то цели для получения объектных файлов делал по маскам имен файлов:
${OBJ_DIR}/%.o: ${SOURCE_DIR}/%.c
тут команды для компиляции
На сколько помню такая конструкция работает, даже если исходники лежат где-то глубже в подкаталоге от ${SOURCE_DIR}. В этом случае при сборке объектников должна воспроизводится иерархия каталогов исходников. Создавать подкаталоги для объектных файлов, конечно, нужно самому, тут же до вызова компилятора.
Что бы make что-то пересобрал надо изменить исходник, иначе make справедливо считает, что уже собрано, о чем вам и сообщает.
Зачем вы вызываете в compile makeи? Можно же просто указать зависимость от другой цели (смотри ниже).
В этом случае определение переменной OBJECTS будет не корректно, т.к. в начальном состоянии (когда сборка очищена), у вас нет ни одного объектного файла и OBJECTS будет пустой. Ее надо определять через SOURCES, заменой расширения.
Конструкция, на сколько помню такая: OBJECTS = ${SOURCES: .o=.c}
И т.к. у вас объектные файлы лежат в другом каталоге надо изменять и путь. Посмотрите описание функции ${subst}
Что бы компилятор сразу создавал объектные файлы в нужном каталоге используйте опцию -o, тогда не нужна будет команда mv.
Цель compile можно сделать так:
link: build ${OBJECTS}
команды для link
compile: link
нет тела
antares4045, Вы просто их плохо искали.
Предлагаю дальше не продолжать. Тут все равно каждый останется при своих, т.к. что бы вас разубедить мне надо разобрать какую-то конкретную ситуацию. А для этого я должен воспроизвести ситуацию у себя и сам разобраться с ней. Мне, конечно, это делать лень.
На вскидку про питон и телеграм ботов сказать ничего не могу, т.к. с питоном я сталкиваюсь мало и не регулярно, а телеграм ботов вообще никогда не писал.
antares4045, Винда так же прекрасно справляется с unix-way цепочками. Нет никакой такой особенности, и нет проблем в винде с запуском процессов.
В никсах полно разного толстого и "монолитного" софта, далеко не unix-way.
Может быть когда-то unix-way и был какой-то фишкой никсов, но сейчас - это уже давно осталось в прошлом.
И применительно к данному вопросу - unix-way тут вообще не при делах. Питон не использует никаких цепочек - это здоровое монолитное приложение.
Тормозить может любая ОС по разнообразным причинам. Не стоит придумывать то чего нет.
Запуск из-под админа вряд ли в этой ситуации чем-то поможет.
Станислав Иванов, Верно.
Обычно программы можно не скидывать - они устанавливаются за ново, как обычно (скачиваете установщик и устанавливаете). Впрочем могут быть варианты, конечно.
Станислав Иванов, Вообще со зверьем можно бороться долго и так и не побороть до конца.
Поэтому подумайте, может проще и быстрее слить нужную информацию с компа и переустановить винду с полным форматированием дисков.
Если, что сливать инфу лучше подцепив диск с вашего компа на другой не зараженный комп - так ваша ОС (и вирусы в ней) будут не активны. Или загрузившись с загрузочной флэшки - в этом случае так же ваша ОС и вирусы не будут активны. Слитую информацию, конечно, стоит проверить на вирусы, до или после - это уже не так важно.
Берете модель конкретного вашего процессора и ищите по нему доку.
Например, если процессор АРМ, то начинаете с документации от производителя железки (АРМы много кто делает, кроме самого АРМа), а там будут ссылки на документацию от АРМ, а у АРМа то же целая пачка этих документов.
С интелом проще - они сами делают свои железки, так что вся документация в одном месте.