OSDev

Иногда забавно все это читать.
Кроме этого, здесь, в этом тексте есть голос мудрости.


Но все равно, забавно. Я не слышу здесь о VLIW архитектуре, которая тоже является целой областью и целый рынок. Имеет и свое весомое применении в жизни.

Вот ее и нужно брать как самый эпичный пример. А верно говоря, ассемблер под подобную архитектуру. Например, TMS320C от Texas Instrument.

i386 по сравнению с этим ассемблером - так себе, упражнения для детей.

Процессор и подобные ему имеют 32 40-битных регистров общего назначения, 32 32-битных аккумуляторных регистров, 16 256-битных векторных регистров, около 16 32-битных контролирующих регистров, 2 блока сложения/умножения, 2 блока логических операций, 4 предикатных регистров и всякие регистры памяти, стека, задач, регистры маски.
500 команд с >4 вариаций, для каждой команды есть еще столько же вариаций свитчей.

листинг


это значит что команды могут выполняются за один такт, а знак "||" означит параллельность - то есть за один цикл конвеера.
В таком случае возникает понятие - microthreading. Микропоточность на уровне конвеера.
Первая команда может значить, что мы выполняем операцию XOR с регистрами a0 и g0, помещаем результат в регистр a26. Rоманды выполниться при условии что в предикатном регистре ?Pr0 лежит булевское значение true.
4op это свитч который говорит, что команда должна выполняться на серией последовательности регистров, а именно


И ЭТО НЕ ВЕКТОРНАЯ ОПЕРАЦИЯ. Это как бы еще не SIMD. При этом еще выполняются операции nop.Вместо них может быть любые совместимые операции. Благодаря тому, что есть, к примеру, 2 арифметических блока, можно одним махом умножать или сумировать в 2-х командах. Есть также операции умножения-сложения mac. Команды типа cmp, jne, jnz, test не нужны, так как "условие" можно поставить под любую операцию. Например, для аналогичных есть команда br(jmp).
Есть команды перемножения матриц для четных номеров регистров - так назвать, "сеточка".

Теперь сложность в том, что программист должен учитывать все особенности архитектуры, следить за работой конвейера команд(а он работает в ручном режиме), следить как минимум, за 64 регистрами(читай переменными) и держать их все в голове, следить за микропоточностью(это когда в одном потоке команд выполняетя 2 разных алгоритма по цене одного), следить за свитчами.

Компиляторов немного. В основном для С и их мало, и они почти не используются, так как неэффективны. Поэтому все пишется ручками.А программы, типа: разжатие и обработка формата MPEG. Это непросто вставочки как в шейдерах первой версии для графического процессора, например, ATI 2001 года, а целое полотнище кода.

И это пример дешевенького, простенького процессора. Не лучший из своего типа. Это как 80386 на фоне Core i7.
А теперь представьте четырехядерного монстра, с 4-х блочным конвеером, на тактовой частоте 2,4 Гц., с набором команд >500, и целым зоопарков регистров самых немыслимых назначений. И это весьма полноценный процессор, несмотря на специфичность их приминения. На нем есть порты ввода/вывода, аппаратное переключение контекста, страничная организация памяти.

Так много в него влазит за счет, того, что ненужно засовывать кучу лишних блоков, которые выполняют автоматически рутинные задачи.
Единственный недостаток таких процессор - сложность разработок.
Даже энергопотребление у них мизерное, потому их и используют в каждом мобильном телефоне, планшете, плеере, портативной DVD видеостанции.
Имеет мощь не хуже Core i3, но пожирает в 20 раз меньше ресурсов. Даже изготовление их, очень мало затратно и просто, за счет чего и цена ниже.


Теперь подытоживая вышесказанное, программировать на ASM - это не каприз, не замашки на производительность, а жизненная необходимость.

P.S. Почему забавно?! Потому, что вы берете в пример процессоры, которые делают для ленивых детей. Которые не могут "освоит школьный материал". Это для всяких там "жадных" процов, даже дворник может написать, не то что на АСМ, а сам АСМ и компилятор для этого АСМ, на этом же языке, еще и в придачу компилятор для C - от "нечего делать".

