это как?

заклинание такое есть

/intel syntax - вроде gas его не умеет

Умеет, и ещë как

хм. Вот в GCC можно делать ассемблерные вставки на gas

Давно причëм

вот

а intel синтаксис там не поддерживается

хм. Вот в GCC можно делать ассемблерные вставки на gas

Ну там да, приходится использовать att синтаксис

так реч про gas вроде

А .s файлы для gas пиши интелевым сколько угодно

Вначале только поставь .intel_syntax noprefix

Вначале только поставь .intel_syntax noprefix

а вот это и есть то самое заклинание

а intel синтаксис там не поддерживается

Я не знаю, что у вас там за GCC и что за заклинания, но с ключом -masm=intel всегда всё без проблем компилировалось. В том числе и ассемблерные вставки тоже.

а вот еще одно

а gcc стандарт с11 поддерживает? если да то с какой версии и в каком объеме?

Я не знаю, что у вас там за GCC и что за заклинания, но с ключом -masm=intel всегда всё без проблем компилировалось. В том числе и ассемблерные вставки тоже.

Спасиб, будем знать

а gcc стандарт с11 поддерживает? если да то с какой версии и в каком объеме?

Более или менее. Тредов вроде до сих пор нет родных (есть чужие реализации) и чего-то ещё. Насчёт версий есть https://gcc.gnu.org/wiki/C11Status но оно давно не обновлялось.

Треды вроде не фича языка

Особенно такого как C

Треды вроде не фича языка

Очень даже фича. В С11 официально признали их существование, поправили формулировки про доступ к объектам, добавили _Thread_local storage class в язык и опциональный threads.h в стандартную библиотеку.

Треды вроде не фича языка

Фитча

Есть еще зеленые треды или по русски-уебански нити

Это уже абстракция над трейдами

Ну если tls имеется в виду. Хотя я не вижу особого смысла в нем. Треды и глобальные переменные несовместимы

К примеру гоурутины или реактивщина

Ну если tls имеется в виду. Хотя я не вижу особого смысла в нем. Треды и глобальные переменные несовместимы

Вы не умеете готовить

Не значит что все не умеют

Асинхронность асики обертка над колбеками многопоточная асинхроннщина на какой нибудь зеленой модели щас очень популярна

C он хорош своей простотой.

Ну если tls имеется в виду. Хотя я не вижу особого смысла в нем. Треды и глобальные переменные несовместимы

strtok() или даже банальный errno?

Нужны расширения - "ты знаешь где взять PL/1". (c) Д. Ритчи вроде

Я не знаю, что у вас там за GCC и что за заклинания, но с ключом -masm=intel всегда всё без проблем компилировалось. В том числе и ассемблерные вставки тоже.

Хм. Трайну, не представляю даже как оно будет выглядеть

С учётом этих " " :: " "

strtok() или даже банальный errno?

Тащить api из однопоточного мира в многопоточный - это называется костыли. Не лучше ли разработать новый реентерабельный без ущерба простоте языка?

Тащить api из однопоточного мира в многопоточный - это называется костыли. Не лучше ли разработать новый реентерабельный без ущерба простоте языка?

Лучше. Но мы имеем то, что имеем. А ещё мы имеем тонны легаси кода, поэтому всё останется так, как есть.

ребят, а как вообще происходит параллельное выполнение кода на ассме? Ну т.е. я вно говорю, мол, камень, этот кусок кода выполняй на этом ядре, а этот на другом. Или как?

слышал про конвейер?

ребят, а как вообще происходит параллельное выполнение кода на ассме? Ну т.е. я вно говорю, мол, камень, этот кусок кода выполняй на этом ядре, а этот на другом. Или как?

Ты просто выполняешь код. Если у тебя есть ОС, у тебя есть планировщик, он знает, какие потоки существуют в системе, выбирает подходящий поток, переключает контекст (регистры проставляет на сохраненные регистры потока, в том числе и program counter в каком-то виде), и код начинает выполняться. Если ОС нет, и самописного планировщика нет (какая-то прошивка на голом железе, например), то зависящим от платформы способом можно указать, с какого адреса начинать выполнение тому или иному ядру. Или ядра начинают выполнять один и тот же код, но знают, кто у них главный (первый), и этот главный им говорит, куда пойти и что выполнять.

хм, т.е. я могу контрллировать ядра вручную, это гуд. Да, я говорю про голое железо, про i386 и далее

хм, т.е. я могу контрллировать ядра вручную, это гуд. Да, я говорю про голое железо, про i386 и далее

В x86 есть IPI, можно «общаться» с соседями. Если интересуешься таким, возьми третий том Intel SDM сразу и там читай.

не просто интересуюсь... Мне надо уметь это юзать)

