Беседа с профессиональным программистом В. Коджесяном
о низкоуровневом программировании,
процессорах и компиляторах

Гигантский каталог программного обеспечения на www.yellow-gold-soft.com

Гигантский каталог программного обеспечения на этом сайте

Вместо предисловия

Я: Во всяком случае я ни в форумах, нигде в иных местах не могу найти что-либо подобное. Если ты не будешь возражать, я опубликую...

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

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

Да правда. Практически все операции необходимые для низкоуровневой работы можно выполнить на Си. Исключением останется пожалуй только управляемое размещение кода в памяти. Т.е. ты иногда не сможешь указать что данный код должен лежать конкретно по адресу 137000. Всё остальное допустимо. В основном работа с железом сводится к работе с периферией. Т.е. в некий заранее выделенный адрес нужно положить какое нибудь число. Это будет означать, что на дисплее в таком-то пикселе загорится красный цвет. Такой доступ нужен для написания драйверов. И в основном востребовано только у производителей железа. Кто делает железо, тот драйвер и пишет обычно. В крайнем случае в Си есть команда #asm кажется. Она означает начало блока на ассемблере. Просто ту часть кода где тебе нужно писать на ассеблере - и пиши на ассемблере. Компилятор С это поймет. Я с этим баловался этак в 1996 году. С тех пор и не пробовал. Наверное в VC6.0 все еще поддерживается этот оператор. Язык Си фактически высокоуровневый ассемблер. Т.е. это означает, что наряду с "высокими материями" вроде классов и наследования, можно мыслить и байтами операндами, и однобайтными командами врод name++. Компилятор Си настолько умный, что всю рутину будет делать за тебя. И главное будет делать это лучше тебя. В современных компиляторах есть и ключи оптимизации, так что даже код оптимальнее компилятора ты не напишешь. Кроме того, если хочешь С выдаст промежуточный код в виде ассемблера. У комитятора есть какой-то ключ для этого. Бери этот код за основу и правь те места, которые ты считаешь, что можешь написать лучше чем Си-компилятор. Уверяю тебя - таких мест ты не найдешь. Только ошибок налепишь, и отлаживать будешь год.

Правда ли то, что Windows вообще максимально пытается ограждать программиста от непосредственной работы с железом, намекая на то, что Микрософт лучше знает, что программисту надо?

Правда, и за этим всем стоит глубокая философия технологий. По мере усложнения задач, люди поделились на тех, кто лучше всех програмирует железо и тех, кто лучше всех пишет приклад. Микрософт - это, "основа жизни", операционки и взаимодействие с железом - это их хлеб. Для эффективного разделения труда - не надо лезть к ним, а они не будут лезть к тебе. И это разделение не имеет конфликта интересов. Просто так удобнее. Микрософт специально старается делать так чтобы прикладнику жилось как можно лучше. Не надо им в этом перечить. Все мы работаем на одну идею.

Правда ли то, что работая для виндоус программист обречён в основном использовать тысячи и тысячи функций win API, что с другой стороны избавляет человека от множества рутинных операций?

Правда, и чем больше ты знаешь этого прикладного API, тем ценнее и опытнее ты как специалист. Изучить синтаксис языка - это примерно 3%. А 97% опыта програмиста как раз и составляет знание разных API. Собственно к глубокому знанию API и нужно стремиться. Это самый эффективный путь к совершенству. Из языка достаточно знать базовые конструкции, и не тратить время на прочую мелочь. Еще полезно знать общие подходы в програмировании. Ну например какими способами обычно передаются данные между источником и приемником. Пул, пуш, синхронно, асинхронно и др. Еще полезно знать базовые технологии, вроде 3Dграфика, Web область, COM, DCOM, сервлеты и др. Но опыт в применении конкретного API по сравнению со всем другим это приоритет примрно 1:10. Лучше знать маленький HTML, но в совершенстве, чем форсить переченем библиотек 3D графики без реального опыта рисования на экране простого шара. В Win API сложно понять как работает Windows приложение. Что такое многооконный однооконный диалоговый документ. Что такое "document-view" архитектура. Второе по сложности, но не по важности - это СОМ технология. Дальше пошли всякие конкретности вроде сетевого API, звукового API...

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

Наверное есть и такие подходы - я назвал бы их фундаментальными. Я не согласен. Вместе с древностью DOS-а ученик притащит и всякие древние вопросы которые и не актуальны и вредны для изучения. Может быть это полезно для историков изучающих как развивалась компьютереная мысль в пространстве-времени... Так уж важно хирургу 20 века владеть деревянным молотком, если у него есть соверменные препараты для анестезии? Мне гораздо больше нравится подход "сверху вниз". Вот мой пацан еще знать не знал, что в компе есть процессор, а запускать игрушку уже умел. Потом и инсталять ее сам научился. Теперь операционки запросто настраивает. И уже языки некоторые освоил. Зачем ему DOS и ассемблер "Радио-80" и "Спектрум", если он на PHP уже живые бабки заколачивает. Нифига себе! Я в 18 лет еще на содержании у родителей сидел. А он в прибавок имеет 1гб заработанного трафика в интернет. И скорость у него почище моего DSL. Вчерась со мной по аске болтал. А ведь начинал он с игрушек. Т.е. с насущной востребованности. Была задачка, написать модель солнечной системы. Я ему сделал заготовку в С++ и привел пару методов библиотеки. Стирание/рисование круга и точки. Это как бы не входило в задачу у них. Т.е. подразумевалось что препад даст заготовку или кто нибудь другой. А вот все остальное он сам лепил. Т.е. собсвенно алгоритм кеплеровского движения и др. алгоритмику он сдал. А заодно и пощупал современный инструмент VC6.0. Если когда и начнет сложные задачи делать сразу начнет с этих двух функций графического API. А так бы только время на поиск и установку этого самого ДОСа.. В общем старье...

