Страница 1 из 1

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

СообщениеДобавлено: 25 май 2009, 17:54
ArtemG
В рамках данного проекта разрабатывается новая архитектура микропроцессора, обеспечивающая независимость выполнения задач не только в функциональном, что характерно для систем общего назначения, но и во временном аспекте, что играет главную роль для систем реального времени и встроенных систем. ВременнАя независимость должна упростить создание подобных систем. Критериями оценки упрощения разработки систем на основе микроконтроллеров служат: количество блокировок, используемых в программном проекте, размер программного кода, количество вычислений необходимых для определения времени ответа (минимальное, среднее, максимальное) на входные значения.

Re: Модель микроконтроллера с параллельным выполнением программ

СообщениеДобавлено: 26 май 2009, 16:39
Соратник слонопотама
1. На слайде "Функционирование вычислительных устройств" сокращение "АП" - это адресное пространство или где?

2. Что включает в себя "контекст выполнения программ"? Вообще, как ты видишь отличие одного вычислительного ядра с несколькими контекстами (вообще-то принято называть это multithreading) от нескольких самостоятельных вычислительных ядер?

3. Как делятся общие ресурсы между программами, выполняемыми в разных контекстах, но на одном "исполнительном устройстве"? Например, если одна программа хочет стереть сектор во флэш-памяти (это дело явно не одной команды), а вторая в то же время будет считывать из флэш-памяти данные (и команда чтения будет восприниматься как продолжение команды записи) - или использование флэша данных в такой архитектуре не предполагается? Тогда можно придумать другие примеры.

Re: Модель микроконтроллера с параллельным выполнением программ

СообщениеДобавлено: 27 май 2009, 02:20
ArtemG
Соратник слонопотама писал(а):1. На слайде "Функционирование вычислительных устройств" сокращение "АП" - это адресное пространство или где?

да, там 2 адресных пространства.

Соратник слонопотама писал(а):2. Что включает в себя "контекст выполнения программ"? Вообще, как ты видишь отличие одного вычислительного ядра с несколькими контекстами (вообще-то принято называть это multithreading) от нескольких самостоятельных вычислительных ядер?

