Навеяно
http://www.haiku-os.org/blog/mmu_man/2008-11-03/say_what_you_want_from_us_but...
Вкратце - "не все люди в этом мире желают сидеть на x86" (А разработчики альтернативных осей - не могут по понятным причинам использовать линуксовые драйвера даже на x86. Особенно те, где открыта только небольшая часть, интерфейс для общения с бинарным модулем. Другая причина - плохо документированный, брошенный код - но IMHO это не чисто линуксовая проблема.)
Решил вот поделится своим мнением по поводу открытых архитектур. Я не обладаю достаточными знаниями чтобы утверждать чем MIPS, ARM, SH4 (используемые во многих устройствах бытовой электроники) лучше один другого. Но я могу судить с точки зрения продвинутого пользователя, который не чурается заглядывать в исходники, но при этом желает иметь систему чуть быстрее чем z80.
Ассоциация с z80 не случайна - даже этот крайне маломощный (8 бит регистры и шина данных, 7Mhz тактовая - максимальная скорость переброски данных в районе 1 Мегабайта в секунду, меньше миллиона операций в секунду) процессор был достаточным для однозадачного пргограммирования многих довольно ресурсоёмких задач, и моё первое знакомство с причудами схемотехники и понятием "архитектура компьютера" пришло именно со знакомства с разными русскими Спектрум-ориентированными сайтами в районе 2000-го года.
[link block 0
http://zx.pk.ru/
"Спринтер" и всё такое.
]
Именно тогда я узнал про кульный компьютер Amiga и его подход к мультимедиа (графика высокого разрешения, цифровой звук, видео) как к спец-задачам, лучше всего выполянемым спец-процессорами. Намного позже я узнал некоторые подробности про высокопроизводительные рабочие станции SGI. Используя очень умно запрограммированные спец-контроллеры для повторяющихся вычислений 3D-графики на разных этапах построения картинки + специализированное железо для перевода векторного представления графики в растровое первые графические терминалы SGI показывали крайне интересные результаты на очень маломощном по сегодняшним меркам процессоре. Но наверное самое главное - в поисках информации о работе этих древних по нынешним меркам машин я нашел большое количество информации по теории работы с 3-d графикой на _не очень сложных_ примерах, и самое важное - как это сделано в железе. То есть - более всестороннее и глубокое понимание того, как это делается. Вообще, понимание того как работает информационная машина (компьютер), умение модифицировать его поведение, то есть умение быть когда надо чуть-чуть программистом я считаю важнейшм преимуществом пользователя открытых опереационных систем. А воспитание и "разгон" (к вершинам знаний) такого пользователя - важной задачей ПО с открытми исходниками и лицензиями. К сожалению, когда радость творчества перерастает в рутину (нет дров на контроллер винчестера, нет дров на контроллер USB, нет дров на контроллер сетевой карты, нет дров на .... ) у многих хороших программистов опускаются руки. Вот чтобы такое не происходило и важны открытые спецификации на железо. (плюс разумеется умение и желание работать сообща, иногда талантливые разработчики ведут себя не очень честно и проталкивают собственное решение проблем технических с помощью социального давления. Пример есть в листе v4l , не говоря уже про тоже имеющюй отношение к личности разработчика пример с Гансом Рейзером).
[ link blok 1
http://www.futuretech.blinkenlights.nl/o2/
http://www.futuretech.blinkenlights.nl/iris-faq.html
http://www.archive.org/details/Computer1984_6
В Гугле например находится статья "The Geometry Engine: A VLSI Geometry System for Graphics", с картинками и пояснениями (англ, естественно) Было очень познавательно.
]
К сожалнию или к счастью, сегодня на дворе самый конец (окнец? намёк на вездесущие пока винды ....) 2008-го года, и просто красивой 3d-картинкой или _цифровым_ звуком никого не удивишь. Огромные потоки цифровой информации генерируются самим домашним пользователем, и он желает чтобы компютер на его столе был не просто игрушкой для программирования самого себя, но и помогал в обработке этой цифровой информации. И тут спектрум-подобные машины к примеру просто остаются за бортом, потому что даже с использованием всех возможных ухищрений объёмы информации измеряемые в мегабайтах в секунду, с жестким условием реалтайм-отображения им просто не по зубам. Картинка размером 1024*768*24 бит - мой рабочий монитор сейчас - занимает больше двух мегабайт в памяти. С учетом того что таких и даже бОльших картинок обычно не одна, а к примеру 4 (четыре рабочих стола в E16 - очень удобно), то объем необходимой оперативной памяти автоматически устремляется в самом идеальном случае к десяткам мегабайт. Необходимость совершать какие-то действия над подобными картинками приводит к необходимости очень высокого быстродействия памяти, шины данных, процессора. (что получается когда шина становится бутылочным горлышком - можно наблюдать на примере открытого смартфона Neo FreeRunner и его видеоподсистемы, где экран 640*480*16 бит подсоединен к видеоакселератору, который черпает данные из памяти через канал шириной меньше чем ISA-шина. 8 мегабайт в секунду, примерно. Подробности в листе рассылки OpenMoko. Или нечто аналогичное для шины Zorro II на Амиге, про которую я узнал из линксового драйвера для фреймбуфера, drivers/video/fm2fb.c) А это - усложнение схемотехники за пределы доступного обычному юзеру с паяльником. Слишком высокие частоты, слишком большое количество проводников. Нет, продвинутый пользователь, кто на работе имеет дело с подобными высоокочастотыми устройствами может и в домашних условиях нарисовать платку, способную работать, и даже стабльно. Но пока такое умение довольно редкое. А значит, железо по-любому будет производить кто-то другой, пользователь же должен просто иметь возможность собрать из блоков то что ему нужно (для экспериментов, удовольствия, или помощи в работе) и запрограммировать получившийся агрегат в меру своих умений (а это обычно для сложных много(суб)процессорных машин выливается в использование идей, алгоритмов и кода других разработчиков - иначе просто не получается.)
Мне кажется, архитектура графстанции начального уровня SGI O2 очень хорошо отражает идею использования дополнительного программируемого элемента (Image Co-Processor), выделенного для быстрой переброски графических и видео данных, с конвертацией на лету по фиксированным (YUV <-> RGB) и/или по загружаемым алгоритмам. Оригинальное (и к сожалению - проприетарное, закрытое и фактически утерянное для масс) программное обеспечениие в составе ОС Irix использовало данный сопроцессор для декодирования сжатых видео потоков, работы с изображениями, OpenGL. На данный момент существует только крайне экспериментальный и заброшенный драйвер для этого сопроцессора, вместе с очень сырым патчем к старым binutils для использования в качестве именно _программируемого_ элемента. Не говоря уже про систему _отображения_, дисплейный контроллер, знания о работе и программировании которого (необходимо для работы Xfree/Xorg с современными библиотеками GUI поверх с приемлимой скоростью) появились в открытом доступе только в этом году, благодаря старанию разработчика из NetBSD.
http://my.opera.com/Macallan/blog/index.dml/tag/O2
