Приглашаю обсудить новую архитектуру

[almandrykin]

Сообщение от Smitt&Wesson

Журнал "Радиолюбитель 97-99" . Есть в бумажном варианте, как курсовая, но, думаю это не для слабонервных.
Одного ассемблерного кода 50 листов. Вам это нужно? Уверен, что - нет.

Журнал "Радиолюбитель 97-99" это наверняка код для КР580ВМ80А, как для самого доступного процессора того времени. Действительно, нет интереса соревноваться с КР580ВМ80А

[Smitt&Wesson]

Сообщение от almandrykin

Журнал "Радиолюбитель 97-99" это наверняка код для КР580ВМ80А, как для самого доступного процессора того времени. Действительно, нет интереса соревноваться с КР580ВМ80А

Для него. Он слизан с Z80 в усечённом варианте, а архитектуру зделал Дмитриев (может и ошибаюсь), но совок (гражданин СССР).

[almandrykin]

Сообщение от p51x

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

Таймер управляется планировщиком. Планировщик записывает в таймер время ближайшего события. Если, вдруг, приходит прерывание ранее срабатывания таймера, то планировщик переустанавливает таймер.

Если нужна задержка на одну секунду, то помещаете в регистр таймаута значение, равное количеству тактовых импульсов в 1 секунде, и посылаете сообщение самому себе или ждёте сообщение от самого себя. Через 1 секунду инструкция завершится со статусом ошибки "Истекло время ожидания передачи сообщения". Реализация - три инструкции.

Вы считает, что один на форуме такой умный и никто больше ничего не знает про фпга?

Разумеется - нет. Сожалею, что у Вас возникло такое впечатление.

У вас в проце, кажись, 16 регистров. Я вас спросил про контекст и прерывания, а вы начали - ну тут в фпга место было и мы еще банк регистров сбабахали, в проце тоже будет несколько банков?

Да, в процессоре тоже будет несколько банков. Возможно, даже больше чем в FPGA. И в этом нет ничего плохого.

Похоже вы никогда не программировали низкоуровнево, а тем более микропроцессора (хоть вроде и хвалились).

Верилог я начал изучать относительно недавно - стартанул около двух лет назад.
А вот насчёт низкоуровнеого программирования категорически несогласен. Обратите внимание на эту страницу - http://l4os.ru/xameleon-download

Угу, а еще это значит отключение памяти (а может ее сброс на диск/нанд), тормоз переферии, переключение на пониженное тактирование, ... и восстановление потом всего. За один такт у вас опора нестабилизируется, не говоря уже о готовности системы к обработке задачи на полном ходу. Ну или это не повердаун, а так...

Нет нет нет. Я не имел в виду хибернацию операционной системы. Речь всего лишь шла о переходе процессора в состояние низкого энергопотребления. Например, x86 переходит в этот режим с помощью инструкции HLT в привелегированной задаче. Выход из него по любому прерыванию. В системе команд "Эверест" нет необходимости в такой инструкции - в случае, когда все задачи находятся в состоянии ожидания, процессор сам переходит в состояние низкого энергопотребеления - отключаются тактовые импульсы от большинства блоков и по этой причине резко падает его энергопотребеление.

Отключение же периферии это отвественность операционной системы. По большому счёту процессор ничего не знает об оборудовании - за оборудованием следит операционная система.

Какое время простоя вы о чем? Если задача плюнет на запрос планировщика, что будет с ситемой? Вы хоть что-нибудь о реальном устройстве читали? Знаете, что такое многозадачность? Почему есть вытесняющая многозадачность? Почему и для чего планировщик не спрашивая квантует и переключает задачи?

Тише тише тише. Что же Вы так разогнали-то лошадей? Ну вот с чего Вы взяли, что задача "плюёт на запрос планировщика" и как такое вообще возможно? Впрочем, похоже мы оба виноваты в этом взаимонепонимании - я плохо объясняю, Вы не желаете понимать. Итак...

Время простоя Вы можете лицезреть на своём десктопе, запустив, например, диспетчер задач Windows - в обычном режиме загрузка процессора минимальна - это я и называю временем простоя. Процессор на миг выходит из спячки, за доли секунды успевает сделать свои задачи, (например, показать или погасить графический курсор) и опять в сон. Как я уже говорил, на x86 для этого используется инструкция HLT. С "простоем", я полагаю, мы разобрались.

Задача по определению не может "плевать" на запрос планировщика, поскольку архитектурно нет способа помешать планировщику - сработал таймер, планировщик переключил задачу, подменив счётчик команд и регистры общего назначения, при этом задача даже не знает, что она была остановлена. Но я повторюсь - переключение задачи по инициативе планировщика это с большой долей вероятности ошибка в алгоритме. Потому что правильной точкой переключения задач являются две инструкции - SEND и RECV. Именно эти инструкции являются точкой переключения задач. Т.е. архитектура подразумевает что задача с большой вероятностью выполнит инструкцию SEND или RECV до истеченеия её кванта времени. Это как бы священная корова всей архитектуры.

