andrewn

С помощью оператора декремента получаем --С = SPRUHV6 — PRU Assembly Language Tools User's Guide

Из документации по армам 5 версии. 926EJ-S это как раз архитектура V5TE: ARM DDI 0100I (это pdf), вот линк. В пдф файле есть DSP subset. Preface (про Е вариант), A2.5.3, A3-16, и глава 4. (Варианты архитектуры (до V6) перечислены в Preface)

Более плотная жидкость стекает вниз. Металлическая гайка в сахаре утонет, а кусок рафинада всплывёт - как камешек и деревяшка. Плотности разные. Это зыбучие пески.... Вот маленький список литературы http://ru.wikipedia.org/wiki/Динамика_сыпучих_сред http://ru.wikipedia.org/wiki/Сыпучее_тело http://ru.wikipedia.org/wiki/Зыбучий_песок В банке с гайками человек не утонет. Это радует...

Гложет меня обоснованное сомнение, что вы безбожно путаете и упрощаете. Задачи, которые решают методом мол.динамики это статистические задачи, где молекулы абстрагируются шариками, а силы каким-нибудь потенциалом Леннарда-Джонса. Задачи на конфигурацию и деформации с шариками работать не могут, конфигурация молекулы в основном состоянии определяется ковалентными связями (и не только, если есть, например водородные связи), кроме того, взаимодействие между частями молекулы и между разными молекулами определяется целой гамммой ван-дер-ваальсовых и дисперсионных (лондоновских) сил, диполь-дипольных (мгновенный диполь с наведённым и/или с постоянным диполем, постоянные диполи друг с другом, мгновенные диполи), и ион-дипольных взаимодействий - в растворах например. Дисперсионные силы не имеют классического аналога. Это уж никак не молекулярная динамика.

Этих, условно, "зон" и есть три, RGB, просто названы замысловато. Мозаика Байера светофильтров (Color Filter Array, CFA) простая: +-+-+ |B|G| +-+-+ |G|R| +-+-+ а потом пересчитывают, что бы из 4 компонент получить три. В этом файле на стр 3 есть пример (второй график снизу). Интересно, что все три светофильтра пропускают ИК.

А это расшифровка "дошлифовки" и "последовательности выч. операций" была. Но я не настаиваю. Beauty is in the eye of the beholder...

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

Предположительно, самодельный загрузчик не инициализирует переменные, а программа скомпилирована с опцией "load-time autoinitialization", а нужна опция "run-time autoinitialization". Другое предположение - программа собрана с одним мапом, но грузится в другие адреса. И т.д...

Ничего, новая отрастёт... А вообще, это прогресс. У вас эрмит 4х4, можно вас попросить для примера привести по паре матриц для больших и малых углов. А разве в TS201 long double отличается от double?

Жаль, что не удалось узнать, что думает экзаминатор по поводу своей задачи... ОР молчит...

А ещё лучше принтфом прикинуться, и как только видишь, что экзаменатор count собрался печатать, так сразу хлобысь и печатаешь двойку (болдом!) :-) И переменную портить не надо - наследить лишний раз...

RR это, RR. Посмотрите на 1) в решении - А и В прочитали нулевой счётчик. И встали в хвост. А потом три пробежали до упора. P.S. Для ясности облегчу себе участь - скажем, что тайм-слайс очень большой. И только внешние события, над которыми у нас власти нет, заставляют планировщик менять задачи. И, если задача прерывается, то планировщик ставит её в хвост.

Неизвестные процессы не в МК, а в условии исходной задачи. Они, естественно, не заданы, но их присутствие в выч. системе, естественно, неявно подразумевается. Кроме всего прочего, термин МК в условиях не фигурирует. Я попытался пересчитать решение для детерминистского алгоритма планировщика, такого, который бы без оговорок мог использоваться в RTOS. Для preemptive round robin для равноприоритетных процессов планировки решение абсолютно возможное (feasible). Ход своих рассуждений опускаю, они очевидные. Об ослинуксе не было ни слова. Насчет "[...] фантазий" - полегче на поворотах, почтеннейший, не в рыбной лавке. Я эту подсказку воспринял в смысле, что двойку можно получить (не обязательно получить, а возможно) независимо от числа процессов и независимо от числа итераций. В моём решении это явно видно: три процесса стартуют и завершаются ни на что не влияя, остальные два явно используют отсылку только к первой итерации, предпоследней итерации и последней итерации. А статистику копить - такого в условии не было. Пока даже предположить не берусь, какое было бы распределение результатов и как оно зависисело бы от загрузки выч. системы. Гипотетически - распределение скорее всего равномерное. Ребята, а дайте мне грант на месяц (пару миллионов сов. рупий) и я это поисследую :-)

Это была всего лишь экзаменационная задача... А планировщик - это Я. :-) Увы, задачи по параллельным процессам так не формулируются. Есть процессы, которы формируются явно, исходя из условий задачи. И, кроме этого, неявно предполагается, что в вычислительной системе есть внешние, неизвестные процессы, которые занимают время ЦПУ, но не взаимодействуют с процессами задачи. Алгоритм планировщика предполагается неизвестным, и более того, предполагается недетерминистским. Т.е. никак нельзя сказать в каком порядке могут быть спланированы два равноприоритетных процесса.

Да, в условии явно это не сказано, но подразумевается достаточно определённо - из семантики вызовов create(). Однако же окружение модельной задачи остаётся полностью неопределённым и неизвестным. Отсюда и хаос и индетерминизм. А планировщик может использовать совершенно детерминированный алгоритм, реального времени в том числе. В РТОСе я чюдеса всякие и наблюдал... К вопросу о прерываниях. Может ли последовательность инструкций INSTR I INSTR I+1 INSTR I+2 быть прервана подряд на каждой инструкции - т.е. три раза подряд. Да элементарно может. Это только кажется, что между ними (инструкциями) время обратное частоте ЦПУ, и, соответственно, бешеная частота потока прерываний. Так бы было без прерываний. А нужно учитывать время, потраченное на обработку прерывания в ISR, на последующий вызов драйвера или приоритетной задачи - в итоге частота прерываний невелика, а процесс прерывается на каждой инструкции. Или, поскольку прерывания распределены по времени _неравномерно_ (как-то по пуассону, грубо говоря, или по бернулли), то через неопределённое число инструкций, но в том числе и через раз и через два и через три... Я надеюсь, что нет, не обязательно. Иначе экзаменатора действительно надо казнить тяжёлым шершавым холодным мьютексом...