верификация дизайна не просто принята, а является неотъемлемой частью разработки
Да, но одно не отменяет другое. Плюс ко всему — статический анализ все-таки быстрее и позволяет на более ранней стадии выявлять ошибки, чем симуляция с тестовыми данными.
А еще можно в добавок сказать, что грамматики этих языков в разы проще чем С++. Тут и LR(1) парсер справится на ура. Так что можно всецело сконцентрироваться именно на анализе.
Здесь вы очень сильно ошибаетесь. Всё настолько плохо, что существуют компании вроде Verific, которые целиком делают бизнес на разработке, продаже и поддержке компиляторов для HDL.
Парсинг VHDL — это ад. Парсинг простого Verilog'а полегче, но вот SystemVerilog — это тоже ад.
Я был одним из разработчиков подобного статического анализатора (http://www.aldec.com/en/products/functional_verification/alint).
Инструментов такого рода хватает (лидер сейчас — Atrenta SpyGlass), но все они стоят немалых денег.
Могу сказать, что насчёт «типовые ошибки такие же, как в С», вы слегка заблуждаетесь. То есть да, какую-то часть можно так выловить, но для полноценного поиска ошибок необходима хотя бы частичная эмуляция RTL-синтеза — а здесь на одном только опыте написания статических анализаторов далеко не уедешь. Плюс ко всему — неплохо бы быть в теме проектирования ASIC/FPGA и уметь писать на SV и VHDL. Ну и last but not least — на авторов Windows-only инструмента в этой индустрии посмотрели бы, мягко говоря, странно:)
И еще: у нас был клиент — компания из Индии — которая купила базовую комплектацию (без большинства встроенных rule plugins) и написала свой плагин для правил, с блэкджеком и шлюхами навигатором по семантическому дереву и регулярками.
Так что иногда эта фича действительно востребована :)
Практика показывает, что клиенты всегда спрашивают API для написания правил, но очень редко его используют. Видимо, им на душе спокойнее, если им кажется, будто бы они способны написать плагин с правилами сами. Поэтому галочка «есть возможность реализации собственных правил» — это большой плюс для вас, даже если эта возможность будет ограниченной.
У нас, кстати, была проблема с предоставлением API: если встроенные rule plugins работали с объектно-ориентированной C++-моделью, то для пользовательских плагинов пришлось сделать громоздкий сишный интерфейс (из-за несовместимости ABI различных C++-компиляторов). Как я понимаю, вы же привязываетесь к конкретному компилятору, поэтому у вас таких проблем возникнуть вроде бы не должно.
P.S. Старайтесь поменьше употреблять фразу «клиенты задают глупый вопрос», даже если это и правда:).
>Во-первых, во всех компиляторах стандартный string и так заоптимизирован, замена передачи по значению на передачу по ссылке не даст вообще никакого роста производительности.
Во-первых, string — часть не компилятора, а стандартной библиотеки (которая вполне может быть сторонней — например, STLPort).
Во-вторых, я не слышал о том, чтобы Copy-On-Write действительно было реализовано в большинстве реализаций стандартной библиотеки, потому как реализация этого механизма с учетом многопоточности не так проста, как кажется, а в некоторых случаях эта оптимизация вылезает боком.
>передача параметров по ссылке требует наличия объекта. В частности, я не смогу передать в качестве аргумента выражение «a»+«b».
Передача по константной ссылке не требует наличия объекта.
А за попытку передачи временных объектов по неконстантой ссылке нужно бить молотком по пальцам.
Почему-то мне кажется, что если все-таки отказаться от использования MSVC для препроцессинга, то линтинг можно значительно ускорить, потому как сейчас довольно-таки много времени съедают на дисковые операции.
Таки да:)
Тем не менее, даже в контексте Конституции, "We the People of the United States" все же означает "Мы, народ Соединенных Штатов, ля-ля-ля... провозглашаем...", а не "Мы народ Соединенных Штатов". Ну это так, мелкая придирка к переводу, которая не меняет сути текста:)
>Наконец-то появилась столь нужная кнопка "Up", непонятно почему отсутствовавшая в предыдущих сборках.
Она была и раньше, только её не было по умолчанию на панели инструментов. Надо было сделать всего лишь пару кликов мышью:D
>Оконный менеджер Kwin обзовёлся полным набором эффектов и теперь ни в чем не уступает Compiz.
Кубика все же пока нет. Но на Планете KDE пробегала информация о том, что плагин с 3D-кубом уже в разработке.
>Непонятно, будет ли включён в релиз музыкальный плеер Amarok 2.
Точно не будет:)
>Напомню также, что KDE 4.1 будет доступна также Windows пользоватям.
Строго говоря, полноценного порта под Вин32 все-таки не будет. Пока что речь идет только о портировании библиотек и приложений. Также в сети пробегали скриншоты портированной плазмы, но, насколько я знаю, плазмоиды под Windows пока что работают весьма нестабильно.
Да, но одно не отменяет другое. Плюс ко всему — статический анализ все-таки быстрее и позволяет на более ранней стадии выявлять ошибки, чем симуляция с тестовыми данными.
Здесь вы очень сильно ошибаетесь. Всё настолько плохо, что существуют компании вроде Verific, которые целиком делают бизнес на разработке, продаже и поддержке компиляторов для HDL.
Парсинг VHDL — это ад. Парсинг простого Verilog'а полегче, но вот SystemVerilog — это тоже ад.
Инструментов такого рода хватает (лидер сейчас — Atrenta SpyGlass), но все они стоят немалых денег.
Могу сказать, что насчёт «типовые ошибки такие же, как в С», вы слегка заблуждаетесь. То есть да, какую-то часть можно так выловить, но для полноценного поиска ошибок необходима хотя бы частичная эмуляция RTL-синтеза — а здесь на одном только опыте написания статических анализаторов далеко не уедешь. Плюс ко всему — неплохо бы быть в теме проектирования ASIC/FPGA и уметь писать на SV и VHDL. Ну и last but not least — на авторов Windows-only инструмента в этой индустрии посмотрели бы, мягко говоря, странно:)
Нет, не знаешь.
блэкджеком и шлюхаминавигатором по семантическому дереву и регулярками.Так что иногда эта фича действительно востребована :)
Практика показывает, что клиенты всегда спрашивают API для написания правил, но очень редко его используют. Видимо, им на душе спокойнее, если им кажется, будто бы они способны написать плагин с правилами сами. Поэтому галочка «есть возможность реализации собственных правил» — это большой плюс для вас, даже если эта возможность будет ограниченной.
У нас, кстати, была проблема с предоставлением API: если встроенные rule plugins работали с объектно-ориентированной C++-моделью, то для пользовательских плагинов пришлось сделать громоздкий сишный интерфейс (из-за несовместимости ABI различных C++-компиляторов). Как я понимаю, вы же привязываетесь к конкретному компилятору, поэтому у вас таких проблем возникнуть вроде бы не должно.
P.S. Старайтесь поменьше употреблять фразу «клиенты задают глупый вопрос», даже если это и правда:).
Во-первых, string — часть не компилятора, а стандартной библиотеки (которая вполне может быть сторонней — например, STLPort).
Во-вторых, я не слышал о том, чтобы Copy-On-Write действительно было реализовано в большинстве реализаций стандартной библиотеки, потому как реализация этого механизма с учетом многопоточности не так проста, как кажется, а в некоторых случаях эта оптимизация вылезает боком.
>передача параметров по ссылке требует наличия объекта. В частности, я не смогу передать в качестве аргумента выражение «a»+«b».
Передача по константной ссылке не требует наличия объекта.
А за попытку передачи временных объектов по неконстантой ссылке нужно бить молотком по пальцам.
да неужели?:)
Тем не менее, даже в контексте Конституции, "We the People of the United States" все же означает "Мы, народ Соединенных Штатов, ля-ля-ля... провозглашаем...", а не "Мы народ Соединенных Штатов". Ну это так, мелкая придирка к переводу, которая не меняет сути текста:)
Она была и раньше, только её не было по умолчанию на панели инструментов. Надо было сделать всего лишь пару кликов мышью:D
>Оконный менеджер Kwin обзовёлся полным набором эффектов и теперь ни в чем не уступает Compiz.
Кубика все же пока нет. Но на Планете KDE пробегала информация о том, что плагин с 3D-кубом уже в разработке.
>Непонятно, будет ли включён в релиз музыкальный плеер Amarok 2.
Точно не будет:)
>Напомню также, что KDE 4.1 будет доступна также Windows пользоватям.
Строго говоря, полноценного порта под Вин32 все-таки не будет. Пока что речь идет только о портировании библиотек и приложений. Также в сети пробегали скриншоты портированной плазмы, но, насколько я знаю, плазмоиды под Windows пока что работают весьма нестабильно.