imsushka писал(а):
ну они ж реализованы программно, не аппаратно
значит их можно сделать везде
Но при этом вы получите только часть их функциональности. Как вы уже заметили, в вашем процессоре потоки одной задачи не могут быть запущены на разных ядрах.
imsushka писал(а):
зачем 1 задаче одна страница по двум адресам ?
Зачем - это уже другой вопрос. Я хотел узнать, что в вашем процессоре произойдёт, если одну физическую страницу отобразить на две логических?
imsushka писал(а):
если у нас 1 задача и 1 процессор - проблема будет ?
Ну если вы делаете однозадачный и одноядерный процессор, то проблем не будет. Но в этом случае возвращаемся к вопросу "а в чём преимущества"?
imsushka писал(а):
Yoda писал(а):
Скажите, каким образом передаются сообщения? Что, кем и куда пишется и читается, - процесс опишите, пожалуйста.
а я не знаю
![Улыбается :)](./images/smilies/icon_e_smile.gif)
я на сообщениях и тормознулся когда ось писал
точнее я тормознулся на всем IPC
соответсвенно в железе тоже не реализовал
Ну вот, видите. Как же можно разрабатывать процессор под ОС, не изучив сначала концепции ОС?
Вкратце поясняю. В процессе передачи сообщений выделяется совместно используемая группа страниц памяти (shared memory). Одна задача что-то пишет в эту память, другая задача читает из неё. Конечно можно изобрести альтернативные аппаратные механизмы, но они (как следствие) будут иметь аппаратные ограничения, что крайне нежелательно. Например, при операциях файлового ввода-вывода объём данных, передаваемых между двумя задачами, может быть вообще ничем не ограничен. Таким образом, отображение одной физической страницы в два разных адресных пространства в двух задачах - совершенно необходимый механизм (а значит должна быть решена и проблема когерентности кешей). А чтобы обмен данными при этом не тормозил напрасно в сотни раз, необходимо, чтобы кеш работал на физических адресах, а не на логических.
imsushka писал(а):
отсутсвие тормозов при постоянном переключении задач (то что решено)
Вообще-то, в классических процессорах нет сильных тормозов при переключении задач (если не считать постепенное вытеснение рабочих данных и кода из кешей 2 и 3 уровней новой задачей, но эту проблему ваш процессор не решит). Парадокс заключается в том, что
аппаратное переключение задач на x86 работает медленней, чем программное.
imsushka писал(а):
передача сообщений (не решено)
Увы, ваш процессор не имеет возможности передавать сообщения, по крайней мере, я пока что такого механизма не вижу.
imsushka писал(а):
кароче проц заточенный под микроядро
А поскольку работа микроядра чуть более чем полностью заточена на обмен сообщениями, то ваш процессор именно для этого типа ядер совершенно непригоден.
И опять же, я не вижу,
в чём именно вы видите преимущества.
imsushka писал(а):
вот чо я хотел реализовать
То, что описано, - это некоторая программная абстракция, которая должна быть реализована поверх конкретного аппаратного механизма.
imsushka писал(а):
так нужен поток параленьный? ну заводи 2 задачу с мапированной общей памятью данных, объяви эту область не кешируемой (в 1 уровня кеше) и наслаждайся жизнью
Какой жизнью? На двух ядрах в несколько десятков раз медленней, чем на одном?
imsushka писал(а):
смысл в том что создается новая задача у которой часть или все АП общее с другой задачей
Так ведь ваш процессор не позволяет объединять адресное пространство иначе чем через запрет кеширования.
imsushka писал(а):
андроид - линукс, а раз линукс то значит форк
Так ведь у вас и форк работать не будет.