Ну, далеко ходить не надо, ОС с ядром mach (микроядерная ОС, где все процессы и драйверы работают в юзермоде). Там все процессы могут быть восстановлены. Точно также большинство военных приложений, там практически всегда требуется прохождение программой контрольных точек и восстановление в случае сбоя с этих контрольных точек.Сообщение от Vladimir Kladov
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
И еще, я например, выработал для себя правило - не использовать в своих проектах бблиотеки и компоненты (vcl/mfc и т.д.) у которых нет исходников (не важно коммерческая библиотека или нет), т.к. в библиотеках глюков предостаточно, а когда нет сорцов, то глюки пофиксить невозможно. Я находил и исправлял не один глюк в контролах и библиотеках для C++ Builder.
Можно сделать гранулярность защиты памяти хоть 1 байт, но если программа портит чужую память которая разрешена на запись, то это никак не поможет. (Например 5 функций используют одну структуру в куче, и одна из функций записывает туда мусор). За правильность работы программы ответственнен ПРОГРАММИСТ и только. Железо - это только инструмент, в противном случае программисты были бы вообще не нужны, компьютеры бы сами писали и отлаживали программы (как в научно фантастических романах).
+1
Кстати тот же Форт весьма просто позволяет зверски переопределить все что можно настолько, что программисту станет "НЕдоступно все".Конечно тормоза возникают, но для тестовой версии самое то. Имхо нормальный контроль юзания аппаратных ресурсов гораздо важнее, чем защита памяти.
Прихожу без разрешения, сею смерть и разрушение...
К сожалению, бывают ситуации, когда использовать чужие библиотеки без исходного кода невозможно. Например: Jpeg, Jpeg2K, Mpeg, Tiff... То, что есть в открытом виде, жутко тормозно, а в случае Tiff'а так вообще половину форматов не понимает. Самое печальное, что не существует нормального описания алгоритма, из которого можно было бы сделать свой код, а тот, что уже есть в открытом виде, не дает понимания того, как это можно сделать по-другому и что-либо оптимизировать. Проще плюнуть и взять готовое в виде откомпилированных jbj-файлов, и ждать, когда все грохнется.
Кривые руки могут быть результатом простой опечатки. Проблема в том, что на х86 вы не сможете обнаружить 10% таких опечаток сразу, а в случае нормальной защиты - 0,1%. Если вы считаете, что труд программиста ничего не стоит, то можете оставаться при своем имхе. Но то, что он стоит намного дороже, чем железо, об этом известно давно. ПО сейчас золотое по сравнению с железом, как раз потому, что софта надо много, и разного, а железо - оно просто клонирует древних ящеров. Тот же арм. Простите меня, но это копия наших советских трехадресных машин: Наири, БЭСМ4. Хорош прогресс...
420 MHz на CycloneII ?
Вот первые результаты. Это на 1 такте получается, на 1 небольшом (но важном) устройстве. Кажется, 420 MHz - близко к границе возможного на CycloneII, но неясно, как бы оно было на более быстром чипе. Web Edition обламывает с выбором чипа, зараза.
Info: Clock "clk" Internal fmax is restricted to 420.17 MHz between source register "OperRegQueue_mux1:mux0|out_num3[0]" and destination register "OperRegQueue_mux1:mux0|out_num3[0]"
Info: fmax restricted to clock pin edge rate 2.38 ns. Expand message to see actual delay path.
Info: + Longest register to register delay is 0.407 ns
Info: 1: + IC(0.000 ns) + CELL(0.000 ns) = 0.000 ns; Loc. = LCFF_X83_Y1_N25; Fanout = 2; REG Node = 'OperRegQueue_mux1:mux0|out_num3[0]'
Info: 2: + IC(0.000 ns) + CELL(0.323 ns) = 0.323 ns; Loc. = LCCOMB_X83_Y1_N24; Fanout = 1; COMB Node = 'OperRegQueue_mux1:mux0|out_num3[0]~11'
Info: 3: + IC(0.000 ns) + CELL(0.084 ns) = 0.407 ns; Loc. = LCFF_X83_Y1_N25; Fanout = 2; REG Node = 'OperRegQueue_mux1:mux0|out_num3[0]'
Info: Total cell delay = 0.407 ns ( 100.00 % )
Info: - Smallest clock skew is 0.000 ns
Info: + Shortest clock path from clock "clk" to destination register is 2.906 ns
Info: 1: + IC(0.000 ns) + CELL(0.989 ns) = 0.989 ns; Loc. = PIN_T2; Fanout = 1; CLK Node = 'clk'
Info: 2: + IC(0.114 ns) + CELL(0.000 ns) = 1.103 ns; Loc. = CLKCTRL_G3; Fanout = 192; COMB Node = 'clk~clkctrl'
Info: 3: + IC(1.266 ns) + CELL(0.537 ns) = 2.906 ns; Loc. = LCFF_X83_Y1_N25; Fanout = 2; REG Node = 'OperRegQueue_mux1:mux0|out_num3[0]'
Info: Total cell delay = 1.526 ns ( 52.51 % )
Info: Total interconnect delay = 1.380 ns ( 47.49 % )
Info: - Longest clock path from clock "clk" to source register is 2.906 ns
Info: 1: + IC(0.000 ns) + CELL(0.989 ns) = 0.989 ns; Loc. = PIN_T2; Fanout = 1; CLK Node = 'clk'
Info: 2: + IC(0.114 ns) + CELL(0.000 ns) = 1.103 ns; Loc. = CLKCTRL_G3; Fanout = 192; COMB Node = 'clk~clkctrl'
Info: 3: + IC(1.266 ns) + CELL(0.537 ns) = 2.906 ns; Loc. = LCFF_X83_Y1_N25; Fanout = 2; REG Node = 'OperRegQueue_mux1:mux0|out_num3[0]'
Info: Total cell delay = 1.526 ns ( 52.51 % )
Info: Total interconnect delay = 1.380 ns ( 47.49 % )
Info: + Micro clock to output delay of source is 0.250 ns
Info: + Micro setup delay of destination is -0.036 ns
Ладно, пойду пока 2ю ступень этого конвейера рисовать в verolg'е.
Могу дать ссылку на полный эдишен (правда там 700-800Мб придется с ftp скачивать) и лекарство в личку скинуть.
Последний раз редактировалось deathsoft; 28.01.2007 в 13:02.
Ну, трехадресность то тоже не у нас придумали (БЭСМ4 и НАИРИ - это просто отечественная реализация трехадресной машины), тот же MIX кнута - трехадресный.
Это есть у интела (http://www.intel.com/cd/software/pro...ipp/302910.htm) с оптимизацией под самые последние процы.
В этуж библиотеку входят и mpg-2, mpeg-4, H.263, H.264 кодеры/декодеры.
Последний раз редактировалось deathsoft; 28.01.2007 в 13:01.
Скорее всего существует, но этот стандарт просто платный, или патентованый и распространяется под NDA.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
