|
|
Скажу, что мне очень сильно не нравится в C++ шаблонах на уровне идей. Полное отсутствие контроля типов. В итоге чтобы понять, какие требования предъявляются к параметрам, например, шаблона класса, нужно перепахать все методы этого класса.
У нас, действительно, несколько разное представление о том, что значит "хороший" язык программирования. Я полностью согласен с Вашим утверждением о том, что если язык позволяет программисту писать так, как программист хочет - это хорошо. До тех пор, пока программист пишет лично для себя свой хобби-проект. Как человек, который в последнее время читает гораздо больше чужого кода, чем пишет своего, могу Вас заверить, что когда начинаешь читать много чужого кода, представления о том, что такое "хорошо" и что такое "плохо" в программировании сильно изменяются. Так как, оказывается, что существует довольно мало опытных осторожных программистов. Для меня хороший язык программирования - это тот язык, который не позволяет программисту делать опасные вещи _просто_. Плюсы этому критерию совершенно не удовлетворяют. Идеология Ада или C# гораздо правильнее - когда существует безопасное подмножество языка, на котором пишется большая часть программы, а для небольшой части кода можно использовать опасные конструкции, но их использование сопряжено с разумными сложностями.
Проблема остановки - это такая теорема в computer science. В двух словах, нельзя написать такую универсальную программу, которая для поданного на её вход описания другой программы и по её входным данным за конечное время напечатает в выходной поток ДА если тестируемая программа на этих входных данных когда-либо остановится, и НЕТ, если она не остановится никогда.
Исходя из этого не стоит смешивать формальную семантику программы и те идеи, которые существовали в голове у программиста при её написании. Для компьютера "смысл" программы - это её формальная семантика, не больше. Весь дополнительный смысл для человека описывается в комментариях неформально и компьютеру недоступен. Для С++ формальная семантика любой корректной программы определена совершенно четко в терминах изменения состояния виртуальной машины. Причем, согласно тезису Чёрча об эквивалентности моделей вычислений, эту виртуальнуя машину можно смоделировать на любом вычислительном устройстве за полиноминальное время. В большинстве реальных архитектур, для программирования которых используется С++, за константное. Плюс широкий класс оптимизационных преобразований, сохраняющий выход программы неизменным. Это позволяет на плюсах писать корректные эффективные программы.
Далее, я буду настаивать на том, что для любого транслятора "понимать программу" означает способность породить для данной исходной программы выходную программу, выход которой неотличим от выхода исходной программы (при исполнении программ в рамках соответсвующих моделей вычислений, разумеется). Т. е. этот термин не сводится только к успешности грамматического разбора. Если для некоторого класса корректных исходных программ транслятор пишет "свойство языка не поддержанно" - он эту программу не понимает.
Когда дело начинает касаться трансляции С++ программы в железо, есть, конечно, прямой путь - породить в железе компьютер, который будет исполнять эту С++ программу. Только вряд-ли кого-то этот путь устроит в случае SystemC. Другой путь, как я писал ранее - программист должен описать структуру системы, пользуясь средствами, выходящими за С++ (пользуясь соглашениями об использовании макросов или классов), и только для описания последовательных внутренностей процессов можно применять собственно С++ с его последовательной семантикой.
Описание SystemC (стандарта ведь не существует?) с требованием использовать те или иные грамматические конструкции как раз и является таким дополнительным семантическим уровнем. То, что Вы раскопали внутренности реализации инструментария SystemC, вообще не имеет никакого отношения к этой семантике. Раз сказано, что при описании процесса нужно использовать конкретный макрос - значит, нужно использовать конкретный макрос, и никак иначе. И еще, минимально достаточное описание этого инструмента (раз это не язык - назовем его инструментом) должно однозначно указывать, что такое "точно такая же система в железе". Без этого нудного и всеобъемлющего описания это все приманка для неосторожных новичков.
Кроме того, необходимо накладывать жесткие ограничения на используемые конструкции С++. То, что Вы пишете про указатели - это очевидно, но, в то же время, крайне сложно формально описать, что с указателями можно делать, а что нельзя, чтобы синтезатор смог их синтезировать с разумной эффективностью. Отмечу, что и для обычных языков программирования арифметика указателей - это зло, так как существуют эффективные алгоритмы оптимизации, которые ею практически убиваются. Оптимизатор посто не может вычислить, на какие переменные в программе указатель _может_ ссылаться, и, соответсвенно, присваивание разыменованному значению такого указателя становится барьером, через который запрещено распространять информацию о выражениях в программе, совершенно не связанных (с точки зрения программиста) с этим указателем. Для обычной программы это только уменьшает эффективность трансляции, для железного синтеза это зло - смертельно.
В общем, повторю еще раз, все сводится к описанию структуры системы на верхнем уровне и некоторого количества последовательных конструкций на нижнем. Первое на плюсах делать сложнее, для второго плюсы - слишком сильный инструмент.
И я не согласен с Вашим утверждением о том, что какие системы моделировать на Верилоге - это вопрос вторичный. Существует множество языков моделирования систем, но только некотороые из них имеют синтезируемые в железо подмножества. "Verilog HDL is a formal notation intended for use in all phases of the creation of electronic systems." - IEEE Std 1364-2001.
E-mail: 
info@telesys.ru