Да, компиляция под такое -- та ещё задача. Полагаю, это одна из причин, почему мэйнфреймы CDC в конечном итоге сошли со сцены: архитектура процессоров, подобных описанных Вами, в первом приближении соответствует архитектуре именно тех древних машин. Естественно, компиляторы там были (Фортран, во всяком случае, точно), но не думаю, что отличались высоким качеством кода. Вот под более традиционные машины и тогда компилировали хорошо (и уж точно лучше, чем GCC, если говорить об уровне процедур -- всяких LTO и прочих глобальных оптимизаций тогда не было в принципе из-за малых объёмов памяти).

Но программирование под подобный процессор в определённом смысле сродни упомянутой Yoda задачей с базой данных: оба случая очень и очень специфичны.

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

Но когда вы поймете как на ассемблере писать правильно, то он у вас привратся в ЯВУ. Так почему бы не начать с него.
Си похой язык. За примерами далико ходить небуду один умник написал FFT но комплексные числа передал как указать на массив действительных. С тех пор 99% кто пробует использовать этот код делают ошибку.
Если код оформлен правильно, то скорость вхождения нвого человека в ваш проект возврастатает.

Меня вот другое смущает почему приложения рассчитанные на непрерывную работу пишут на Си. Когда как рациональнее писать на бесике на крайней случай на java.

Лично я в свое время решил доказать что делфи всемогучь поэтому и начал писать на нём. Хотя в последствие первичный загрузчик TASM вточиный Borland Pascal и ядро на Delphi

SII, а чем вам Unix так ненравится?

Всем Начиная с fork и навязывания синхронного ввода-вывода.

Вот про регистры как переменные не очень большого радиуса действия и переименование регистров хотелось бы поподробнее.



Мне в Си больше всего не хватает конструкций наподобии:
import javax.servlet.http.HttpServlet;

и вместо имени javax.servlet.http.HttpServlet servlet можно было бы писать коротко HttpServlet. Отсутствие возможности разбиения имен функций по каким-нибудь категориям хотя бы.

namespace-ы из C++ гораздо менее удобные. Или вообще как в хml:



В данном случае описан namespace c именем "http://www.foobar.com" и алиасом t. В другом случае может быть xmlns:x="http://www.foobar.com", при этом namespace будет тем же, хотя и алиас другим. Но это слегка из другой оперы. Просто иллюстрация концепции.

Вот насчет контроля над регистрами в ассемблере интересно.



С fork() понятно о чём речь. Хотя не совсем. fork() - представляет из себя основу межпроцессного взаимодействия под UNIX-ом. Конвейеры между процессами организуются на базе наследованных дочерним процессом файловых дескрипторов.

Начет "навязывания синхронного ввода-вывода". Хотелось бы расшифровать подробнее, если возможно.

fork -- средство запуска нового процесса (задачи), причём, насколько знаю, единственное (в классическом Унихе). Вместо того, чтобы просто сделать хорошее явное управление памятью (которым будут пользоваться те задачи, которым оно нужно), обычный запуск нового процесса (с необязательной возможностью передать ему все или часть дескрипторов -- это далеко не всегда нужно) и обычную же многопоточность, родили этот изврат.



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

В классическом единственное. Дескрипторы наследуются все. Дочерний процесс ненужные дескрипторы закрывает. Так как это происходит в коде одной по-сути программы, то выглядит это достаточно удобно.

if (fork() > 0) {
// parent code
} else {
// child code
}

После закрытия лишних дескрипторов в child ветке для запуска другой программы используется exec(). У дочернего процесса копируется сегменты данных и стека. Вот это не сильно красиво - ведёт к разрастанию размеров дочерних процессов. Я на эту тему писал как-то статейку: http://dev64.wordpress.com/2011/12/17/%D1%8D%D0%BA%D1%81%D0%BF%D0%B5%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D1%82-%D1%81-fork-2/. Однако в более поздних реализациях систем есть tfork() или что-то наподобии, что не копирует дескрипторов...