/* традиционное ограничение на длину поста - продолжение следует */

[almandrykin]

Ранняя Вин ХП блокировалась и то не всегда, все остально неи. Это ваши фантазии.

В бытность свою программистом в Южной Корее, мне довелось писать драйвер для Windows 2000, затем переносить его под Windows XP, а затем писать аналогичный драйвер для Linux. Скажу честно - пробовать реализовать бесконечный цикл в драйвере мне не приходило в голову, но как оно там устроено внутри - представление имею. С большой долей вероятности могу предположить что такой цикл приведёт или к полномму зависанию, или к BSOD. Так же предполагаю что подобное поведение будет и в самой последней Windows 8. Проверять лениво, ибо это ничего не доказывает и к спору отношение не имеет.

И такие люди делают процы... Вам прямая дорога к друзьям из мультиклета (тоже хвалились и сказки рисовали, а на деле...)

Тут, наверное, самое время позлорадствовать на Мультклетовцами, но нет. Я не могу оценить их архитектуру, но уверен что они занимаются правильным делом - время расставит всё по местам и если их архитектура удачная, то она завоюет себе место под Солнцем. А что, неужели разработчики "Мультиклета" пиарились на programmersforum.ru?

[imsushka]

Сообщение от Smitt&Wesson

Для него. Он слизан с Z80 в усечённом варианте, а архитектуру зделал Дмитриев (может и ошибаюсь), но совок (гражданин СССР).

какой такой слизан ?!?!??!

з80 это расширенный и8080 с которого и был слизан 580вм80а

историю знать надо

[p51x]

Если, вдруг, приходит прерывание ранее срабатывания таймера, то планировщик переустанавливает таймер.

Зачем? Как он учтет время обработки прерывания? А что если таймер должен был сработать в момент вашего прерывания?

Если нужна задержка на одну секунду, то помещаете в регистр таймаута значение, равное количеству тактовых импульсов в 1 секунде

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

и посылаете сообщение самому себе или ждёте сообщение от самого себя

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

Через 1 секунду инструкция завершится со статусом ошибки "Истекло время ожидания передачи сообщения".

Чем это отличает от простого пустого цикла? Да и оверхед поменьше будет.

Да, в процессоре тоже будет несколько банков. Возможно, даже больше чем в FPGA.

Надеюсь вы представляете сложность управления таким зоопарком? А размеры проца для всего этого?

Нет нет нет. Я не имел в виду хибернацию операционной системы. Речь всего лишь шла о переходе процессора в состояние низкого энергопотребления.

Вот поэтому я и говорил о вашем опыте в низкоуровневом программировании... Вы путаете проц и ОС, их возможности и задачи. Вы что разрабатываете? Проw или прослойку между ОС и процом? Гибернация ОС это одно, а "низкое энергопотребление" это другое...

В системе команд "Эверест" нет необходимости в такой инструкции - в случае, когда все задачи находятся в состоянии ожидания, процессор сам переходит в состояние низкого энергопотребеления - отключаются тактовые импульсы от большинства блоков и по этой причине резко падает его энергопотребеление.

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

Отключение же периферии это отвественность операционной системы. По большому счёту процессор ничего не знает об оборудовании - за оборудованием следит операционная система.

И опять вы путаете сладкое с мягким. Периферия проца и устройства подключенные к компу/ОС это не одно и то же. Почитайте уже что-нибудь. Например ваш таймер, блок порта, памяти, ппл, ... это к процу, а вот дисковод можно считать ОСным.

В системе команд "Эверест" нет необходимости в такой инструкции - в случае, когда все задачи находятся в состоянии ожидания, процессор сам переходит в состояние низкого энергопотребеления - отключаются тактовые импульсы от большинства блоков и по этой причине резко падает его энергопотребеление.

Итого: ваш проц будет иметь очень узкоспециализированное применение... Представить, что любая ОС будет работать с утройствами постоянно их переподключая, переинициализируя и т.д., а задачи и обработчики будут либо пропускаться, либо работать с большим оверхедом.

Ну вот с чего Вы взяли, что задача "плюёт на запрос планировщика" и как такое вообще возможно?

Вы же сами писали и не отвечали на предыдущие вопросы, а из них следует, что планировщик не переключает задачи, а посылаем им сообщения типа "поработай", "усни". Как? Долгий цикл и анализ сообщений только в конце итерации - квант в пролете.

Впрочем, похоже мы оба виноваты в этом взаимонепонимании - я плохо объясняю, Вы не желаете понимать.

Не валите с больной головы на здоровую.

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

Т.е. уже задачи переключаются. Оки.