а еще мне пока сложно понять, как менеджер процессов в ядре ОС контроллирует работу НАТИВНЫХ программ, переключается ними. А если в программе вечный цикл? Или менеджер процессов как бы "виртуализирует", хавая по команде из кадой программе и выполняя, в зависимости от приоретета

не просто интересуюсь... Мне надо уметь это юзать)

Если вопрос стоит именно так, погляди «Современные операционные системы» Таненбаума для начала.

понял, записал, гуглю

просто менеджер процессов не имеет права неработать долгое время или вообще падать

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

а еще мне пока сложно понять, как менеджер процессов в ядре ОС контроллирует работу НАТИВНЫХ программ, переключается ними. А если в программе вечный цикл? Или менеджер процессов как бы "виртуализирует", хавая по команде из кадой программе и выполняя, в зависимости от приоретета

Есть вытесняющая многозадачность, есть кооперативная. В кооперативной один поток сам должен передать управление другому потоку (или сказать ОС, что с него можно переключиться). При таком подходе вечные циклы проблема. А вытесняющая многозадачность подразумевает наличие таймера, и ОС по прерыванию от таймера, если нужно, сохранит состояние потока и просто переключится на какой-то другой, не спрашивая, что по этому поводу думает сам поток.

Возьми ядро FreeBSD и изучай )

Линукс не рекомендую

Возьми ядро FreeBSD и изучай )

Как вариант. Но Таненбаума всё равно почитать стоит.

Там сам чëрт ногу сломит

Т.е. я могу заранее процу сказать, на какую команду прыгнуть и через какое время, прежде чем передать управление от менеджера задач к процессу?

Т.е. я могу заранее процу сказать, на какую команду прыгнуть и через какое время, прежде чем передать управление от менеджера задач к процессу?

Ты можешь посмотреть, сколько времени работает поток и решить, что этому уже хватит. А таймер тебя все равно постоянно дергает, т.е., ты волей не волей прерываешься, чтобы его обработать.

Ключевая сущность - прерывание от таймера

По нему и планируются потоки

Я не могу посмотреть, потому что поток занял камень. Вопрос пытаюсь рассмотреть в рамках одного ядра в камне

Я запускал десятку на старом одноядерном компе, ради интереса

Ну и IPI, если ядер много

По нему и планируются потоки

Кхм, понял

Я запускал десятку на старом одноядерном компе, ради интереса

И оно работало, да.

А виртуализация, то, что я предложил выше?

Плохая мысль?

Плохая мысль?

Медленно.

А виртуализация, то, что я предложил выше?

Можно сразу и защитить, отсекая всякие прерывания и прочую хрень небезопасную для ядра

Медленно.

Понял.

Да

Можно сразу и защитить, отсекая всякие прерывания и прочую хрень небезопасную для ядра

Ядра ОС

Ядра ОС

Обычно у тебя все равно есть уровни привилегий и MMU в каком-то виде, поэтому с ядром из пользовательского кода и так ничего не сделать. А вот всякие QEMU используют нечто похожее, транслируя исполняемый код на лету. Только обрабатывают не по одной инструкции, а останавливаются на границах блоков кода, обрабатывают следующий и т. д.

ну я в рамках этой учебный работы расчтываю на максимальную переносимость и минималистичность. Не буду пока вообще пологаться MMU

хочу, чтобы апаратно-зависимой частью было небольшое колличество драйверов, для работы с сетевой картой, видео картой, портами и накопителями

я больше в соло то и не вытяну)

и те были модульными, независимыми, дабы можно было перекомпилить, отрубив часть функционала

ну я в рамках этой учебный работы расчтываю на максимальную переносимость и минималистичность. Не буду пока вообще пологаться MMU

В 64-битном режиме хочешь-не хочешь а MMU использовать придется

почему?

почему?

Потому, что длинный режим включается тем же флагом, что и MMU - CR0.PG

т.е. 64 камень стартует в реальном режиме, так? Потом, загрузчик грузит ядро, ядро переводит камень в защищенный режим или длинный режим и тут уже нужно MMU

т.е. 64 камень стартует в реальном режиме, так? Потом, загрузчик грузит ядро, ядро переводит камень в защищенный режим или длинный режим и тут уже нужно MMU

Mожешь из реального сразу в длинный скакать, только установи EFER.LMA=1. Потом выставляй сразу PE и PG и окажешься в длинном режиме. Следом можешь сделать jmp far в 64 битный

Разумеется, нужно подготовить таблицы страниц и загрузить CR3. И да, PAE вобяз.

вот эта тема в виртуальной адресацией - ваще пока не ложится в мозг. Я понимаю, зачем она нужна, но научиться с этим взаимодействовать на низком уровне вручную - чет пока сложно, но я доберусь, обязательно

просто я не понимаю, почему нельзя было бы оставить возможность... Кхм, вот 8 байтовый указатель - вот вся физическая память, добро пожаловать. А если нужна защита - юзаешь MMU