Насчет синхронного ввода вывода. В UNIX универсальной функцией для реализации асинхронного ввода-вывода является select(), в более поздних версиях poll(). select() позволяет организовать такой функционал. В классическом юниксе работает select на любом типе файловых дескрипторов. А дескриптором является любой файл, сокет или устройство.

В частности с помощью select() на классическом UNIX, не имеющем тредов, можно реализовать треды пользовательского уровня. select() работает в том числе и в WinSock библиотеке под Windows, что позволяет писать переносимые программы с использованием сокетов.

Не путайте неблокирующий ввод-вывод и асинхронный. Неблокирующий позволяет не ожидать готовности к выполнению операции (например, read из сокета не будет ждать появления данных в буфере ОС), а асинхронный - ее завершения. Например, нельзя использовать select на файле на диске - файл всегда готов к чтению. Но если вы отправите запрос на, например, чтение 4 гигабайт данных с диска, то поток будет остановлен до завершения чтения, которое займет достаточно много времени. Асинхронный же read вернет выполнение немедленно, а когда операция будет завершена - уведомит задачу каким-либо способом.

В POSIX есть асинхронный ввод-вывод - расширение AIO - но нормальных реализаций я еще не встречал. Ядерная реализация в линуксе не поддерживает кеширование, что убивает производительность, а реализация в glibc использует пул потоков, что жрет кучу ресурсов зря.

Fork же плох тем, что в обычном сценарии - fork с последующим exec - ядро делает много лишней работы, сначала копируя таблицы страниц и дескрипторов, а затем уничтожает их и заменяет на таблицы нового процесса.

Собственно неблокирующего ввода обычно достаточно. 4 гигабайта с диска просто так читать не будешь, все равно скорее всего куда-то все будет писаться. Появится та или иная буферизация.



С другой стороны API такой оказался простым и понятным для прикладных программистов.

Для асинхронного ввода-вывода нужны потоки. В классическом юниксе их и не было. Практика разработки показала, что системы, реализованные на базе классической однотредовой реализации, в разы надежнее, чем аналогичные более поздние реализации. Так например случилось с QNX4 и QNX6. QNX конечно своеобразная операционная система. QNX6 от QNX4 отличается прежде всего многотредовостью от природы. В QNX4 все было однотредовым. Системы на базе QNX4 намного надежнее, чем на базе QNX6.

Другой надежной однотредовой системой был SCO UNIX. В нем тоже не было никаких тредов. SCO UNIX в то время как у FreeBSD был аптайм пол месяца, не перегружался годами.

Мы ведь здесь сравниваем не Аду с С, а ассемблер с ЯВУ.
По поводу читаемости. Можно написать хороший или плохой код на ЯВУ и хороший или плохой код на ассемблере. Но в любом случае читаемость хорошего кода на ЯВУ лучше, чем хорошего кода на ассемблере.


Не вижу принципиальной разницы. Разница между прикладным и системным ПО в первую очередь в целях использования, а не в способах кодирования.


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


Ну конечно, так все и поверили .


А о таком понятии, как "золотая середина", слышал?


Почему же боятся? Я не боюсь и честно говорю, С/С++ устарели и требуют несовместимого обновления. У меня есть чёткое видение нового языка, поэтому одним из пунктов своей программы я вижу создание компилятора с нового ЯВУ.


Это далеко не единственный минус и, может быть даже не самый главный. Самые противный минус Паскаля, Модулы и Ады (я перечислил те языки общего класса, на которых имел несчастье выполнять проекты) - это слишкам-много-букав и, как следствие, ужасная читаемость. Та мысль, которую можно выразить в двух очевидных строках, в них необходимо расписывать на целый абзац мутного текста, содержащего кучу лишних слов. Чего только стоят эти begin/end!
Вот видишь, SII, холивар разгорается. Ты всё-таки этого добился .

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>