Но я повторюсь - переключение задачи по инициативе планировщика это с большой долей вероятности ошибка в алгоритме. Потому что правильной точкой переключения задач являются две инструкции - SEND и RECV. Именно эти инструкции являются точкой переключения задач. Т.е. архитектура подразумевает что задача с большой вероятностью выполнит инструкцию SEND или RECV до истеченеия её кванта времени. Это как бы священная корова всей архитектуры.

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

[p51x]

С большой долей вероятности могу предположить что такой цикл приведёт или к полномму зависанию, или к BSOD.

Т.е. уже бсод допускается? Без всяких вероятностей на винде стандартная настройка бсод по ватчдогу.

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

Ну идея может и имеет место быть, но не знаний, не опыта, не подвижек нет.

А что, неужели разработчики "Мультиклета" пиарились на programmersforum.ru?

Неее... Это рабочий момент, приносили еще тоже на фпга потестить, отзывы пописания, обсудить архитектуру и возможности.

[imsushka]

almandrykin

может лучше Описать что в связке l4os/проц решается программно , а что аппаратно ?
а вот городить очередную систему команд не стоит ?
причем она мало чем оличается от МИПСа

[almandrykin]

Сообщение от p51x

Зачем? Как он учтет время обработки прерывания? А что если таймер должен был сработать в момент вашего прерывания?

Предлагаю считать время в тактах. Например, на плате Марсоход2 тактовая частота равна 100МГц - вот от неё и "плясать". Временные интервалы тоже считать в тактах.

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

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

libc в момент иниициализации.

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

Послать то она может, да кто же будет слушать, если сообщения СИНХРОННЫЕ и задача в этот момент блокирована в фазе передачи? Вот до таймаута планировщик ни разу не передаст сообщение блокированной задаче.

Чем это отличает от простого пустого цикла? Да и оверхед поменьше будет.

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

Надеюсь вы представляете сложность управления таким зоопарком? А размеры проца для всего этого?

Вот поэтому я и говорил о вашем опыте в низкоуровневом программировании... Вы путаете проц и ОС, их возможности и задачи. Вы что разрабатываете? Проw или прослойку между ОС и процом? Гибернация ОС это одно, а "низкое энергопотребление" это другое...

Давайте без демагогии? Я же Вам ссылки дал на образы загрузочных дискет - посмотрите на даты, подсуньте образ виртуальной машине, потестируйте. Если честно, да простят меня уважаемые форумчане, то мне кажется что уровень познаний ОС у Вас остановился на уровне MS-DOS. Ну вот судя по коментариям о циклах, прерывниях и прочих тонкостях.

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

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

С чего Вы взяли что в момент простоя у процессора отключается питание? Выше черным-по-белому написано, что переход в режим низкого энергопоребления реализуется через отключение тактовых импульсов от основных блоков процессора. При этом состояние регистров не теряется, питание к схеме остаётся подведено.

И опять вы путаете сладкое с мягким. Периферия проца и устройства подключенные к компу/ОС это не одно и то же. Почитайте уже что-нибудь. Например ваш таймер, блок порта, памяти, ппл, ... это к процу, а вот дисковод можно считать ОСным.

Итого: ваш проц будет иметь очень узкоспециализированное применение... Представить, что любая ОС будет работать с утройствами постоянно их переподключая, переинициализируя и т.д., а задачи и обработчики будут либо пропускаться, либо работать с большим оверхедом.

С точностью до наоборот - никаких лишних переключений контекста. Да запустите уже демку Хамелеона, всего-то и нужно поставить MS Virtual PC, VMWare Workstation или Oracle VM VirtualBox и загрузится с образа дискеты, ссылку на который я дал в предыдущем посте.

Попробуйте хотя бы http://l4os.ru/concept

Понимаете, тот факт, что я зарегистрировался на programmersforum.ru несколько дней назад, он никак не значит что все эти вопросы в течение 10 лет не были "перетёрты" на дугих ресурсах.

Вы же сами писали и не отвечали на предыдущие вопросы, а из них следует, что планировщик не переключает задачи, а посылаем им сообщения типа "поработай", "усни".

Покажите где я такое писал.

Как? Долгий цикл и анализ сообщений только в конце итерации - квант в пролете.

http://everest.l4os.ru/simple_scheduler/

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

Предлагаю почитать что-нибудь о микроядре L4, желательно о версии L4X2 и микроядре Pistachio.

[almandrykin]

Сообщение от imsushka

almandrykin
может лучше Описать что в связке l4os/проц решается программно , а что аппаратно ?
а вот городить очередную систему команд не стоит ?

Я провел чертовски много времени на http://opencores.org
Поначалу так и хотел - взять готовый проц и запихнуть в него микроядро.
Пока смотрел как люди делают свои процессоры, родилась архитектура нового.

причем она мало чем оличается от МИПСа

MIPS это RISC, а эта архитектура гораздо ближе к CISC