Ну, скажем, если макрокоманда описывает 8 дисководов на одном контроллере, то она развернётся в восемь блоков управления устройством -- по одному на каждый из дисководов. Часть информации в них идентичная, часть (вроде адреса устройства) отличается.
Ну, я подозреваю. Переключение контекста -- это всегда дорого, а если при этом сыплются кэши и/или TLB, то вообще жуть... В частности, поэтому настоящих микроядерных осей и нет (та же QNX ни разу не микроядерная, если брать сей термин, как он изначально понимался: в ней абсолютно все функции традиционного ядра вроде управления процессами, потоками и памятью, находятся в общем адресном пространстве, и лишь драйверы устройств вынесены в отдельные пространства -- но такое было возможно ещё в той же RSX-11 и VAX/VMS).
Ну, если и потеряли, то лишь в плане знакомства с возможностями довольно навороченных макросредств. Синтаксически, повторюсь, он довольно страшненький, и многие вещи можно было бы решить лучше (в частности, лучше решено в макроассемблере PDP-11 -- но функционально он несколько слабее).
Сишный препроцессор достаточен для условной трансляции, но у него нет ни возможностей организовывать циклы, ни каких-либо вычислительных возможностей, ни полноценной манипуляции с параметрами макросов. Соответственно, сложную процедуру сборки можно организовать лишь с использованием внешних средств, которые наклепают кучу дефайнов, а на долю препроцессора останется лишь условная трансляция.
Сишный препроцессор исключительно убог. В той же ОС/360 процесс генерации (сборки) ОС построен как раз на использовании ассемблера с его макросредствами: параметры будущей системы описываются кучей макрокоманд, и ассемблер на выходе даёт не объектный файл, а текст заданий, выполнение которых, собственно, и сгенерирует систему. Ну а для этого макросредства должны иметь возможность вычислений во время трансляции, обработки строк, ветвлений, циклов и т.д. (Конкретно в асме ОС/360 это всё синтаксически довольно коряво -- всё ж первая половина 1960-х -- но функционально полноценно.)
Ну дык если регистров для передачи не хватает, придётся в любом случае размещать в памяти -- а там стек будет, скорей, даже более эффективным, чем произвольное место ОЗУ, поскольку он с большей вероятностью будет в кэше.
Что такое традиционные макрокоманды, знаете? Какие, скажем, были в ассемблере OS/360? Вот ничего подобного в нём нет. Локальных меток (определённых только внутри блока, ограниченного нормальными метками) тоже нет -- лишний гемор при написании команд переходов. А переизбыток в нём директив для вывода всякой разной информации в объектный файл -- как раз для того, чтобы переваривать выхлоп компилятора и помещать в объектный файл сгенерированную компилятором отладочную информацию.
В ГНУсном ассемблере изначально заимствовали порядок, принятый в родном ассемблере PDP-11, но почти во всём остальном всё исказили; потом зачем-то применили его к интеловскому, но изрядная часть других архитектур использует синтаксис, "родной" для архитектуры, а не для ГНУсных извращенцев.
Вообще, практически единственная задача AS -- глотать выхлоп GCC и преобразовывать его в объектный файл. Для написания сколько-нибудь серьёзных ассемблерных программ он непригоден (нет очень многих возможностей, и, в частности, макросредств).
Архитектура (система команд и т. п. вещи) не меняется уже скоро четверть века и называется AMD64. А перечисленные в этом переписывании других источников изменения -- это микроархитектура, т. е. внутреннее устройство процессора.
Почитал вику про этот самый SIMT. Не сказать, чтоб какие-то кардинальные отличия от обычного SIMD были:
The key difference between SIMT and SIMD lanes is that each of the SIMT cores may have a completely different Stack Pointer (and thus perform computations on completely different data sets), whereas SIMD lanes are simply part of an ALU that knows nothing about memory per se.
Такое, в общем-то, и на обычном SIMD сделать можно, если подготовить данные должным образом.
Ага, но позже. Ну а я вообще люблю придираться к терминологии и т.п. -- а то иногда пишут уж очень вольно (до такой степени, что перестаёшь понимать, о чём речь).
Вообще, в FAT содержатся не номера секторов, а номера кластеров, и не в формате LBA, поскольку последний относится к адресации секторов на диске, а не кластеров на томе FAT.
Ну, я начал работать с компами с 13 лет, английский реально не знал (обычная советская школа с весьма посредственным, скажем так, уровнем преподавания). Но это абсолютно никак не мешало мне (и не только мне) освоить на Агате сначала Бейсик, а затем Ассемблер. Робик с Рапирой даже не пробовали смотреть -- интереса никакого они для нас не представляли. А через пару лет, когда уже я вёл кружок в нашей же школе для 5-6-классников (половина из которых была "немцами" -- это сейчас английский обязательный, но не в 1980-х), они тоже без проблем всё усваивали. Знание английского для того, чтобы выучить десяток-другой команд, НЕ ТРЕБУЕТСЯ от слова совсем. Ну а кто на такое не способен -- тому нечего делать не только в плане компьютеров, но и вообще в чём угодно, где требуется хотя бы капля мозгов.
Ну, настоящей виртуализации (не программной эмуляции чужой системы команд) без железной поддержки на IA-32 быть не может из-за наличия команд, которые являются непривилегированными, но работают с системной информацией (считывают содержимое каких-то системных регистров, если склероз не изменяет). Соответственно, либо делать неполноценную "обычную" виртуализацию, которая работать будет лишь в случае, если гостевая ОС эти команды никогда не использует (а соответственно, не требуется их перехватывать и эмулировать средствами гипервизора), либо как-то разбираться с машинным кодом гостевой системы перед его выполнением, обнаруживать такие команды, заменять их чем-то, вызывающим прерывание... Ну, думаю, Вы поняли. Оба подхода не дают 100% надёжности работы, а второй, к тому же, очень сложен и временами вызывает сильные тормоза. Ну а как делали эти самые VMware/Connectix -- понятия не имею, честно говоря.
Ну, для СССР вполне себе супер была, выдавая 200 или сколько там млн. оп/с -- как раз за счёт параллелизма. Плюс, она была достаточно мобильной, в отличие от типичных высокопроизводительных машин что у нас, что у них, которые были чисто стационарными.
Ну, скажем, если макрокоманда описывает 8 дисководов на одном контроллере, то она развернётся в восемь блоков управления устройством -- по одному на каждый из дисководов. Часть информации в них идентичная, часть (вроде адреса устройства) отличается.
А что подразумевается под тэгированной памятью?
Ну, я подозреваю. Переключение контекста -- это всегда дорого, а если при этом сыплются кэши и/или TLB, то вообще жуть... В частности, поэтому настоящих микроядерных осей и нет (та же QNX ни разу не микроядерная, если брать сей термин, как он изначально понимался: в ней абсолютно все функции традиционного ядра вроде управления процессами, потоками и памятью, находятся в общем адресном пространстве, и лишь драйверы устройств вынесены в отдельные пространства -- но такое было возможно ещё в той же RSX-11 и VAX/VMS).
Ну, если и потеряли, то лишь в плане знакомства с возможностями довольно навороченных макросредств. Синтаксически, повторюсь, он довольно страшненький, и многие вещи можно было бы решить лучше (в частности, лучше решено в макроассемблере PDP-11 -- но функционально он несколько слабее).
Сишный препроцессор достаточен для условной трансляции, но у него нет ни возможностей организовывать циклы, ни каких-либо вычислительных возможностей, ни полноценной манипуляции с параметрами макросов. Соответственно, сложную процедуру сборки можно организовать лишь с использованием внешних средств, которые наклепают кучу дефайнов, а на долю препроцессора останется лишь условная трансляция.
Сишный препроцессор исключительно убог. В той же ОС/360 процесс генерации (сборки) ОС построен как раз на использовании ассемблера с его макросредствами: параметры будущей системы описываются кучей макрокоманд, и ассемблер на выходе даёт не объектный файл, а текст заданий, выполнение которых, собственно, и сгенерирует систему. Ну а для этого макросредства должны иметь возможность вычислений во время трансляции, обработки строк, ветвлений, циклов и т.д. (Конкретно в асме ОС/360 это всё синтаксически довольно коряво -- всё ж первая половина 1960-х -- но функционально полноценно.)
Ну дык если регистров для передачи не хватает, придётся в любом случае размещать в памяти -- а там стек будет, скорей, даже более эффективным, чем произвольное место ОЗУ, поскольку он с большей вероятностью будет в кэше.
Что такое традиционные макрокоманды, знаете? Какие, скажем, были в ассемблере OS/360? Вот ничего подобного в нём нет. Локальных меток (определённых только внутри блока, ограниченного нормальными метками) тоже нет -- лишний гемор при написании команд переходов. А переизбыток в нём директив для вывода всякой разной информации в объектный файл -- как раз для того, чтобы переваривать выхлоп компилятора и помещать в объектный файл сгенерированную компилятором отладочную информацию.
В ГНУсном ассемблере изначально заимствовали порядок, принятый в родном ассемблере PDP-11, но почти во всём остальном всё исказили; потом зачем-то применили его к интеловскому, но изрядная часть других архитектур использует синтаксис, "родной" для архитектуры, а не для ГНУсных извращенцев.
Вообще, практически единственная задача AS -- глотать выхлоп GCC и преобразовывать его в объектный файл. Для написания сколько-нибудь серьёзных ассемблерных программ он непригоден (нет очень многих возможностей, и, в частности, макросредств).
Значит, с чем-то ещё спутал. Всё ж под ПК на асме уже четверть века не быдлокодил, особо поэтому не слежу :)
Но, вроде б, для реализации функций вроде memcpy стандартные либы используют пересылки через SIMD-регистры. Или тоже с чем-то путаю?
В 64-разрядном режиме, если память не изменяет, строковые операции выпилены.
Архитектура (система команд и т. п. вещи) не меняется уже скоро четверть века и называется AMD64. А перечисленные в этом переписывании других источников изменения -- это микроархитектура, т. е. внутреннее устройство процессора.
Почитал вику про этот самый SIMT. Не сказать, чтоб какие-то кардинальные отличия от обычного SIMD были:
Такое, в общем-то, и на обычном SIMD сделать можно, если подготовить данные должным образом.
Во-первых, надо не читать, надо писать :)
А во-вторых, сравните кодирование команд в PDP-11 и в 8086.
Ну, пока что ничто не мешает использовать хоть Виваду, хоть Квартус с "коммунистической системой лицензирования"...
Ага, но позже. Ну а я вообще люблю придираться к терминологии и т.п. -- а то иногда пишут уж очень вольно (до такой степени, что перестаёшь понимать, о чём речь).
Вообще, в FAT содержатся не номера секторов, а номера кластеров, и не в формате LBA, поскольку последний относится к адресации секторов на диске, а не кластеров на томе FAT.
Отечественные ПЛИС есть, но те, о которых мне известно, являются клонами древних Альтер, ну и, как обычно, их фиг достанешь :)
Ну, я начал работать с компами с 13 лет, английский реально не знал (обычная советская школа с весьма посредственным, скажем так, уровнем преподавания). Но это абсолютно никак не мешало мне (и не только мне) освоить на Агате сначала Бейсик, а затем Ассемблер. Робик с Рапирой даже не пробовали смотреть -- интереса никакого они для нас не представляли. А через пару лет, когда уже я вёл кружок в нашей же школе для 5-6-классников (половина из которых была "немцами" -- это сейчас английский обязательный, но не в 1980-х), они тоже без проблем всё усваивали. Знание английского для того, чтобы выучить десяток-другой команд, НЕ ТРЕБУЕТСЯ от слова совсем. Ну а кто на такое не способен -- тому нечего делать не только в плане компьютеров, но и вообще в чём угодно, где требуется хотя бы капля мозгов.
Ну, настоящей виртуализации (не программной эмуляции чужой системы команд) без железной поддержки на IA-32 быть не может из-за наличия команд, которые являются непривилегированными, но работают с системной информацией (считывают содержимое каких-то системных регистров, если склероз не изменяет). Соответственно, либо делать неполноценную "обычную" виртуализацию, которая работать будет лишь в случае, если гостевая ОС эти команды никогда не использует (а соответственно, не требуется их перехватывать и эмулировать средствами гипервизора), либо как-то разбираться с машинным кодом гостевой системы перед его выполнением, обнаруживать такие команды, заменять их чем-то, вызывающим прерывание... Ну, думаю, Вы поняли. Оба подхода не дают 100% надёжности работы, а второй, к тому же, очень сложен и временами вызывает сильные тормоза. Ну а как делали эти самые VMware/Connectix -- понятия не имею, честно говоря.
Ну, для СССР вполне себе супер была, выдавая 200 или сколько там млн. оп/с -- как раз за счёт параллелизма. Плюс, она была достаточно мобильной, в отличие от типичных высокопроизводительных машин что у нас, что у них, которые были чисто стационарными.