Предыдущая версия справа и слеваПредыдущая версия | Следующая версияСледующая версия справа и слева |
igor:istoria [2019/04/29 23:42] – [Специализированные и проблемно-ориентированные компьютеры] igor | igor:istoria [2019/04/29 23:51] – [Программирование в средние века] igor |
---|
Про язык Си часто говорят, что он дает очень быстрый машинный код, значительно более быстрый, чем дают другие языки. Что мы вкладываем в слово "значительно"? На 10%? На 20? Никаких исследований на эту тему никто не поводил. Это миф, который рассказывают и слушают люди, не готовые разобраться в подлинных причинно-следственных связях между явлениями. Язык Си принципиально ничем не отличается от Паскаля и более того - от Алгола. Более быстрый код дает не язык как таковой, а компилятор. Почему? - Элементарно: компилятор Алгола в 50-е годы создавали с нуля, с чистого листа, а компилятор языка С в 70-е годы разрабатывался с опорой на 15-летний опыт эксплуатации Алгола и ПЛ-1 (да и Фортрана тоже). А раз так, то было бы вполне логично ожидать, что он будет на четверть или даже на треть быстрее. \\ | Про язык Си часто говорят, что он дает очень быстрый машинный код, значительно более быстрый, чем дают другие языки. Что мы вкладываем в слово "значительно"? На 10%? На 20? Никаких исследований на эту тему никто не поводил. Это миф, который рассказывают и слушают люди, не готовые разобраться в подлинных причинно-следственных связях между явлениями. Язык Си принципиально ничем не отличается от Паскаля и более того - от Алгола. Более быстрый код дает не язык как таковой, а компилятор. Почему? - Элементарно: компилятор Алгола в 50-е годы создавали с нуля, с чистого листа, а компилятор языка С в 70-е годы разрабатывался с опорой на 15-летний опыт эксплуатации Алгола и ПЛ-1 (да и Фортрана тоже). А раз так, то было бы вполне логично ожидать, что он будет на четверть или даже на треть быстрее. \\ |
Еще один миф: язык Си якобы приближен к архитектуре компьютера. КАКОГО компьютера? Разных архитектур очень много - к какой из них этот язык ближе всего? И вопрос номер следующий: если Си - язык высокого уровня, то правильно ли __в принципе__ приближать его к архитектуре какого-либо компьютера? По идее, такой язык должен быть абстракцией, которая к разным компьютерам подходила бы в равной степени. \\ | Еще один миф: язык Си якобы приближен к архитектуре компьютера. КАКОГО компьютера? Разных архитектур очень много - к какой из них этот язык ближе всего? И вопрос номер следующий: если Си - язык высокого уровня, то правильно ли __в принципе__ приближать его к архитектуре какого-либо компьютера? По идее, такой язык должен быть абстракцией, которая к разным компьютерам подходила бы в равной степени. \\ |
| === Статическая и оверлейная линковка === |
| Выше мы рассмотрели линковщик как новую (в сравнении с древней эпохой) служебную программу, собирающую загрузочный файл из множества объектных файлов, выданных компилятором. В простейшем случае линковщик помещает в загрузочный файл основную программу со всеми нужными подпрограммами - это //статическая линковка//. В средние века наряду со статической была уже освоена //оверлейная линковка//: весь программный код делился на сравнительно небольшой основной загрузочный модуль и несколько оверлейных модулей. При запуске программы на выполнение основной загрузочный модуль загружался в оперативную память, и ему сразу передавалось управление, а оверлейные модули подгружались только тогда, когда нужно было выполнить содержащиеся в них подпрограммы. Разумеется, вопрос о том, какие части программы включить в основной загрузочный модуль и какие в оверлеи, мог решить только программист: "программист решил - линковщик сделал". Оверлейная линковка позволяла (1) уменьшить затраты времени на загрузку программы в оперативную память и (2) эксплуатировать большую и сложную программу на машине с ограниченной емкостью памяти (пусть хотя бы ценой некоторой "задумчивости" при выполнении некоторых операций), но не спасала от того, что разные программы на половину или больше состоят из одних и тех же деталей: каждый оверлейный модуль принадлежал какой-то одной программе. Отсюда вытекает очевидная идея "обобществить" оверлейные модули, но эта идея - более поздняя. Мы ее коснемся в главе "новое время". \\ |
=== Компиляторы и интерпретаторы === | === Компиляторы и интерпретаторы === |
Мы рассмотрели компиляционную технологию программирования как наследие древнекомпьютерной цивилизации, дожившее с некоторыми изменениями до нашего времени. В 60-е-70-е годы XX века имело место разделение некогда единой технологии программирования на два "рукава": компиляционный и интерпретационный. В 1964 г. был придуман **Бэйсик**, и так вышло, что именно он, а не Паскаль и не Си, стал королем средневековых языков. \\ | Мы рассмотрели компиляционную технологию программирования как наследие древнекомпьютерной цивилизации, дожившее с некоторыми изменениями до нашего времени. В 60-е-70-е годы XX века имело место разделение некогда единой технологии программирования на два "рукава": компиляционный и интерпретационный. В 1964 г. был придуман **Бэйсик**, и так вышло, что именно он, а не Паскаль и не Си, стал королем средневековых языков. \\ |
Чем жертвовали создатели Бэйсика и ради чего? Боевыми возможностями языка? Но поскольку язык для начального обучения, то это не считается. То, что язык получился кривой и некрасивый, - это хуже, потому что отрицательно влияет на интеллектуальное становление будущих специалистов. Зато получили первый в истории диалоговый язык, и он же был первым широко распространенным **//интерпретационным//** языком. Компиляторы Фортрана, Алгола и других языков преобразовывали исходный текст программы в машинный код, который затем запускался на выполнение. Бэйсик работает иначе. Интерпретатор просматривает исходный текст строка за строкой и сам выполняет описанные в строке действия. Поскольку каждую строку приходится обрабатывать отдельно, выполнение всей программы происходит намного медленнее, чем выполнение машинного кода, зато отпадает необходимость в компиляции как отдельном этапе работы. Что лучше? Если бы что-то было лучше, все поступали бы только так. Большая и сложная программа, особенно если она обрабатывает большие массивы данных, гораздо эффективнее выполняется с участием компилятора. Но в ряде случаев, особенно при выполнении учебных заданий, выполнение программы "на лету", без компиляции, может быть даже быстрее. И еще одно преимущество интерпретатора: поскольку он не вырабатывает никакого машинного кода, а выполняет все действия сам, неправильно написанная прикладная программа ничего не может испортить. Впрочем, в те годы это преимущество никому не казалось существенным. \\ | Чем жертвовали создатели Бэйсика и ради чего? Боевыми возможностями языка? Но поскольку язык для начального обучения, то это не считается. То, что язык получился кривой и некрасивый, - это хуже, потому что отрицательно влияет на интеллектуальное становление будущих специалистов. Зато получили первый в истории диалоговый язык, и он же был первым широко распространенным **//интерпретационным//** языком. Компиляторы Фортрана, Алгола и других языков преобразовывали исходный текст программы в машинный код, который затем запускался на выполнение. Бэйсик работает иначе. Интерпретатор просматривает исходный текст строка за строкой и сам выполняет описанные в строке действия. Поскольку каждую строку приходится обрабатывать отдельно, выполнение всей программы происходит намного медленнее, чем выполнение машинного кода, зато отпадает необходимость в компиляции как отдельном этапе работы. Что лучше? Если бы что-то было лучше, все поступали бы только так. Большая и сложная программа, особенно если она обрабатывает большие массивы данных, гораздо эффективнее выполняется с участием компилятора. Но в ряде случаев, особенно при выполнении учебных заданий, выполнение программы "на лету", без компиляции, может быть даже быстрее. И еще одно преимущество интерпретатора: поскольку он не вырабатывает никакого машинного кода, а выполняет все действия сам, неправильно написанная прикладная программа ничего не может испортить. Впрочем, в те годы это преимущество никому не казалось существенным. \\ |
Поскольку интерпретатор не порождает машинного кода, автор программы, написанной на Бэйсике, может передавать ее другим лицам ТОЛЬКО в виде исходного кода. Это с какой-то стороны хорошо, а с какой-то плохо (это кому как!) - ну не бывает на свете идеальных инженерных решений. Безусловно хорошо то, что такая программа может быть запущена на любом компьютере, на котором имеется соответствующий интерпретатор. В какой-то мере интерпретатор Бэйсика (и любого другого языка из тех, что появились позже) может рассматриваться как виртуальная машина - доступная владельцу мелкого компьютера альтернатива СВМ больших мейнфреймов. В предыдущей главе мы отметили, что разработчики __древних__ компьютеров первым делом оснащали свои детища компилятором Фортрана - точно так же в __средние века__ разработчики 16-разрядных мини-ЭВМ (PDP-11, они же СМ-3, СМ-4) оснащали свои операционные системы интерпретатором Бэйсика, хотя для таких машин он уже должен был считаться устаревшим. А разработчики восьмиразрядных домашне-игровых компьютеров своей жизни без Бэйсика не мыслили, потому что написать для такой слабой машины мало-мальски приличный компилятор было весьма непростой задачей, стоимость которой свела бы к нулю всю привлекательность таких машинок. А на советских ПК обычно вообще никакого другого программного обеспечения не было. Более серьезные программисты не жаловали Бэйсик, считали его //суррогатной технологией//. Однако в средние века проблема суррогатных технологий не ощущалась так остро, поэтому к ней я надеюсь вернуться, когда наша история дойдет до нового времени. \\ | Поскольку интерпретатор не порождает машинного кода, автор программы, написанной на Бэйсике, может передавать ее другим лицам ТОЛЬКО в виде исходного кода. Это с какой-то стороны хорошо, а с какой-то плохо (это кому как!) - ну не бывает на свете идеальных инженерных решений. Безусловно хорошо то, что такая программа может быть запущена на любом компьютере, на котором имеется соответствующий интерпретатор. В какой-то мере интерпретатор Бэйсика (и любого другого языка из тех, что появились позже) может рассматриваться как виртуальная машина - доступная владельцу мелкого компьютера альтернатива СВМ больших мейнфреймов. В предыдущей главе мы отметили, что разработчики __древних__ компьютеров первым делом оснащали свои детища компилятором Фортрана - точно так же в __средние века__ разработчики 16-разрядных мини-ЭВМ (PDP-11, они же СМ-3, СМ-4) оснащали свои операционные системы интерпретатором Бэйсика, хотя для таких машин он уже должен был считаться устаревшим. А разработчики восьмиразрядных домашне-игровых компьютеров своей жизни без Бэйсика не мыслили, потому что написать для такой слабой машины мало-мальски приличный компилятор было весьма непростой задачей, стоимость которой свела бы к нулю всю привлекательность таких машинок. А на советских ПК обычно вообще никакого другого программного обеспечения не было. Более серьезные программисты не жаловали Бэйсик, считали его //суррогатной технологией//. Однако в средние века проблема суррогатных технологий не ощущалась так остро, поэтому к ней я надеюсь вернуться, когда наша история дойдет до нового времени. \\ |
На замену Бэйсику был придуман Фокал, но он не обещал ни чудес, ни революций и в итоге оказался мертворожденным. Несмотря на критику, которой Бэйсик подвергался с "молодости", он пережил несколько реинкарнаций. Однако будущего у него нет. \\ | На замену Бэйсику был придуман Фокал, но он не обещал ни чудес, ни революций и в итоге оказался мертворожденным. Несмотря на критику, которой Бэйсик подвергался с "молодости", он пережил несколько реинкарнаций. Однако будущего у него нет. \\ \\ |
=== Статическая и оверлейная линковка === | |
Выше мы рассмотрели линковщик как новую (в сравнении с древней эпохой) служебную программу, собирающую загрузочный файл из множества объектных файлов, выданных компилятором. В простейшем случае линковщик помещает в загрузочный файл основную программу со всеми нужными подпрограммами - это //статическая линковка//. В средние века наряду со статической была уже освоена //оверлейная линковка//: весь программный код делился на сравнительно небольшой основной загрузочный модуль и несколько оверлейных модулей. При запуске программы на выполнение основной загрузочный модуль загружался в оперативную память, и ему сразу передавалось управление, а оверлейные модули подгружались только тогда, когда нужно было выполнить содержащиеся в них подпрограммы. Разумеется, вопрос о том, какие части программы включить в основной загрузочный модуль и какие в оверлеи, мог решить только программист: "программист решил - линковщик сделал". Оверлейная линковка позволяла (1) уменьшить затраты времени на загрузку программы в оперативную память и (2) эксплуатировать большую и сложную программу на машине с ограниченной емкостью памяти (пусть хотя бы ценой некоторой "задумчивости" при выполнении некоторых операций), но не спасала от того, что разные программы на половину или больше состоят из одних и тех же деталей: каждый оверлейный модуль принадлежал какой-то одной программе. Отсюда вытекает очевидная идея "обобществить" оверлейные модули, но эта идея - более поздняя. Мы ее коснемся в главе "новое время". \\ \\ | |
==== Немного воспоминаний и размышлений ==== | ==== Немного воспоминаний и размышлений ==== |
В предыдущей главе я рассказывал вам про свою студенческую практику, но не закончил этот рассказ - теперь, как и обещал, продолжу. \\ | В предыдущей главе я рассказывал вам про свою студенческую практику, но не закончил этот рассказ - теперь, как и обещал, продолжу. \\ |