`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрей Зубинский

Опять о языках, точнее, - об одном языке

+99
голосов
Ещё точнее, - о несуществующем языке.
 
Я люблю C. Потому что это действительно хороший язык (хоть и ужасный, конечно). И очень много кто ещё любит C – иначе бы сегодня не было столько разных производителей С-компиляторов для столь разных платформ (от 8-битовых контроллеров до 256-битовых спецвычислителей). C пережил многие языки, которые некогда считались панацеей от всех болячек. C пережил легенду под названием Ada – уже и программное обеспечение пассажирских самолётов (можете представить себе степень надёжности, требуемую в этой области) мирового класса пишут на C, вот свидетельство:
C пережил Lisp, Prolog и Smalltalk – сейчас эти языки существуют, но ничего значимого на них давно уже не пишется (в сравнении с пишущимся на C).
Итак, C прожил долго, счастливо, и будет жить ещё долго. Потому что он нужен, платформенно-независимый высокоуровневый ассемблер, он очень нужен. Но если смотреть на С именно как на ассемблер обобщённой вычислительной машины традиционной архитектуры, есть некоторые претензии.
Мне лично бы хотелось, чтобы в высокоуровневом ассемблере были как минимум две конструкции, отсутствующие в C: суффикс, ключевое слово at и суффикс, ключевое слово when.
at позволяет указать физический адрес размещения объекта в памяти, например:
volatile unsigned int PORT_A at 0x0002 ;
что значит – слово (размер – unsigned int для целевой платформы), расположенное по адресу 0x0002,  является отображённым на память регистром порта ввода-вывода A. Подобных регистров в самых разных архитектурах необъятное количество.
Ключевое слово when, по сути, являющееся модификацией at и относящееся исключительно к функциям. Оно позволяет задавать обработчики прерываний без обращения к ассемблерному коду:
void Signal_From_Gyro( void ) when INT_11 ;

То есть, - это указание компилятору и редактору связей, что функция Signal_From_Gyro() является обработчиком прерывания INT_11 (на деле это должна быть предопределённая константа), соответственно, - для этой функции должен быть сгенерирован специфический код и указатель на функцию должен быть помещён в ячейку памяти, где «сидит» адрес обработчика прерывания INT_11.

В принципе, можно обойтись и без when, только c at, но в таком случае программист будет вынужден городить ещё больше низкоуровневого машинно-зависимого кода в тех случаях, когда с этой задачей прекрасно может справиться генератор кода компилятора.

Ещё хотелось бы, чтобы серьёзно «прошерстили» последний стандарт языка, выловили все оставленные на откуп разработчикам конкретных реализаций компиляторов неоднозначности (ведь многие из них тянутся со времен Кернигана и Ричи), и постарались от них избавиться. Причем так, чтобы грамотный прежде написанный код всегда работал. Во многих случаях это возможно.

Например, жёсткое правило, что при операциях присваивания (lvalue = rvalue) сначала генерируется (и исполняется) код вычисления rvalue, затем – код вычисления lvalue, и только после этого выполняется собственно присваивание, устраняет много мелких семантических пакостей (и никак не влияет ни на эффективность генерируемого кода, ни на исполнимость написанного ранее – потому что из-за неоднозначности в нынешнем стандарте языка такой код «с нюансами» заслуженно считается неправильным).

Вообще, неплохо было бы создать гибрид семантики современного алголоподобного языка (Modula-2 или Oberon-1), самой приятной части C-синтаксиса и, непременно, - адресной арифметики, - получилось бы очень «вкусно».
По-моему, Никлас Вирт мог бы создать язык действительно взрывной популярности, если бы пошёл по этому пути. Кстати, -  совершенно необязательно делать такой язык объектно-ориентированным, хоть бы и в минимальной степени (как Oberon-2). Причина одна – для объектно-ориентированных языков крайне трудно создавать верификаторы.
Ну а насчёт функциональных языков… Системы управления реального времени, где сейчас царит C – область volatile-переменных и обработчиков прерываний. Чистым функциональным языкам эти понятия – как серпом по… А сложные абстрактные построения, которые призваны устранить это отчуждение изящной чистой математики от безобразной реальности, сами по себе настолько безобразно уродливы (как те же монады), что уж лучше возиться с императивным ассемблером. Было бы иначе – разработчики ПО Airbus предпочли бы функциональный стиль - уж они-то своё дело знают, будьте уверены.
+99
голосов

Напечатать Отправить другу

Читайте также

Вопрос: зачем уродовать язык вещами зависящими от платформы?

Да, задавать прерывания во всех компиляторах для встраиваемых систем нужно по разному. Но платформа от платформы отличается так радикально что код в любом случае не переносим без портирования или условной компиляции.
Например обработчик прерывания на PIC18 отличается от dsPIC как небо и земля, а это один производитель микроконтроллеров.

А по поводу портов даже не знаю что и сказать...
Тут также у каждой платформы свои особенности, и судя по моему опыту всё сводится к заголовочным файлам для конкретного процессора и обычно эту работу проделывает производитель железа.

IMHO

язык уродоваться не будет, если его не уродовать )

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

для PIC-18 в компиляторах HT-PIC предумотрен для описания обработчиков прерываний спецификатор interrupt, dsPIC я не ковырял, но и для него, по идее пары (dsPIC, модель, номер_прерывания) должно быть достаточно для спецификации нюансов.

для 51-го семейства в компиляторе SDCC есть почти точный аналог at - директива __at c тем же смыслом, её используют для доступа к регистрам спец. назначения (SFR). точно так же здесь есть директива __interrupt(номер_прерывания).

в Keil для 8051-х - в принципе, то же самое.

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

кстати, можно было бы (да и нужно) эти расширения для самых разных платформ обработать, обобщить и найти тот минимум, который наверняка было бы целесообразно внести в язык.

впрочем, претензии понятны.

обе вещи ведь относятся больше к редактору связей, чем к "транслятору" - в этом основная проблема, видная и мне.

Например, жёсткое правило, что при операциях присваивания (lvalue = rvalue) сначала генерируется (и исполняется) код вычисления rvalue, затем – код вычисления lvalue, и только после этого выполняется собственно присваивание, устраняет много мелких семантических пакостей (и никак не влияет ни на эффективность генерируемого кода, ни на исполнимость написанного ранее – потому что из-за неоднозначности в нынешнем стандарте языка такой код «с нюансами» заслуженно считается неправильным).

А что же происходит в С в данный момент?

С очень хорош, т.к. он даёт практически полную свободу действий программисту, даёт полный контроль над работой ПК, в то время как другие языки пытаются "облегчить" жизнь программисту беря что-то на себя. Например, Garbage Collection, которого в С нет и никогда не будет. Просто потому, что в С его нельзя нормально реализовать. Тем неменее, настолько низкий уровень работы с компьютером и практически полная свобода действий делают С почти что идеальным языком для создания компиляторов, ассемблеров и парсеров разного направления.

А функциональные языки, например, Lua, который построен на базе того же С, отлично подходят для прототипов. Иногда просто хочется попробовать алгоритм, посмотреть как он будет работать без каких-либо оптимизаций, не зацикливаясь на деталях. Программа в 40 строк в С может быть написана в Haskell где-то в 10-15 строк. И если алгоритм работает так, как вам нравится, никто не мешает его перенести на С и оптимизировать его под определённую платформу.

К сожалению, по поводу at/when сказать ничего не могу. Не хватает опыта оценить полезность таких нововведений. -)

Андрей, не могли бы вы посоветовать действительно стоящие книги по этому языку?

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT