У нас много чего применяли, только это не прижилось. Завод "Светлана" (у нас в Питере) выпускал полностью асинхронные процессоры (без сигнала тактирования), работали они по принципу запрос-ответ (ready/busy), но распространения эта идея не получила, т.к. процы были склонны к зависаниям, а проверить факт зависания было невозможно.

Но вообще, создание проца с собственной архитектурой занятие полезное, т.к. можно вживую увидеть все достоинства и недостатки той или другой вычислительной архитектуры. Раньше (когда не было ПЛИС) это можно было сделать только на моделях (выпуск в железе могли себе позволить только крупные заводы), а теперь можно сделать и в железе.

какую таблицу... Нет никакой таблицы. Вот представьте - 4 байта по адресу 0000_0104H. И "под" ними - 4 байта дескриптора, по адресу 1_0000_0104H. На самом деле, теневая память с дескрипторами может адресоваться так, чтобы в SDRAM обе четверки попали в одну линейку. И может быть групповой дескриптор на 256 байт. И думаю, этого достаточно. Памяти - ровно в 2 раза больше надо. Зато программистам будет проще жить - сейчас этот ресурс дороже какой-то там памяти.

Где это взять, это в ПЦ есть? Как задействовать? Колись уже, а то у меня ситуация с прогой именно такая вышла - пришлось отложить проект и надолго (нет, не EmuZWin, с ним все в порядке, просто некогда).

Если про это:
Model-Specific Registers – модельно-специфические регистры.

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

...

Команды RDMSR и WRMSR

Команда RDMSR (ReaD from Model Specific Register) выполняет чтение из MSR-регистра. Действие команды заключается в проверке двух условий: во-первых, проверяется наличие нулевого уровня привилегированности кода, во-вторых, проверяется наличие в регистре ECX значения, адресующего один из MSR-регистров. Если хотя бы одно из этих условий не выполняется, то выполнение команды RDMSR заканчивается. Если выполняются оба условия, то значение MSR-регистра, адресуемого содержимым регистра ECX, помещается в пару 32-битных регистров EDX:EAX.

то это вряд ли поможет.

Ну - это дико не оптимально. Это примерно как Бил Гейтс везде продвигает свой бейсик и C# (хотя это дикие тормоза и огромный бесполезный расход памяти, в результате чего любой комп. работает со скоростью 386го). Вспомните алгоритмы из книг Кнута (там все было оптимально и написано на ассемблере).

Да есть во всех процах начиная с Pentium Pro (см. интеловскую доку по процу том 3)

Для этого есть DevPartner Studio (раньше BoundsChecker).

Да, конечно, неоптимально. Хранить boolean в байте - тоже неоптимально. Знаете, что на самом деле НЕ ОПТИМАЛЬНО? Не оптимально - не иметь возможности найти максимум ошибок в программе до того, как она зависнет, и завесит систему. Не оптимально - заставлять программеров искать баги, которые могли бы себя проявит сами, и сказать - "вот тут ошибка". Не оптимально - пытаться сделать не-дырявую ось на дырявом по определению железе (см. проект Singularity).

эта платная штука. И пробовал я ее. Ничего она не может. В этой ситуации - ничего. Не знаю, где там ей что сказать надо, чтобы она указала, откуда ноги выросли. Да, забыл сказать: задача многопоточная (> 5 потоков), и вообще непонятно, в каком потоке вылет.

Для того чтобы работали все проверки надо компилить с ее библиотекой (для MSVC) старые версии поддерживали и делфи, был BoundChecker Delphi edition. При этом ловсятся ошибки с точностью до заданого числа байт. Технология очень простая, перед вызовом функции массивы и стек заполняются патерном, потом этот патерн проверяется, если были переполнения - это тутже выявляется.

Проблема как всегда не в железе, а в криворуких програмерах, какое хорошее железо не делай и там найдутся те кто напишет программу, которая будет работать с глюками на самом отказоустойчивом железе. Раньше люди программирвоали на асме и выявляли все ошибки, а сейчас не могут выявить ошибки на ЯВУ (хотя это на порядок проще).

В большинстве своем наличие трудноотлаживаемых ошибок в программе, обуславливается стилем программирвоания. Есть у меня одна отечетсвенная книга (годов еще 60х), называется "Индивидуальная отладка программ", там про это очень хорошо написано. Книга актуальна и в наше время.

Более того DevPartner позволяет выявлять deatlock'и в многопоточных программах, и делает это достаточно эффективно.

Ну, бесплатный - только сыр в мышеловке. Делфи - тоже платный продукт. И любой софт для разработки под альтеру - тоже (и не малых денег стоит).

