Sandro>> Хотя было нетривиально. Мне пришлось для одной из подпрограмм писать генератор (точнее, планировщик) ассемблерного кода, т.к. руками разложить все данные по регистрам не удавалось, хотя из анализа было ясно, что должно влезть. Всю ночь писал
Bredonosec> - из этого тут мысль крутится..
Bredonosec> Слушай, а разве мощности вычислительные и мощности памяти не равноценны? Вроде ж при расположении всего добра на пзу - что нарастить логику, что нарастить память, примерно близкие расходы. Почему столь разный подход? Памяти - сколько угодно, а по мощности - вылизывание.
Если бы ... когда мы что-то перекидываем из математики в память, то мы, фактически начинаем пользоваться таблицами. И тут мы попадаем на декартово произведение. Если у нас в математике N входов, каждый из которых имеет M состояний, то размер таблицы выходит M
N .
Степенная функция растёт быстро
Поэтому обычно табулируют только функции с одним параметром (тригонометрию в первую очередь), ну или комбинаторику, где суммарное количество состояний мало.
Хотя бывают, разумеется, и весьма экзотические случаи. Например, Элита на Спектруме для трёхмерных расчётов делала умножение через таблицу квадратов. Есть такой незаслуженно малоизвестный метод.
Но если памяти хватает, то можно и в таблицы. Можно таблицу с программным кодом заранее генерировать для типовых случаев расчёта. Так, например, работает оригинальный Wolfenstein 3D — там прекомпилированный код для всех коэффициэнтов масштабирования текстур. И только поэтому он успевает на 286.
Да можно множество примеров привести. Суть, естественно, в том, чтобы найти правильный баланс для конкретного железа.
Да, игрушки я, разумеется, привожу в качестве примеров, чтоб не помянуть случайно какой-нибудь коммерческий код
Bredonosec> Или дело исключительно в надежности и неубиваемости работы при такой схеме?
См. выше.
Bredonosec> И да, кстати, при обработке каких-то массивов инфы, если произошел сброс до предыдущей контрольной точки, как получается согласование, чтоб некие данные повторно не пошли, как уже новые?
Слишком общий вопрос. Зависит от конкретного устройства. Иногда нужно вообще забыть, что было до рестарта, иногда частично, иногда повторно обработать данные. Зависит от задачи.
Sandro>> При этом контрольные точки немодифицируемы (immutable) — они только сохраняются, и всё. Транзакционная модель с журналированием, в общем-то.
Bredonosec> И сохраняются в той же памяти? В ПЗУ?
Обычно в выделенной энергонезависимой памяти. Так надёжнее. А то представь себе — пишешь ты в ПЗУ рядом с программой, и тут просечка по питанию. Что там запишется? По каким адресам? А кто его знает ...
Выделенная память безопаснее. Тем более, сейчас во многих контроллерах есть встроенная маленькая ПЗУ с побайтовой записью, как раз чтобы хранить настройки и контрольные точки.
В древнем железе с ферритовой памятью было ещё проще — она же по самой своей природе энергонезависима.
Bredonosec> И на какой срок? Неограниченно? Или до создания следующих 2 контрольных точек, как с бэкапами?
Зависит от количества доступной памяти и степени паранойи разработчика
![;) ;)](//s.wrk.ru/s/wink.gif)
Если памяти много — то можно писать хоть всё. Заодно и чёрным ящиком побудет в случае чего. А так — двух точек, да, вполне достаточно в большинстве случаев. Можно и с одной, но тогда потеря контрольной точки должна быть восстановимым отказом. А то вдруг в момент записи чего случится.