 |
|
Вопросы совместимости - страшная вещь. Они мешают развиваться и тянут назад.
Довольно давно кто-то из брэндов (кажется, compaq)
попытался выпустить "legacy-free PC", в которой избавлялся от большинства
того,
что традиционно торчит в "intel-based PC's" со времен того самого, первого
"писюка" - от клавиатурного порта, мышиного порта, огрызка под названием
"порт принтера", последовательных портов... клава, мышь, принтер и модем -
на usb,
ISA-слоты отсутствуют как класс... на морде же этого прогрессивного
монстра гордо красовался 3.5" дисковод. Не смогли избавиться. Крепко
держит.
Ладно периферия - периферия дело наживное, для новой периферии ничего кроме
новых
драйверов как бы и не требуется. Возмем что-нибудь более глобальное.
Ну, там, изменение разрядности - как в свое время тот же intel PC
перепрыгнул с "как бы 20" разрядов на нормальные 32 разряда, и как сейчас
тот же intel продвигает 64-разрядную архитектуру. Последнюю я, правда,
в глаза не видел (и, думаю, на столе у меня оно окажется не скоро),
но, говорят, на ней уже есть вездесущий Линукс, и в секретных лабораториях
Микрософт
удалось загрузить не менее секретный билд windows.
При смене разрядности процессора драйверами уже не отмашешься -
чтобы полноценно использовать новые возможности, придется переписать
заметный кусок операционной системы (а то и всю OS - что мы и видим на
примере
тех же windows), обсмотреть весь оставшийся код на предмет того,
не заложились ли мы где-то на разрядность данных или указателей,
пересобрать всю эту кучу кода, и потратить уйму времени на отладку.
Переход ia16 - ia32 (грубо говоря, от 286 к 386 процессору)
был практически безболезненным, поскольку
старые программы продолжали работать в 16-битном режиме 32-битного
процессора.
Если бы ia32 принципиально отличалась бы от ia16 - все старые программы,
за редким исключением, пошли бы лесом, поскольку почти во всех
программах так или иначе закладывались на особенности архитектуры,
в частности на разрядность данных. Сложно было в те времена "писать
портабельно"
на intel PC, да и смысла особого никто не видел.
Переход ia32 - ia64 пока фактически не состоялся (ждем-с),
но в юниксовом мире с этим проще - привычка "писать портабельно"
у программистов есть, поскольку портабельность эта востребована -
тот зоопарк архитектур, на которых заводится тот же Линукс,
вызывает умиление и восхищение. Тем более, что на пресловутой ia64
Линукс смогли загрузить раньше винды. ЧтО. в принципе, логично.
Но все эти отказы от LPT-портов, придумывания всяких
USB, AGP и прочих TLA, да и даже увеличение разрядности
(а также объема памяти, улучшение алгоритмов распараллеливания инструкций в
процессоре,
создание новых instruction set'ов, и что я еще мог забыть) -
на революцию не тянет. Экстенсивное развитие - отращиваем
память, разрядность, да гоним гигагерцы - вот всё быстрей и работает.
А защита приложений друг от друга по прежнему реализуется через
механизм исключений, защита приложения от самого себя - сдвиги есть,
но не особо революционные...
Возмем простейшую вещь. "Двухголовый" писюк. Скажем, популярную вскоре
после появления socket 370 celeron'ов комбинацию из двух целеронов
на одной материнской плате Abit чего-то-там.
Два процессора - это круто. В два раза. Почти.
Запускаем две задачи - и они молотят параллельно, иногда конкурируя за шину
и
периферию (шина одна, и периферийные устройства тоже),
но ввиду наличия кеша в процессоре - в среднем все получается быстро.
Запускаем одну задачу с двумя нитями - каждая нить вешается на свой
процессор,
и и обе молотят параллельно. Обрабатывая, например, данные из одного
массива "в две струи", и обмениваясь друг с другом информацией через...
через оперативную память, для скорости - не через сокеты же, в самом деле.
И если одна нить на одном процессоре взвела "флажок" в памяти (или записала
туда кусочек данных) - другая нить должна иметь возможность тут же считать.
Но стоп! Ведь процессор же должен по возможности работать с кешем, а не
грузить
шину перекачкой данных в память/из памяти? А значит - должен быть механизм,
обеспечивающий синхронизацию данных между кешами процессоров, причем чем
больше процессоров - тем более накладной становится такая синхронизация.
А почему? Да потому, что с тех времен, когда многозадачность
делалась многозадачными ОС на одном процессоре, подобный метод синхронизации
был если не поощряем, то хотя бы распространен. А в языке Си даже был
модификатор
volatile, предназначенный для подобных целей.
...а значит, до тех пор пока есть софт, закладывающийся на подобные методы
синхронизации - с революциями есть определнные напряги.
Напряги, впрочем, решаемые - уже сейчас такого рода синхронизация
не поощряется, плюс наличествует системное API, специально предназначенное
для синхронизации процессов, но - ближайший пример многонитевой программы,
синхронизующейся через общие переменные в памяти, я видел не далее чем вчера
- счетная задача, занимающаяся обсчетом полей и параметров плазмы
в некоей хитрой установке.
...когда-то давно dz писал про архитектуру (реально существующую),
где задача не может обратиться к не выделенному ей кусочку памяти
не потому, что схлопочет exception, а потому, что в этой архитектуре
технически невозможно создать указатель на объект, не принадлежащий тебе.
Идеальная защита, как приложений друг от друга, так и приложений
самих от себя (выход за границы массива, например, или некорректная
работа с указателями). Одна мелкая проблема - в семантику
языка Си это не ложится никак, да и в семантику большинства
других языков ложится со скрежетом и скрипом. А значит -
всё, начиная от ОС, и кончая прикладным софтом, придется писать
с нуля. А значит... а значит, крупный, денежный клиент,
которому ведь нужно, чтобы работало, а не чтобы было революционно и всё
такое,
платить не будет. Массовый клиент - тем более.
Значит, революций не будет. Будет эволюция, ограниченная
определенными рамками.
Когда Трансмета анонсировала свой crusoe, первым делом было объявлено, что
"на нем идет linux". Бабаян со своим "Эльбрусом" - анонсировали
возможность выполнения кода intel-процессоров.
Одна надежда - на новые языки, вроде той же Явы или C#, где
можно надеяться на меньшее количество неявных
закладок на архитектуру. Явных закладок там быть не должно.
...подумать только, не так давно язык Си считался очень подходящим языком
для
написания переносимых программ...
| |
| |