Проект на паскале, но какая разница. Метод паттернов не проходит. Проверялось и другими средствами, которые заполняют все паттерном. (Не пойму только, а при чем тут MSR'ы всякие? Какой с них толк - если это всего лишь средство получить информацию о возможностях аппаратуры). Там ошибка очень глубокая, наведенная. И наверняка даже не моя, а в одной из библиотек графики. Криворукие программисты, говорите? Вы попробуйте написать 100000 сток кода, и чтобы без ошибки, а я посмотрю. Хорошая ошибка - это которая сразу приводит к сбою. Но есть плохие ошибки. Функция отрабатывает нормально, ничего не происходит. На первый взгляд, и на второй и на десятый. Но где-то в памяти делает что-то не то. И спустя минуты долгого выполнения другая функция в другом месте начинает обращаться к данным, а они какие-то не те. Все случаи предусмотреть нельзя, и прога с грохотом падает. Попробуй теперь догадайся, которая из 10000 функций что-то не учитывает. Это не кривые руки программистов. Это ленивое железо + принцип "программисту доступно все". Я считаю, что сейчас на разработку ПО приходится вбухивать все больше средств и времени и сил - только потому, что слишком много экономии на разработке железа. "Мы не будем делать паровоз, вот вам 100 лошадей, скачите куда хотите". Так получается.

Читайте первоисточник (мануал по процессору от интела том 3 (с сайта интела)), а не русский перевод непонятно кого. В области регистров MSR есть область из 16-32х регистров, которые запоминают последние 16-32 перехода (все виды переходов call/jmp/int и т.д.), просто так этим воспользоваться не удастся, т.к. обработчик исключения Page Fault в первую очередь должен сохранить значения этих регистров (в противном случае в них запишутся переходы, которые происходят внутри обработчика).

Ну на счет 100000 строк кода я могу сказать только одно, что на компьютере код отлаживать намного легче, чем например во встроеной системе на TMS (у которого защиты памяти вообще нету) и кроме JTAG эмулятора нет никаких средств общени с внешним миром (ни монитора ни клавиатуры).

Я разрабатываю драйверы режима ядра (для систем на ядре NT) и исходников там порядка 1Мб, однако мне это не мешает находить и исправлять ошибки. Большинство ошибок можно исправить исходя из чисто теоретических принципов. Остальные с помощью контролирующего кода (assert'ов) и всяких там дебагеров и средств типа баундс чекера.

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

Ну и какой обычному разработчику (не уровня ядра) от этих регистров, если он может ими воспользоваться. Ошибки ошибками, но есть еще преднамеренный вредоносный код, от которого на x86 не убежать, не спрятаться. Стек программе доступен всегда как адресуемой пространство. В том же самом стеке лежат и адреса возвратов, и локальные переменные, и параметры. Метод паттернов здесь не поможет. Кроме естественных ошибок, появляется возможность найти редкий случай сочетания входных данных и переполнением буфера выполнить код, который никогда не должен был бы выполниться, в случае нормальном. Архитекутура, в которой стеки разделены, и не адресуются как обычная память, исключает такую возможность напрочь.

Ну, вообще метод патернов со стеком отлично помогает, делается проверка стека после каждого вызова функции, аналогично выявляются непроинициализированные переменные и налезание стека на код.
В новых x86 есть бит защиты страниц, который разрешает/запрещает выполнение кода с этой страницы, для стека стасятся атрибуты RW, для данных тоже RW, для кода RX, при этом запись в страницы с кодом тутже приводит к исключению, а также попытка выполнени данных и стека.
Кстати на x86 есть возможность защиты стэка, кода и данных, практически как в компьютерах с гарвардской архитектурой - это использование сегментной модели, когда у каждого сегмента задается его адрес и размер, тогда при переполнении стека вырабатывается исключение Stack Fault. Это никто не использует, потому что компилятор под сегментную модель писать в 100 раз сложнее, поэтому везде и используют упрощенную - FLAT модель. В своей тестовой многозадачной ОС, которую я писал на ассемблере я использовал защиту уровня сегментов и все 3 кольца защиты (как раз дл того чтобы посмотреть какие преимущества это дает), защищенность от ошибок повышается в разы, но компиляторов поддерживающих это нет, а из ОС только OS/2 поддерживала уровни привелегий 0, 2 и 3, все остальные ОС поддерживают только 0 и 3.

Так это не проблема железа, а проблема кривых инструментальных средств, которые не поддерживают аппаратуру на которой работают. Тотже отладчик SoftIce поддерживал MSR регистры, но только LastBranchFromIp и LastBranchToIp.

Всего стека? В каждом потоке? Ну вы меня умиляете. Я же говорю: до возникновения ошибки придется запускать прогу на несколько суток тогда.

Проверять после вызова придется всю память, принадлежащую задаче. Я о том и толдычу, что это нереалистично.

И потом, представьте себе идеальный мир. Прогу можно написать сразу так, что если в пределах защищенного блока произойдет ошибка, то прога не слоамется, а просто сообщеит, что данный участок данных сбойный, и пропустит его, и дальше пойдет. А может и не сообщать, просто в журнале фиксировать - если задача такая. А сейчас - будьте добры увидеть, что "программа выполнила недопустимую операцию", и полчаса ваших прежних ожиданий накрылись медным тазом. И будьте добры сами методом исключения (например) найти тот кусок данных, который роняет прогу, и удалить их из набора. Пример абстрактный, но характеризует нынешнее положение дел в полной мере. Разработчики даже не пытаются предусмотреть восстановление после сбоя, потому что сбой однозначно испортит общую кучу, доступную всей программе с едиными правами, и дальше пытаться выполнять что-либо просто бессмысленно: восстановление невозможно.

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

Ну вот, получил я Quartus II 6.1. Пока не понял, пойдет ли он с лицензией Web Edition, буду сейчас пробовать.

Ага, вроде идет. Expiration date: 27-Jun-2007. На полгода, то есть. Через полгода новую дадут, если от имени той же сетевой карты / пользователя просить, кто в курсе, скажите.

Пойду туториал "полистаю" ;)

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

Ну, далеко ходить не надо, ОС с ядром mach (микроядерная ОС, где все процессы и драйверы работают в юзермоде). Там все процессы могут быть восстановлены. Точно также большинство военных приложений, там практически всегда требуется прохождение программой контрольных точек и восстановление в случае сбоя с этих контрольных точек.

И еще, я например, выработал для себя правило - не использовать в своих проектах бблиотеки и компоненты (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 скачивать) и лекарство в личку скинуть.

Ну, трехадресность то тоже не у нас придумали (БЭСМ4 и НАИРИ - это просто отечественная реализация трехадресной машины), тот же MIX кнута - трехадресный.

Это есть у интела (http://www.intel.com/cd/software/pro...ipp/302910.htm) с оптимизацией под самые последние процы.

В этуж библиотеку входят и mpg-2, mpeg-4, H.263, H.264 кодеры/декодеры.

Скорее всего существует, но этот стандарт просто платный, или патентованый и распространяется под NDA.

Кстати тема то названа неверно - нет микросхемы cyclon 3, видимо имелось ввиду Stratix III (т.к. идет сравнение с Virtex 5, а это схемы одного уровня), а Cyclon соответсвует Spartan.

Есть, есть. Уже анонсировано, указано время выхода в продажу (какой-то квартал 7 года), , цены ориентировочные (только я не понял насчет этих цен: как хочешь считай то ло 2000 баксов за 1000 штук, то ли при партии от 1000 штук 2 бакса за штуку).

Я когда давал линк на альтеровском фтп, то указывал вот этот файл: 61_quartus_windows.exe его мне и качнули. Я так решил, что Web-edition назывется 61_quartus_free.exe , тоже не маленький, 400 метров. А что такое 61_quartus_programmer.exe (50 метров) я вообще не понял. Заставка была вроде бы та же, но я продолжать не стал установку.

По 2000$ за штуку при партиях от 1000 штук
поштчно может и все 3000$

Вот теперь окончательно понятно. Золотые прямо. Но я думаю, эти цены не навсегда. Вспомнить, сколько 1Гб флэшка стоила год назад (~1000 уе), и сколько сейчас стоит 4Гб (~100 уе). Наделают побольше, подешевеет поди. Я вообще целюсь влезть если не в циклон2, то хотя бы в стратикс. Они тоже дороговаты пока, правда. Но если ничего не делать, то и ничего не будет к тому моменту, как они подешевеют.

Так я вэб-эдишн качнул (в смысле не я а мне) или полную версию? Как узнать-то? :v2_crazy:

Такс, я щас качнул какой-то док по System Verilog, стандарта 2001 мне не хватат. Кто-нить по-быстрому может сказать, как вот такое в цикл `for впихнуть (если это вообще можно):

Мне так долгонько рисвать все эти вызовы модулей придется, если без `for, да и ошибок боюсь добавится.

Полный Quarus в наборе имеет
Quartus
ModeSim
IP Cores
NIOS
и вроде че то еще

И весит что то около 1Гб

WEB окло 300 мег и почти ничего нету, но клизма подходит что к полному что к урезаному варианту.

Ну SystemVerilog это чуть из другой песни

А так что то в таком духе

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

Во IEEE 1364

не, шлет подальше.
Error (10170): Verilog HDL syntax error at OperRegQueue_step1.v(25) near text "for"; expecting an identifier ("for" is a reserved keyword ), or "endmodule", or a parallel statement
Внутри always-блока прокатило (я уже раньше попробовал), но там же нет обращения к модулям, просто набор присваиваний.

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

Стандарта Verilog 2001 для циклов и условных конструкций достаточно, а вообще я бы советовал использовать VHDL (он похож на паскаль и ада, вам я думаю это привычнее будет) и поддерживает if/generate и for/generate с самой первой версии. Плюс к тому поддерживает типы данных, как обычный язык программирования, что позволяет при моделировании автомата видень состояние автомата в виде осмысленного текста (s_idle, s_rx и т.п.). Кроме того VHDL поддерживает 9ти значную логику, кроме состояний '0', '1' есть еще 'X', 'Z' и различные уровни нагрузки, от weak до strong (что необхдимо для выявления гонок при моделировании).

Верилог изначально предполагался совсем для других целей (это был внутренний язык для синтеза фирмы Cadence) и поддерживает всего 2 типа "провод" и "регистр", поэтому при симуляции видны только нули и единицы.