Контекст выполнения программы включает в себя два адресных пространства(данных и кода) и отображение этих пространств на некоторые ресурсы.
Да, идея не нова, такой тип многозадачности называется Interleaved multithreading или Temporal multithreading ( http://en.wikipedia.org/wiki/Multithrea ... -threading ). Существуют даже процессоры, которые могут работать с такой многозадачностью.
Отличия. Несколько ядер - они работают в истинном параллелизме обычно от отдного генератора частоты с частотой K т.е. каждое работает с частотой K. Места на кристалле занимает каждое ядро+доп расходы на связь между ними. В вычислительном ядре с несколькими контекстами выполнения существует одно ядро тактируемое от генератора с частотой K, и N контекстов выполнения, т.е. можно скзазать, что каждый контекст выполняется ядром, параллельно с другими, с частотой K/N. Места на кристалле занимается под одно ядро + доп расходы на комутацию.

Соратник слонопотама писал(а):3. Как делятся общие ресурсы между программами, выполняемыми в разных контекстах, но на одном "исполнительном устройстве"? Например, если одна программа хочет стереть сектор во флэш-памяти (это дело явно не одной команды), а вторая в то же время будет считывать из флэш-памяти данные (и команда чтения будет восприниматься как продолжение команды записи) - или использование флэша данных в такой архитектуре не предполагается? Тогда можно придумать другие примеры.

Этот вопрос в конечном счете решается программистом. Возможности, которые предоставляет архитектура - это создание приватных (когда на адрес ресурса есть отображение только из одного адресного пространства) и общих (когда на адрес ресурса есть отображение из нескольких адресных пространств) адресов ресурсов. Простой вариант реализации - объявление общей flash памяти, объявление общей ячейки памяти в SRAM для блокировки и дальше с помощью ассемблерной команды test_and_set или похожей делать spinlock для обеспечения блокировки.

Re: Модель микроконтроллера с параллельным выполнением программ

СообщениеДобавлено: 27 май 2009, 10:47
Соратник слонопотама
ArtemG писал(а):Контекст выполнения программы включает в себя два адресных пространства(данных и кода) и отображение этих пространств на некоторые ресурсы.
Да, идея не нова, такой тип многозадачности называется Interleaved multithreading или Temporal multithreading ( http://en.wikipedia.org/wiki/Multithrea ... -threading ). Существуют даже процессоры, которые могут работать с такой многозадачностью.
Отличия. Несколько ядер - они работают в истинном параллелизме обычно от отдного генератора частоты с частотой K т.е. каждое работает с частотой K. Места на кристалле занимает каждое ядро+доп расходы на связь между ними. В вычислительном ядре с несколькими контекстами выполнения существует одно ядро тактируемое от генератора с частотой K, и N контекстов выполнения, т.е. можно скзазать, что каждый контекст выполняется ядром, параллельно с другими, с частотой K/N. Места на кристалле занимается под одно ядро + доп расходы на комутацию.

Если мне не изменяет память, каждый контекст выполнения подразумевает, как минимум, наличие собственных регистров общего назначения, флагов АЛУ, уж не знаю как насчёт SFR-ов. Также, вроде бы, энергопотребление возрастает пропорционально квадрату частоты. Учитывая, что в случае multithreading-а по сравнению с многоядерностью мы экономим площадь кристалла фактически только за счёт разделяемых функциональных блоков ядра (ALU, FPU, устройство управления, контроллеры памяти и т.д.), т.е. не в N раз, а существенно поменьше, не очень очевидно преимущество одного многопоточного 50-150МГц-ового ядра перед несколькими однопоточными 10МГц-овыми ядрами.

ArtemG писал(а):Этот вопрос в конечном счете решается программистом. Возможности, которые предоставляет архитектура - это создание приватных (когда на адрес ресурса есть отображение только из одного адресного пространства) и общих (когда на адрес ресурса есть отображение из нескольких адресных пространств) адресов ресурсов. Простой вариант реализации - объявление общей flash памяти, объявление общей ячейки памяти в SRAM для блокировки и дальше с помощью ассемблерной команды test_and_set или похожей делать spinlock для обеспечения блокировки.

В общем, для такой архитектуры всё те же грабли - кривые руки программистов :D

Re: Модель микроконтроллера с параллельным выполнением программ

СообщениеДобавлено: 27 май 2009, 12:43
ArtemG
Соратник слонопотама писал(а):Если мне не изменяет память, каждый контекст выполнения подразумевает, как минимум, наличие собственных регистров общего назначения, флагов АЛУ, уж не знаю как насчёт SFR-ов. Также, вроде бы, энергопотребление возрастает пропорционально квадрату частоты. Учитывая, что в случае multithreading-а по сравнению с многоядерностью мы экономим площадь кристалла фактически только за счёт разделяемых функциональных блоков ядра (ALU, FPU, устройство управления, контроллеры памяти и т.д.), т.е. не в N раз, а существенно поменьше, не очень очевидно преимущество одного многопоточного 50-150МГц-ового ядра перед несколькими однопоточными 10МГц-овыми ядрами.

Собственные регистры, флаги АЛУ, SFR, Program Counter, ... все это находится в SRAM на которую отображаются адреса из контекста выполнения.
Насчет энергопотребления сказать увы ничего не могу. Даже если так, то физически микроконтроллер будет тактироваться с одной частотой в обоих случаях, только архитектурная реализация разная.
Главных преимуществ у Interleaved multithreading два:
1. Гарантированное время выполнения в каждом потоке выполнения, независимо от других, т.е. мы можем сказать что столько-то команд в вычислительном процессе выполнятся за определенное время. И например, если один поток зависнет, то это никак не отобразится на других.
2. Так как одна задача относительно независима от других, то и вероятность зависимости данных в последовательно выполняющихся инструкциях мала, что позволяет просто организовывать эффективный конвейер.
В общем, для такой архитектуры всё те же грабли - кривые руки программистов :D

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

Re: Модель микроконтроллера с параллельным выполнением программ

СообщениеДобавлено: 27 май 2009, 16:58
Соратник слонопотама
ArtemG писал(а):Главных преимуществ у Interleaved multithreading два:
1. Гарантированное время выполнения в каждом потоке выполнения, независимо от других, т.е. мы можем сказать что столько-то команд в вычислительном процессе выполнятся за определенное время. И например, если один поток зависнет, то это никак не отобразится на других.
2. Так как одна задача относительно независима от других, то и вероятность зависимости данных в последовательно выполняющихся инструкциях мала, что позволяет просто организовывать эффективный конвейер.

Всё это очень подозрительно. Во-первых, как бы не были задачи независимы друг от друга, им таки придёцца общаться и делить ресурсы (даже если их будет делить отдельный процесс), соответственно, возможны блокировки и т.д. Ведь планировщик никуда не делся - просто он стал аппаратным, соответственно и проблемы никуда не делись - можеть лишь чуток видоизменились. Может, и есть какой-нибудь чудный способ обеспечить таким образом QoS, однако они есть и для "обычных" ОСРВ. Особой простоты я что-то не вижу, а в чем тогда преимущество? Чтобы завоевать место под солнцем, преимущества должны быть видны невооруженным глазом! :smile:
Насчет конвейера, эффективности и простоты его организации... хотелось бы взглянуть на реализацию =))))

Re: Модель микроконтроллера с параллельным выполнением программ

СообщениеДобавлено: 27 май 2009, 21:45
ArtemG
Соратник слонопотама писал(а):Всё это очень подозрительно. Во-первых, как бы не были задачи независимы друг от друга, им таки придёцца общаться и делить ресурсы (даже если их будет делить отдельный процесс), соответственно, возможны блокировки и т.д. Ведь планировщик никуда не делся - просто он стал аппаратным, соответственно и проблемы никуда не делись - можеть лишь чуток видоизменились. Может, и есть какой-нибудь чудный способ обеспечить таким образом QoS, однако они есть и для "обычных" ОСРВ. Особой простоты я что-то не вижу, а в чем тогда преимущество? Чтобы завоевать место под солнцем, преимущества должны быть видны невооруженным глазом! :smile:
Насчет конвейера, эффективности и простоты его организации... хотелось бы взглянуть на реализацию =))))

Какие проблемы никуда не делись? Я говорил о том, что в традиционной многозадачности в том числе в ОСРВ существует временнАя зависимость между независимыми задачами, в данной архитектуре ее нету.
Конвейер даже реализовывать не нужно, чтобы понять что его эффективность будет выше за счет того, что он будет реже сбрасываться.