И ещё вопрос про процессоры. Я читал и ты писал как-то про то, что современные процессоры умны настолько, что используют свои свободные микро- и наносекунды на то, чтобы подготовиться к возможным дальнейшим приказам от программы, забегая вперёд и даже фантазируя в своих прогнозах. Так вот, насколько программист сегодня имеет доступ к таким умным операциям в процессоре? Вообще насколько сегодня глубоко разработчики процессоров пускают программистов влиять на работу процессора?

Ну я знаю это только поверхностно. Кажется такая технология называется предсказыванием. По-моему программистов влиять на скрытые дела процессора никак не пускают. Тут опять же философия разделения труда. Каждый делает свое дело. Програмисты кодируют алгоритм прикладной задачи, компилятор транслирует это в процессорный код. А разработчики процессоров стремятся поднять скорость исполнения этого кода. Конечно все друг с другом сотрудничают. Но в большинстве задач друг другу не мешают. Разработчики архитектуры процессора, меряют статистические распределения очередности операций в типовом коде комилятора. И на основе статистики оптимизируют железо так, чтобы оно предугадывало следующую операцию и выполняло ее в параллель. Собственно это и позволяет гонять по лабиринтам виртуальных зверюг очень быстро. Возможно, есть компиляторы которые могут учитывать особенности архитектуры процессора. Интел там или АМД. Очень специфическая область знания. Простым смертным вроде нас с тобой - не очень важна. Еще есть распараллеливание операций на много процессоров. Та же Windows поддерживает многопроцессорность. Это дело уже востребовано в некоторых серьезных задачах. Вроде компьютерной системы головного офиса крупного банка. Можешь поинтересоваться.

Я предполагаю, что сейчас они пускают чужих в процессор намного более поверхностно, чем во времена 286 машин.

Да, и именно в силу выгоды разделения труда. Пока ты будешь оптимизировать 286 код под Пентиум и отлавливать свои ошибки, твой заказчик купит Итаниум и софт твоего конкурента. Который давно обошел тебя в прикладной функциональности, хотя его код на порядок отстает по эффективности исполнения от твоего. Только заказчик этого не знает. Он просто купил Итаниум и забыл все проблемы. Итаниум в основном занят тем что рисует красивые трехмерные музыкальные кнопочки, за эти кнопочки собсвенно заказчик и купил софт твоего конкурента. Ты конечно был прав и правоту свою можешь доказывать в ... голодном поле, среди бомжей ;(

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

Умер, умер, и даже отпели уже. Для нас с тобой во всяком случае. Драйвера для Windows пишутся с помощью DDK(Driver Developer Kit) который ловко интегрируется с VC6.0 и Си++. Осталась маленькая область для развлечений. Это прикладные разработки на спец. процессорах, вроде Zilog... Полный тупик...

Насколько Микрософт влияет на разработку процессоров под свои Windows? У меня есть предположение, что прогресс движется к тому, чтобы в будущем программисты вообще имели только высокоуровневый доступ к процессорам и чтобы даже сама система команд такого процессора стала более высокоуровневой.

Думаю что поизводители железа конечно взаимодействуют с разработчиками операционок. У них там всякие соглашения. Маловероятно что нас простых смертных это сильно касается. Это примерно так: - Нефть дорожает, а мы с тобой как покупали бензин так и будем покупать. Конечно можно поворчать на рост цен, но не повлиять на них. Примерно также производители железа и микрософт определяют софтверный рынок, задают на нем тон.

Ведь теоретически можно сделать процессор настолько умным, чтобы он на ходу интерпретировал Си++ код на уровне железа?

Задача програмирвания - это отразить реальные связи объектов в мире в компьютерной модели. Сделать это пока что может только человек. Некоторая тенденция к дальшейшему удалению от ассемблера наблюдается. Но решается она в основном на програмном уровне. Появились всякие виртуальные оболочки вроде java. Но вот построить железо на более высокоуровневый код, как то не получается. Под ту же Java сколько хотели делать железный процессор, Sun даже сделал, но не прижилось...
Есть и обратная тенденция. Наоборот, железо исполняет все меньше и меньше аппаратных инструкций, скажем всего четыре!. А все остальные эмулируются програмно. т.е. некий, еще один микропрограмный слой внутри процессора - фактически жестко зашитая программа которая выполняет операции ассемблерного языка x86. Такие технологии назывались кажется RISC. Преимущество - дешевые процессоры. Но PC-подобные процессоры по моему отошли от этого направления. Подробности не знаю.

Вообще насколько я правильно предполагаю?...

Мне кажется у тебя здоровое любопытство, но оно мало связано с реальными потребностями. Перефразируя на музыкальную область, это примерно - какие направления в разработке гитарных грифов? Интересно конечно, полезно, точнее не вредно знать какой гитарный лак технологичнее и долговечнее, но очень далеко это лежит от практической твоей работы в ресторане. Примерно так же технологии процессоров отстоят от того на чем можно заработать деньги в програмировании. Т.е. не вредно, но и пользы мало. Мне кажется в любом случае лучше ориентироваться в более практических областях. Когда станешь мастером в чем-то, эта область будет так же интересна как и архитектура процессоров, но при этом еще и практическая польза будет по жизни. С другой стороны это ограничит кругозор и потенциально новые области интереса, с непрогнозируемыми результатами.

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

А кстати учи английский! Хотя бы в пределах чтения тех. документации. Все новое в IT все-таки на английском идет.

На главную страницу сайта
На главную страницу раздела