Аннотация
Пособие основано на лекциях, читавшихся автором в рамках курса «Архитектура ЭВМ и язык ассемблера» в Ташкентском филиале МГУ весной 2007 года; часть материала также прошла апробацию в рамках курса «Архитектура ЭВМ и системное программное обеспечение» кафедры Прикладной математики МГТУГА в 2008, 2009 и 2010 гг.
Пособие ориентировано на практические занятия с использованием системы команд i386, «плоской» (бессегментной) модели памяти, ассемблера NASM и операционной системы Linux или FreeBSD; в частности, описываются конвенции системных вызовов обеих систем, также для обеих систем приводятся исходные тексты файлов с макроопределениями, призванными облегчить ассемблерное программирование на ранних этапах изучения дисциплины.
Бумажные публикации
Пособие впервые опубликовано редакционно-издательским отделом МГТУГА в июле 2010 года под заголовком «Архитектура ЭВМ и системное программное обеспечение: язык ассемблера в ОС Unix» в виде двух отдельных частей; ISBN 978-5-86311-769-0 (часть I) и 978-5-86311-770-6 (часть II).
Второе издание пособия, включающее ряд исправлений, новую главу об арифметическом сопроцессоре, параграф, посвящённый машинному представлению целых чисел и некоторые другие дополнения, издано в 2011 году в издательстве МАКС Пресс. ISBN 978-5-317-03627-0.
Электронная версия
PDF-файл, полностью соответствующий печатной версии второго издания, можно взять тут: http://www.stolyarov.info/books/pdf/nasm_unix.pdf
Электронные версии обеих частей первого издания также доступны:
- часть I: http://www.stolyarov.info/books/pdf/asm_unix_mstuca_part1.pdf
- часть II: http://www.stolyarov.info/books/pdf/asm_unix_mstuca_part2.pdf
Статус бумажной версии
Второе издание имеется в продаже.
| Прикрепленный файл | Размер |
|---|---|
| Файл stud_io.inc для FreeBSD | 2.08 кб |
| Файл stud_io.inc для Linux | 2.21 кб |
| Архив с текстом примера greet из пар. 5.3 (часть II) | 1.38 кб |
| Программа cmdl.asm из пар. 4.4 (часть II) | 1.1 кб |
| Программа match.asm из пар. 2.6.9 (часть I) | 1.7 кб |
Приветствую.
Приветствую. Спасибо за книги, но вот в чем проблема, они не адаптированны по 64 битные версии ОС.
fylh@calculate ~/Сталец/labs/jap $ nasm -f elf lab1.asm
fylh@calculate ~/Сталец/labs/jap $ ls
3.asm asm lab1.asm lab1.o lab2 stud_io.inc
fylh@calculate ~/Сталец/labs/jap $ ld lab1.o -o lab1
ld: i386 architecture of input file `lab1.o' is incompatible with i386:x86-64 output
fylh@calculate ~/Сталец/labs/jap $
64-битное окружение
Попробуйте сказать линкеру -m elf_i386, то есть вот так:
ld -m elf_i386 lab1.o -o lab1
У меня сейчас под рукой нет 64-битной системы, так что проверить этот вариант я не могу. Если не сложно, сообщите о результатах. Если не сработает, скажите ld -V и киньте сюда результат. Спасибо.
fylh@kubuntu-2011-03:~/Ста
fylh@kubuntu-2011-03:~/Сталец/labs/jap$ nasm -f elf lab1.asm
fylh@kubuntu-2011-03:~/Сталец/labs/jap$ ld -m elf_i386 lab1.o -o lab1
fylh@kubuntu-2011-03:~/Сталец/labs/jap$ ls
3.asm asm lab1 lab1.asm lab1.o lab2 lab.o stud_io.inc
fylh@kubuntu-2011-03:~/Сталец/labs/jap$ ./lab1
Hello, world!
fylh@kubuntu-2011-03:~/Сталец/labs/jap$
Спасибо!
Большое спасибо за отчёт, одной проблемой меньше. Обращаю ваше внимание на второе издание -- вполне возможно, вас заинтересуют появившиеся в нём дополнения.
Nasm и библиотека Си
Здравствуйте!
Я попытался вызвать функцию printf из библиотеки Си, но програмку убиват ОС с сигналом SIGILL. Но когда я слинковал через gcc, то всё заработало. (т.е. надпись "Hello, world!" благополучна вышла). Не подскажете как правильно линковать через ld.
Я делал так:
# ld -o hello -shared /lib/libc.so.6 hello.o
# ./hello
Недопустимая инструкция
Через gcc так:
# gcc hello.o
# ./a.out
Hello, world!
#
Узнать, что там
Узнать, что там конкретно делает gcc, вы можете очень легко - дайте ему флажок -v, он вам сам расскажет. Но вообще идея делать динамически слинкованную бинарь из ассемблерной программы кажется мне по меньшей мере странной - нафига тогда вообще на ассемблере писать.
А х64 редакция будет?
А х64 редакция будет?
Ведь не секрет, что х64 версии дистрибутивов оказываются быстрее своих х86 версии и не в последнюю очередь из-за того что последние выпускаются с разной совместимостью (i386/i486 и т.д.) что существенно сказывается, так как не используются все современные инструкции процессоров.
В х64 в этом плане проще, так как набор инструкций появился относительно недавно.
Спасибо за внимание и книгу, ознакомлюсь.
Вряд ли
Имеющаяся книга появилась как обобщение опыта, полученного в ходе чтения соответствующего курса. Сам курс появился в результате моего категорического нежелания вспоминать, как всё это делается под MSDOS в 16-битной системе команд. В Ташкенте курс был прочитан один раз и больше, видимо, читаться не будет никогда; из МГТУГА я тоже потихоньку ухожу, так что там этот курс (во всяком случае, в моём исполнении) более тоже не имеет шансов быть прочитанным. И уж совсем невероятным кажется мне такое стечение обстоятельств, при котором мне захочется подготовить новый курс практически с нуля -- при том, что для себя я давно уже провёл чёткую черту между прогрессом и потребл$$ством, и 64-битные архитектуры однозначно отношу к этой вот второй категории, как и многоядерности и прочую "мощную" лабуду. Самая мощная машина у меня дома представляет собой Celeron 1.7 с 512 Mb RAM и я не вижу никакого резона для её замены. Вообще, мировую компьютерную промышленность стоило бы законсервировать лет на десять, до тех пор, пока существующие компьютеры не начнут рассыпаться от старости -- именно рассыпаться, а не "морально устаревать". Это, впрочем, касается не только компьютеров, с автомобилями ситуация точно такая же.
А чтобы линукс не тормозил, выкиньте гном и кде. В помойку, где этим жирным уродцам самое место.
Слишком мощные компьютеры, говорите?
А о больших задачах, для которых и несколько тысяч ядер - это мало, о таких вы не слыхали? А ведь вся компьютерная техника для таких задач и создаётся. А домашние компьютеры - это уже побочное производство. Обычный узел суперЭВМ сегодня - это материнская плата с четырьмя двенадцатиядерными процессорами и RAM по два гигабайта на ядро (!). И это только один узел.
Слыхал-слыхал
Мне ваше утверждение о "побочности" домашних компьютеров напоминает старое советское "зато мы делаем ракеты". Это когда всякие "великие стратеги" предпочитают мыслить "великими задачами" масштаба не менее чем БАМ или там разворот северных рек, а об окружающей реальности (типа, скажем, колбасы в магазинах) подумать считают ниже своего достоинства. С таким же успехом можно заявить, что карьерные самосвалы массой не менее 250 тонн — это и есть настоящие автомобили, а всякие там легковые и грузовые машины, а равно и автобусы — это всё побочное производство.
По поводу задач — я и не о таких задачах слыхал, смею вас заверить. А ещё я слыхал (и даже не то что слыхал, а точно знаю), что у нас на ВМК сейчас монтируют зачем-то уже третий суперкомпьютер, при том что первые два ничем полезным не заняты — нечем их занимать. Но дело даже не в этом. Даже если бы эти конкретные машины было чем занять, доля суперЭВМ среди всех имеющихся в мире машин составляет не то что не проценты, даже не тысячные доли процентов, причём даже если считать не машины, а процессоры. Это мизер, не заслуживающий внимания. И доля расчётных задач, требующих серьёзной мощности -- это ничтожная, пренебрежимо малая часть задач, решаемых с помощью компьютеров. А для подавляющего большинства задач, которые решаются на машинах, мощность процессора не нужна совсем, то есть вообще, то есть никак — потому что это интерактивные задачи, ведущие диалог с пользователем. И чтобы процессор не успевал за пользователем, нужно либо чтобы этот процессор был на паровом ходу или там с педальным приводом, либо чтобы программист, который написал программу, был полным идиотом (последнее, к сожалению, встречается очень часто — вот те же браузеры тому пример).
Так или иначе, именно домашние и офисные машины, ну и примкнувшие к ним серверные решения, которым мощность тоже нафиг не нужна, поскольку они упираются не в процессор, а в скорость сети, диска и объём памяти — это и есть основа компьютерной индустрии, а суперЭВМ, производимые в единичных экземплярах, никакой погоды не сделают. Если мощные процессоры нужны для суперЭВМ, то пусть их для суперЭВМ и производят — партиями по несколько тысяч штук, а не по несколько десятков миллионов. Ну, это если бы мир был идеален.
Но поскольку мир не идеален, производители домашних и офисных компьютеров очень хотят продолжать кушать бутерброды с икрой, а для этого им необходимо продавать компьютеров не меньше, чем раньше, а, напротив, всё больше и больше. Для этого есть два способа. Первый — сделать так, чтобы компьютеры быстро ломались. Способ старый и проверенный, но у него есть недостаток — трудно сделать так, чтобы компьютер отработал свои три года, а потом рассыпался. Если сделать его совсем на соплях, то половина компьютеров сдохнет во время гарантии, и тут уже проблемы обеспечены. Соответственно, используют второй способ: сделать так, чтобы компьютеры подвергались "моральному устареванию". Пока работал закон Мура, это получалось само собой. Но вот когда производители процессоров лет семь назад упёрлись в предел тактовой частоты и закон Мура неожиданно для всех захлебнулся, менеджменту железячных компаний пришлось срочно что-то изобретать для сохранения своего места в мире. Инженеры сказали "мы не можем сделать процессор вдвое мощнее", на что манагеры им объяснили, что если они не сделают процессор вдвое мощнее, то будут кушать баланду. Поскольку баланда — аргумент убедительный, инженеры почесали репу и придумали некий протез — два ядра на одном камне, потом четыре, потом восемь... А программисты проприетарных компаний им в этом помогли, создавая год от года всё более и более тормознутый софт и создавая тем самым у конечного потребителя ложное ощущение необходимости перманентного апгрейда. Вот это я и называю потреблядством — не когда удовлетворяются имеющиеся потребности, а когда искусственно создаётся ощущение потребности там, где никакой потребности и рядом не лежало.
Итог всего этого мракобесия в том, что 99,9999% всех процессоров в мире простаивает (ничего не делает) в течение 99,9999% времени, но при этом на изготовление этих процессоров тратится немерянное количество ресурсов, потом на их питание на холостом ходу тратится прорва электричества, и оплата всего этого влетает конечным пользователям в несуразно гигантское количество денег.
Увидел маркетоида — убей его.
Наука и бизнес
А на чём сегодня держится почти любая естественная наука? На реальных экспериментах? Это уже дела давно минувших дней. Ни одна современная производственная и научная задача не обходится без численного моделирования. Погоды, говорите, не делают... Ну, ну... А как появляется техника, к которой мы привыкли, от сотовых телефонов до автомобилей и зданий? На персональном компьютере чертежи рисуют? Всё это моделируют, и для работы в таких сферах в реальном режиме, в режиме рынка, необходимы огромные вычислительные мощности. И никакие ПК, и даже никакое их количество, не смогут заменить современные супер-ЭВМ на производстве. О том как у нас всё простаивает я по-лучше вашего знаю (у нас и не такие машины занимаются не пойми чем), но это свидетельствует только о том, что у нас мозгов не хватает для того, чтобы это эффективно использовать, но уж никак не о том, что это всё не нужно. И то, что в этой области мы как обычно протормаживаем - это наши проблемы (людей), а не прогресса вычислительной техники. То, что у нас обычно всё бестолково используется, это и так понятно, но о бессмысленности роста вычислительной мощности вообще, в принципе - Вы лучше никому не говорите, люди, связанные с реальной наукой, над Вами смеяться будут. Рассуждения, приведённые выше, свидетельствуют о том, что вокруг Вас одни ПК, и с реально большими задачами Вы не сталкивались. Уровень развитости производства напрямую зависит от вычислительных мощностей, доступных инженерам. Да и безопасность страны уже измеряется в терафлопсах и петафлопсах, т.к. ядерное оружие невозможно испытывать, его можно только моделировать.
Для персональных компьютеров, естественно, уже давным давно, во всяком случае в офисах, не имеет никакого смысла весь современный прогресс. Но для тех, например, кто играет в реалистичные игры, производительности процессоров и видео-карт всегда не хватало. Я вот вообще не играю, но компилирую, например, ядро Linux. И как-то удобнее, когда на 4-ядерном процессоре оно компилируется несколько минут, а не несколько дней, особенно если к этому ещё кучу чего компилировать нужно. Вычислительные мощности ощущаются и обычным пользователем в виде моментальности тех действий, которые раньше нужно было ждать, пока выполнятся, и в итоге - в большей комфортности и свободе при работе на компьютере.
А в смысле стоимости и производительности, персональные компьютеры - действительно ничтожная часть по отношению ко всем мировым вычислительным ресурсам. А на маркетоидов не смотрите - если на них обращать внимание - никаких нервов не хватит. Общество потребления выгодно, и его пытаются сделать любыми способами - не получится с компьютерами, будут что-нибудь другое рекламировать.
Когда Вы сажаете рассаду в огороде, вам достаточно лопаты, и уму не постижимым кажется, зачем только делают экскаваторы: столько металла тратят, столько соляры жрёт, и используют его для какого-нибудь ландшафтного дизайна без толку. Но когда Вам нужно будет вырыть котлован для собственного дома - тогда и оцените, насколько это грандиозный инструмент.
Прямо как в том анекдоте
Получается в точности как там — "дядь, а ты с кем сейчас говорил?"
Мне, честно говоря, немного непонятно, зачем столь страстно убеждать меня, что суперкомпьютеры нужны и важны. Я, собственно, не предлагал прекратить производство суперкомпьютеров — если их кто-то покупает, пусть их производят. Я бы только, например, учредил практику проверки обоснованности расходов: если где-то поставили суперЭВМ, а она не задействована, то имеет место очевидная растрата, причём вне зависимости от того, о коммерческой компании идёт речь или о бюджетной. В первом случае впустую растрачены деньги акционеров компании, во втором растрачены деньги налогоплательщиков, но в обоих случаях есть тот, кто получил откат, и этого кого-то стоит, очевидно, посадить известно куда. Ну да это, впрочем, лирика, не имеющая отношения к исходному вопросу. А исходный вопрос тут вот какой. Допустим, я полностью соглашусь с вами по части нужности и полезности суперкомпьютеров (я не собираюсь, на самом деле, с этим соглашаться, но допустим). И как, пардон, из этого следует, что 64-битный 4-ядерный процессор на десктопе у секретарши, которая кроме ворда и пасьянса ничего никогда не запускает, являет собой что-то отличное от потреблядства?
Кстати, ядро линукса и я компилирую, и мне как-то совсем непонятно, откуда вы взяли "несколько дней". На моём дохлом селероне 2.6'е ядра собираются меньше получаса, да и вообще, при чём тут процессор? Львиная доля времени (я бы даже сказал, чуть менее чем всё) при этом тратится на старт и останов gcc, сегмент кода при этом не перезагружается, конечно, но у gcc и сегмент данных нехилый, а самое страшное при создании процесса — это генерация страничных таблиц (а это каждый раз с нуля и без вариантов); и процессор тут вообще ни разу ни на что не влияет, а влияет скорость шины (хрена с два вы её увеличите, скорость света помешает) и скорость обмена с диском (тоже хрена с два что тут можно ждать, упёрлись давно в физические ограничения). Впрочем, ядра бы и быстрее собирались, если бы у тех, кто их пишет (а заодно и у авторов gcc), на столе что-нибудь помедленнее стояло, а то привыкли об эффективности не думать, вот и имеем то что имеем (например, ну они хоть бы make -j работать заставили нормально, а то как не работало, так и не работает, несмотря на то, что в ядре до чёрта совершенно не зависящих друг от друга подсистем). Но вообще-то пересборка ядра операционки — это не та задача, которую часто приходится решать конечному пользователю, да и не только конечному.
Если мне экскаватор потребуется, я вряд ли его покупать стану, и тем более не стану сокрушаться, что мой автомобиль не оснащён соответствующими функциями. Да он мне если и понадобится, то разве что раз за всю жизнь. Уж как-нибудь я с этим одним разом справлюсь. А в повседневной жизни мне нужен автомобиль — не экскаватор и не карьерный самосвал, и даже не болид формулы-1, а обычный автомобиль, чтобы возить мою задницу и мой чемодан. При этом я никоим образом не отрицаю полезности и нужности карьерных самосвалов и экскаваторов, пока их разработка не влияет на свойства моего авто.
Короче говоря, не надо мне рассказывать про полезность суперкомпьютеров. Лучше попытайтесь опровергнуть моё утверждение, которое вы предпочли не заметить: если быстрые процессоры нужны для суперЭВМ, то пусть их и производят для суперЭВМ, и ровно в тех количествах, в которых они нужны на суперЭВМ — то есть десятками тысяч штук, а не сотнями миллионов.
Кстати (припоминая свои знания из области параллельных вычислений и численных методов), процессор общего назначения в роли узла суперкомпьютера — это вообще-то нелепость, не?
Добавил
Добавил отдельным комментарием, а про этот вопрос забыл...
Отвечаю. Естественно, нелепость. Но это можно только теоретически утверждать, а реально, когда строится огромная машина, берут массово производимые и, соответственно, относительно дешёвые (относитено не-массовых), но самые высокопроизводительные процессоры. К тому же, всё ПО поменять под другую архитектуру не представляется возможным.
Но сейчас, как только появилась возможность, начитают отходить от бестолкового использования кристалла процессора, и всё больше используют процессоры SIMD или полу-SIMD архитектуры, в частности, графические процессоры. Самые мощные суперЭВМ уже большей частью своей производительности обязаны процессорам НЕ общего назначения. Но эффективно использовать эту архитектуру намного сложнее.
Ага
Про осваивание LInux для девелопинга
Здравствуйте, господин Столяров. Рекомендуете ли Вы основательное осваивание системы Linux ВМЕСТО Windows для будущего программиста, и насколько полезно изучение конкретной реализации языка ассемблера для Linux - NASM в курсе общего изучения самого языка?
Разумеется :)
Я рекомендую забыть Windows вместе со всеми её вирусами и прочими прелестями как страшный сон, навсегда, и рекомендую это не только программистам. Я вообще не понимаю, как можно всерьёз говорить об использовании системы, в которой бывают вирусы.
Что касается конкретно NASM, то, во-первых, у вас очевидный бардак в голове: какого это "самого языка"? Язык ассемблера — это всегда именно язык конкретного ассемблера, а не чего-то ещё, сколько есть ассемблеров, столько есть и их языков, никакого "самого языка" здесь нет и быть не может. Во-вторых, причины выбора именно NASM подробно изложены в предисловии к моей книжке, повторяться смысла не вижу. А в-третьих, NASM — это ассемблер для x86-х процессоров, а не "для Linux". NASM есть и под виндой, разумеется, ведь сам NASM — это программа на ANSI C, переносимая со страшной силой. Вот только писать под винду (в смысле, оконные приложения) на ассемблере нереально, особенно в рамках учебных задач.
Опровергать
Опровергать тут нечего: всё, что приносит деньги - гипертрофируется, раздувается до безобразия. И вы, почему-то, "предпочли не заметить", что в этом смысле я ничего не опровергаю, а поддерживаю, потому что невозможно опровергать бессмысленность использования современных компьютеров в офисах для набора документов и т.п.
Хотя на самом деле, за то, что мы с Вами имеем возможность иметь у себя на рабочем столе плоды колоссальных научных достижений за совершенно ничтожную цену, мы должны быть благодарны как раз-таки тому, что процессоры продаются "сотнями миллионов", а не "десятками тысяч штук".
Где вы нашли такой make, который не понимает -j? Когда я набирал текст предыдущего поста, в фоне была запущена компиляция gcc командой make -j 4. Это обеспечило почти непрерывную 100% загрузку всех моих четырёх ядер, и соответственное уменьшение времени компиляции, тем более, что современные процессоры знамениты не только своей многоядерностью, но и большим кэшем (причём, это всего лишь недорогой прошлогодний ноутбук). В правильно написанном программном продукте все модули делаются независимыми для компиляции и связываются только по интерфейсам, что позволяет великолепно распараллеливать процесс компиляции. Если бы на это влияли скорость обмена с ОЗУ или внешними устройствами, то 100% загрузки не было бы. А с 512-ю МБ памяти, конечно, не понять, что всё целиком, ОС, системное ПО, компиляторы, исходные и промежуточные данные, и результаты компиляции могут не выходить за рамки оперативной памяти (при достаточном её количестве). К жёсткому диску вообще при компиляции обращений нет, т.к. при распаковке архива с исходным кодом всё это кэшируется в ОЗУ, потом обрабатывается и опять кэшируется, а не сразу пишется на диск. Для не-супервычислений проблема медлительности жёстких дисков перекрывается большой оперативной памятью. А скорость компиляции gcc достигается за счёт эффективности производимого им кода - отключить оптимизацию, и компиляция будет летать. Но только жертвовать приходится чем-то одним - либо скоростью компилирующего, либо скоростью компилируемого.
Компилируют не многие, но играю почти поголовно. С видео работают уже многие, т.к. цифровые камеры - не редкость.
Кстати, в былые времена доходил до такого маразма, как написание на ассемблере под Windows, поэтому могу отметить, что это вполне реально. Загляните на www.wasm.ru. Правда, NASM там не в моде...
Вы читать-то вообще умеете или как?
make -j, разумеется, работает и всегда работал, я иного и не утверждал, тем более что реализуется это -j совершенно очевидным образом (достаточно представить себе граф зависимостей, который строит make). А утверждал я другое: если бы кого-то волновала скорость сборки ядра Linux, его можно было бы собирать через make -j (и без всяких промежуточных make deps), плюс к тому его можно было бы не пересобирать с нуля при каждом изменении конфига, а делать, как это принято в нормальных проектах, обычный make, который пересобирал бы лишь то, что нужно, и перелинковывал всю махину (последнее происходило достаточно быстро даже на 386-х). Что gcc собирается с make -j -- это я не удивлён, так и должно быть. Удивляет как раз то, насколько наплевать на скорость сборки своего детища авторам линуксовых ядер.
Далее, "не выходить за ОЗУ" -- конечно можно, и очень даже понятно, но, во-первых, для сборки того же ядра Linux, чтобы вообще не лазить к диску, потребуется тогда гигов 16 памяти (я деньги лучше пропью и потерплю раз в год, что оно собирается полчаса), а во-вторых, память находится _за_ шиной. Кроме того, построение страничных таблиц каждый раз при запуске процесса, собственно говоря, от диска никогда не зависело, оно всегда происходит "не выходя за RAM", что никак не отменяет его чудовищной ресурсоёмкости. Ergo, 64-разрядность и многоядерность процессора вам ничем не поможет. Ну, почти ничем.
Что играют поголовно - я вот тоже не играю. А из периода 286-х машин сохранил нежные воспоминания о симуляторе f-19, который нормально работал на XT с 640 Kb RAM (прописью: 640 _кило_байт) и CGA (4 цвета), а на убогой 286й летал как я даже не знаю что. Более реалистичного флайт-сима я с тех пор не видел, зато нынешние монстры на 512 Mb даже запускаться не хотят. Это замкнутый круг: железячники гонят процессоры и память, софтверщики (язык не поворачивается их программистами называть) гонят всё более и более монструозные и тормознутые приложения.
Про массовые тиражи процессоров — а я и не спорю, что это хорошо, когда массовые процессоры идут большими тиражами, что снижает их стоимость. В качестве мракобесия, подлежащего искоренению, я считаю из пальца высосанное "совершенствование" процессоров для массового потребителя, которое должно было остановиться лет семь назад (кстати, процессоры нынче стоили бы ещё дешевле, если бы это всё ещё были селероны или на худой конец P4).
Ну и последнее, про "нормальные продукты" -- вот то-то и оно, если дальше гнать процессоры, скоро нормальные продукты писать никто не будет. Не останется людей, которые это умеют. Впрочем, гнать дальше уже не получится, предел технологии по процессорам, к счастью, достигнут (многоядерность - это уже жизнь после жизни), плюс к тому несколько обнадёживает появление netbook'ов, всё-таки у кого-то хватило здравого смысла. Подозреваю, что логическим завершением всего этого мракобесия станет появление коробочки размером с пачку сигарет с дырками для монитора и USB (ненавижу USB, но вряд ли оно куда-то денется), на которой работает какой-нибудь OpenOffice, которая не ломается в принципе, за отсутствием трущихся частей, а стоит пять баксов. Надеюсь, после этого компьютерная индустрия всё-таки сдохнет.
Бесконечно
Бесконечно далеки Вы от настоящей компьютерной индустрии... Я бы тут и высказываться не стал, если бы не увидел, что к обучающим материалам, какими являются Ваши книги, прилагаются такие странные комментарии. Процессоры естественно развиваются, и что же удивительного в том, что предназначенное для решения больших вычислительных задач пытаются под любым предлогом продать как можно большей аудитории? Если бы компании, производящие процессоры и вообще ПК, не зарабатывали бы на поставке сверхбессмысленно мощных компьютеров в офисы и обычным пользователям, то ни о каком развитии технологического процесса, ни о сверхэкономичных процессорах, netbook-ах, коробочках за пять баксов - речь ещё долго не шла бы.
Меня то как раз и удивляет такое безграмотное отношение к этому вопросу, как будто все, кто создают компьютерную технику и ПО - это идиоты. И, что ещё более удивительнее, все, кто пишут ядро Linux - тоже чего-то не додумали. А вам не кажется подозрительным, что gcc позволяет параллельную компиляцию, а ядро Linux нет? Это потому что тысячи программистов туповаты, или же всё-таки в этом есть какой-то смысл? Так вот в серьёзных книжках по этому вопросу поясняют, что при компиляции самого главного, что работает на компьютере и управляет всем остальным, необходим полный контроль за последовательностью компиляции и достоверность того, что будет на выходе, чего параллельная компиляция в полном объёме не даёт.
Насмотревшись на Windows, другие продукты Microsoft, политику Intel, и развитие ширпотребных компьютеров начинает везде чудиться обман, избыточность, неэффективность, бессмыслица. Мой совет похож на Ваш (см. выше) - выбросить всё это из головы, и искать рациональность в серьёзных вещах. Linux, как и многое другое базовое свободное ПО, пишут гениальные программисты, и упрекать их в непрофессиональности и не стремлении к эффективности - это только самому позориться. А на самом деле эффективно использовать современную компьютерную технику могут только настоящие учёные.
Смешно, да
Бесконечно далеки Вы от настоящей компьютерной индустрии...
К счастью, да — далёк, причём удалился я от индустрии вполне намеренно, когда понял, на что она похожа.
Правда, очень забавно слышать подобные заявления в свой адрес от человека, который начал (и, судя по всему, на полном серьёзе) с утверждения, что-де только суперЭВМ и есть настоящая индустрия, а всё остальное — побочное производство.
Процессоры естественно развиваются
Естественное развитие процессоров для ПК закончилось около семи лет назад, с выходом P4 и его аналогов. Всё, что было после этого, никакого отношения к естественному развитию процессоров не имеет; многоядерные процессоры, как я уже говорил, представляют собой классический пример потреблядства и являются результатом маркетоидских игрищ, а не технического развития.
Если бы компании, производящие процессоры и вообще ПК, не зарабатывали бы на поставке сверхбессмысленно мощных компьютеров в офисы и обычным пользователям, то ни о каком развитии технологического процесса, ни о сверхэкономичных процессорах, netbook-ах, коробочках за пять баксов - речь ещё долго не шла бы.
Это опровергается одним примером: Cray. Компания, создававшая лучшие в мире суперкомпьютеры и ничем другим, никаким офисным потреблядством никогда не занимавшаяся. И работавшая до тех пор, пока её маркетоиды не уничтожили.
Но, на самом деле, в вашем утверждении системная ошибка гораздо глубже. Утверждение о том, что-де коммерческим компаниям нужны деньги, чтобы изменять мир к лучшему — это очень популярный миф, его можно услышать и в применении к автомобильной индустрии, и, скажем, в применении к так называемым звукозаписывающим компаниям (дескать, мы заработанные деньги используем для поиска и раскрутки молодых исполнителей, а пираты нам мешают, из-за них у нас нет денег), да и вообще везде, где есть коммерция. Люди в целом не очень любят, когда на них наживаются, поэтому коммерсанты при любой возможности пытаются создать у публики ощущение собственной полезности. В действительности коммерческая компания есть, по определению, компания, единственной целью деятельности которой является извлечение прибыли, никаких иных целей у них нет и быть не может, не потому, что они "плохие", а просто таково определение слова "коммерческий".
Чтобы проиллюстрировать действительный эффект от финансовой мощи тех, кто продаёт в офисы четырёхядерные компьютеры, я вас вот о чём спрошу. Где, простите, процессоры Alpha? И сама компания DEC? И где, простите, Sun Microsystems и её SPARC? И остальные архитектуры, не имевшие отношения к Intel? Выжил в итоге самый идиотский из всех имевшихся в наличии процессоров — причём его создатели сумели заработать достаточно денег, чтобы купить и уничтожить всех перспективных конкурентов. Это вы называете техническим прогрессом?
Я бы сказал, что очень важно понимать опасность этого вот мифа о том, что у коммерческих компаний есть какие-то полезные цели. Просто исходно мир был устроен так, что заработать деньги можно лишь принеся кому-то пользу. В области малого бизнеса это до сих пор так. В области крупного бизнеса это не так вот уже примерно полтора столетия.
Так вот в серьёзных книжках по этому вопросу поясняют, что при компиляции самого главного, что работает на компьютере и управляет всем остальным, необходим полный контроль за последовательностью компиляции и достоверность того, что будет на выходе, чего параллельная компиляция в полном объёме не даёт
Сие есть гуманитарный бред, не имеющий отношения к технике. Ядро — это такая же программа, как и любая другая, и к ней точно так же применимы принципы построения зависимостей. Если бы кого-то так сильно волновала конкретная последовательность сборки, загружаемых модулей бы уж точно не было.
Иной вопрос, что конфигурация ядра записывается в один большой файл; результатом этого становится зависимость буквально всего, что там есть, от этого одного файла и категорическая невозможность построить настоящий граф зависимостей. Можно это переделать? Можно. Но потребует серьёзных усилий. А зачем, если оно и так за четыре минуты собирается?
Linux, как и многое другое базовое свободное ПО, пишут гениальные программисты, и упрекать их в непрофессиональности и не стремлении к эффективности - это только самому позориться
Да неужели? Ну, ядро, допустим, в основном пишут действительно гениальные люди, и некоторых из них я даже лично знаю. Что никоим образом не отменяет того факта, что все программисты — люди, во-первых, ленивые, а во-вторых, всегда могут себе найти другое занятие, нежели переделывать систему сборки ядра. Наконец, в-третьих, от одних людей, имеющих прямое отношение к ядру Линукса, я слышал весьма нелестные отзывы о других людях, имеющих отношение туда же, как и обо всём проекте в целом (в частности, про ядро 2.6 при его появлении я слышал буквально следующее: всё это всё меньше похоже на Unix и всё больше похоже на Win NT).
Что касается другого программного обеспечения — знаете такую программу /bin/true? Ну вот запустите её под strace'ом и посчитайте, сколько она делает системных вызовов. Я тут 103 насчитал. Мораль: основная юзерспейсовская библиотека — та самая GNU libc — сейчас представляет собой монстра, негодного к использованию, но которым продолжают пользоваться, потому что всем всё пофигу. То есть если ещё про "ядерщиков" и их гениальность я соглашусь, то команда Столлмана моё уважение потеряла давно и прочно. Ну то есть самого RMS я безмерно уважаю как политика и пропагандиста, но как программиста-профессионала — увы (в особенности после его ответа на мой вопрос об отношении к C99; в шоке был не только я, но и половина аудитории).
Где-то мне статья попадалась на эту тему (не смог сейчас найти, к сожалению), там автор сделал весьма поверхностный code quality review нескольких известных проектов, которыми миллионы людей пользуются, и сделал весьма неутешительные выводы. Что-то вроде "вы думали, серьёзные программы пишут боги? увы, это такие же люди, как и вы, причём часто гораздо хуже вас подготовленные; причём это ещё open source, а что творится внутри проприетарных проектов, остаётся только догадываться".
upd Вот, набрёл-таки снова на этот текст: http://corte.si/posts/code/reading-code.html Рекомендую весьма :) очень полезно для избавления от розовых очков.
А на самом деле эффективно использовать современную компьютерную технику могут только настоящие учёные.
Современную компьютерную технику эффективно использовать не может никто, потому что это невозможно. А эти ваши настоящие учёные (во всяком случае, в России) поголовно винду гоняют, какое там к дьяволу эффективное использование.
Не удается скачать кнги по nasm.
При переходе по ссылке для скачивания появляется соообщение "Страница не найдена." Книги были убраны из свободного доступа?
Исправлено
Там перемудрили с настройками drupal. Сейчас вроде всё нормально.
Благодарю!
Благодарю!
FPU
Планируется ли добавление в пособие информации о FPU? Я понимаю что в i386 он был еще в виде сопроцессора, но где-то с i486 появился в самом процессоре, а пособие же не строго по i386?
Уже есть
Во втором издании про FPU целая глава, хотя и не очень большая (см. стр. 166--181). В первом издании этой главы не было из-за, во-первых, жестких ограничений по объёму книги (в МГТУГА не умеют издавать ничего кроме брошюр) и, во-вторых, из-за того, что на лекциях в МГТУГА я этот материал всё равно не успевал прочитать. Самая первая версия моего курса, прочитанная в Ташкенте, этот материал содержала.
FASM vs NASM
Только без холивара, вопрос что лучше для написания кода для биоса FASM или NASM ? один советует одно, второй советует другое.
Хочется услышать мнение как специалиста
Какой там холивар
Сказано же в явном виде (у меня в предисловии), что выбор между этими двумя ассемблерами в моём случае был сугубо случаен. Не могу я посоветовать ни тот, ни другой, и вообще я FASM только издали видел.
Гм... вообще-то я бы сказал, что лучше это делать на Си, а не на асме; жизнь коротка, знаете ли. Уж если микроконтроллеры можно программировать на Си, то полноценный комп (пусть даже имеется в виду его биос) -- тем более. На асме стоит, видимо, сделать только обёртку с точками входа, один маленький файлик. А всю функциональность лучше всё-таки на Си.
Спасибо
Спасибо большое за хорошую книгу. К сожалению, это большая редкость - книга по ассемблеру для юникс. Однако, хочу присоединиться к предыдущим комментаторам и сказать, что все-таки очень не хватает описания ассемблера для х64. Каково бы ни было Ваше отношение к современным тенденциям, это реальность, к тому же реальность востребованная самыми разными людьми, и не только для игр. Я занимаюсь моделированием физических процессов в атмосфере, и использование больших объемов памяти дает мне немалый выигрыш в скорости расчетов. Нет у Вас планов сделать что-то в виде приложения к уже изданной книге?
Еще один вопрос интересует - устройство позиционно-независимого кода. Если для х86 все более или менее понятно (есть довольно подробная информация в мануале NASM), то про х64 полное молчание. Может, Вы посоветуете, где можно почитать?
Пожалуйста
Реальность -- это то, что реально происходит. В мою реальность 64-битные машины не проникли и ещё долго не проникнут, поскольку для имеющихся задач мне это не нужно. Чтобы написать книгу по ассемблеру для x64, мне для начала придётся купить соответствующий компьютер, потом потратить уйму времени на изучение новой архитектуры, и ничего взамен не получить кроме сомнительного морального удовлетворения. Так что ответ на ваш вопрос, собственно говоря, уже был дан в комментариях выше, и остаётся прежним: нет, я не буду заниматься 64-битными архитектурами, и их описание не входит в мои планы ни в каком виде. Ну разве что произойдёт чудо и найдутся идиоты, готовые создание такой книги профинансировать, причём не по договору авторского заказа (такой я не подпишу, противоречит убеждениям), а в порядке спонсорско-грантовом. Но поскольку чудес не бывает, идиотов таких не найдётся.
Что касается моделирования физических процессов в атмосфере, то здесь, я полагаю, язык ассемблера вообще никак и низачем не нужен: пишите лучше на Фортране, или на Си, или ещё на чём-то, но уж никак не на асме. Это бессмысленная трата времени, по быстродействию вы всё равно не переплюнете существующие математические библиотеки, да и если и переплюнете, то разве что на жалкие проценты; а жизнь коротка.
Пишу,
Пишу, естественно, на С со всякими OpenMP и прочее, но некоторые небольшие функции оптимизировал на ассемблере. При этом была ощутимая отдача в продуктивности. Еще раз спасибо за книгу.
Обсуждение книги
Здравствуйте! Заинтересовался Вашей книгой, в данный момент изучаю. Сам я,конечно, "страшно далёк от народа", не могу аргументированно возразить ни Вам, ни Вашему сопернику, да и нужды в этом нет. Вы - консервативен,минималистичен,реален(в своём мировоззрении), он - наоборот, максималист. Я не могу не согласиться, что "сегодняшние" программисты всё чаще и чаще используют шаблонный подход ко многим задачам, здесь есть и плюсы и минусы. С одной стороны - зачем изобретать велосипед, можно использовать готовые библиотеки и модули,вызывая их десятки и сотни раз в своих программах, облегчая себе задачу и, неминуемо, раздувая общий "вес" программы в целом.Но при этом, однако, теряется оригинальный подход к делу, возможно, потенциально более рациональное решение.Иными словами - застой в более продуктивной реализации программного продукта, но выигрыш в стабильности, проверенности, скажем так. Хотя, не всегда то,что является старым и проверенным на деле ВСЕГДА оказывается правильным,как потом выясняется. Понятие "правильности" относительно и актуально лишь на определённый момент времени, возможно потом окажется "более правильным" иной подход. Но и с другой стороны: если бы мы использовали строго консервативный подход к модернизации имеющегося у нас оборудования (железа), и выжимали из него буквально всё, заставляя программистов потеть для более оптимального решения (составления программы) тем самым повышая их профессиональный уровень - мы так бы до сих пор,наверно, сидели за 8-ми разрядными процессорами типа КР580ВМ1 или Z80 (Zilog) c 64 кБ памяти на борту, а иногда и того меньше, и пытались бы подогнать наши существующие потребности под эти "габариты". А вообще тему, которую Вы затронули, можно развивать до бесконечности и я просто признателен и Вам, и Вашему оппоненту , и всем тем,кто действительно пытался обсудить данный вопрос именно "по делу", а не быть безразличным ко всему происходящему, каким, увы, является очень большой процент современной молодёжи.Но повторяюсь, ни возразить, не поддержать я никого не могу, ибо "выпал из колеи" современного развития компьютерной индустрии лет эдак 20 назад. Я раньше занимался программированием на языке ассемблер под процессоры Z80 для пк ZX-Spectrum ( Zeus assembler), поэтому все мои теперяшние познания в программировании практически равны 0. Но всё равно сел вот за книги (ваши в том числе).Я не считаю, что программирование на чистом ассемблере является нецелесообразным. Всё в мире относительно. Для меня, допустим, интересна ОС Колибри, написанная на чистом FASM,многозадачная,перспективная ОС. Вы скажете: это несерьёзно, у этой ОС нет будущего, что я дилетант, и этой операционкой занимаются дилетанты.Возможно в чём-то и будете правы,Вам виднее как опытному программисту. Но вспомните, ведь и ядра Linux бы не появилось в своё время, и FREEBSD, все работали бы и модифицировали UNIX. Я благодарен и Вам, и всем тем, кто освещает подобные "редкие" темы, кто не стоит на месте и пытается двигаться вперёд, а не просто сидит у экрана монитора с отвисшей челюстью, гоняет GTA или World Of Warcraft и тупо рассуждает на тему " Мой комп тупит, надо побольше оперативы,проц побестрее, сборку винды получще (экстрим там или зверька ) и всё пойдёт ок". Поверьте, ужасно слышать такие суждения, причём это происходит всё чаще и чаще. Удачи Вам! Спасибо за книгу.
Комментарий
Для начала дам небольшой совет (знаю, что непрошенный, но уж раз пришли — :-) ) -- ознакомьтесь с правилами сочетания пробелов и знаков препинания. Ну вот хотя бы здесь: http://www.proza.ru/diary/drcroco/2011-09-10
Ну а по существу... мне сложно что-то ответить, вы мне приписываете тезисы, которых я не выдвигал, и аргументы, которых я не произносил, как мне тут что-то отвечать? Вот та же колибри -- у неё действительно нет перспектив, но отнюдь не потому, что она маленькая и шустрая, а потому, что всё написанное на асме привязано к конкретному процессору и от него зависит, вон через два-три года окончательно забудут про i32, будет везде эта вот 64-битка (у меня она тоже рано или поздно появится, хотя и не раньше, чем стоимость б/у системного блока упадёт до ста баксов), но это ещё полбеды, а если Intel совсем загнётся? Например, его ARM начнёт всерьёз теснить? Ведь язык Си появился, когда Кену Томпсону стало лень переписывать Unix под уже третью архитектуру. "Старое и проверенное", знаете ли, я тоже никогда не считал истиной в последней инстанции -- про заведомую негодность существующей Glibc, заметим, именно я упомянул.
Я вот тут недели три назад запустил F-19 в dosbox'е. Dosbox -- это интерпретатор старого машинного кода, то есть работает он ну оооооочень медленно, но F-19 когда-то летал на IBM XT с CGA-монитором (говорю на собственном опыте: я сам в него играл на XT), так что в dosbox'е на моём дохлом celeron'е чувствует себя просто замечательно. Современные игрушки требуют ресурсов в десятки тысяч раз больше, а стали ли они от этого доставлять пользователю больше кайфа? Супер-пупер-графику и всё остальное, на что уходят ресурсы, пользователь перестаёт замечать через пять минут. Это я к тому, что да, не умеют нынче программы писать эффективно; только ассемблер тут, извините, ни при чём. Эффективность программ на Си -- если их писать правильно -- в большинстве случаев оказывается _выше_. "Внезапно", как сейчас модно говорить.
Спасибо за
Спасибо за совет. Учту на будущее.
У меня к Вам есть вопрос по поводу реализации алгоритма временной задержки (таймерной привязки) для процессоров семейства i32, но, скорее всего, это уже частный вопрос, не относящийся к теме. Если у Вас нет времени, или нет желания на всё это -- отпишитесь пожалуйста (на сайте , или на мой почтовый ящик: [email removed]). С уважением, Юрий.
Удачи!
К сожалению,
К сожалению, готового ответа у меня нет, а исследовать вопрос действительно нет времени совершенно.
Без розовых очков...
...И где, простите, Sun Microsystems и её SPARC?...
SPARC, простите, вот здесь, в первой строчке TOP 500, в суперкомпьютере производительностью порядка десяти петафлоп. Но о задачах, для которых и такой производительности будет мало, Вы, наверное, даже и не слыхали...
А по поводу качества linux-ПО: ну не стоит, в самом деле, считать, что миллионы людей вокруг - идиоты, один Вы всё правильно понимаете. Особенно среди людей, которые не ради заработка шлёпают "поделки".
Знаете ли, для скольких архитектур процессоров существует дистрибутив ПО под общим названием Debian?
Попробуйте написать программу, а лучше - несколько десятков тысяч программ разной сложности, которые почти в полном объёме переносимы на десяток совершенно разных архитектур. Тогда поймёте, что та сложность, которая присутствует даже в самых простых, но универсальных, переносимых (и т.п.) программах - это минимально возможная сложность, ошлифованная и оптимизированная многими программистами в течении многих лет.
А чтобы направить свой антиглобалистский пыл в правильное русло, советую почитать серьёзную литературу по философии Unix/Linux, например, шикарную книгу "Искусство программирования для UNIX" (Эрик С. Реймонд), из которой вы узнаете, в чём конкретно принципы проектирования большей части коммерческого ПО противоположна философии UNIX.
Пять минут смеха продлевают жизнь на сутки
Ситуация, ей-богу, начинает меня забавлять. Я уж думал, вы сдулись, но ни фига — таки припёрлись опять, причём только для того, чтобы вывалить толпу «аргументов», содержательная ценность которых приблизительно равна сакраментальному утверждению «сам дурак». У вас по существу-то есть что возразить? Ну а пока вы об этом думаете, проведём работу над ошибками.
Насчёт спарков: ну опять вы со своими ракетами. Не волнуют меня суперкомпьютеры, и в особенности меня не волнует top500, представляющий собой бессмысленное мерянье пиписьками, исполняемое, что несколько обидно, за чужой счёт (иногда, замечу, и мой счёт, я ведь тоже налоги плачу). Попадание в верхние позиции top500 означает ровно одно: у кого-то нашлось больше лишних (при этом чужих) денег, чем у других. Вы вот мне скажите, где мне сейчас купить десктоп на спарке, чтобы его на стол поставить, взгромоздить на него тот самый Debian (NB: разумеется, я знаю, на скольких платформах он работает; я, знаете ли, с Linux работаю с 1994 года, а с 1997 — только с ним; больше того, можно было бы заметить, что я и в проекте Openwall участвую, и не только в нём) — так вот, взгромоздить и использовать в качестве рабочего инструмента заместо этого идиотского интела. Что до задач — NASA человека на Луну запустила, обладая совокупной вычислительной мощностью в разы меньшей, нежели мощность современного мобильника. Если программы писать через... ээ... короче, если их как попало писать, то вам любого суперкомпьютера окажется мало. А этот ваш первый в top500 жрёт почти 13 мегаватт, то есть он за месяц одного электричества съедает на сумму, приблизительно соответствующую стоимости строительства многоквартирного дома. Меня это обстоятельство интересует гораздо больше, чем те прожорливые модели, которые на нём обсчитываются.
Писать переносимые программы я не только «пробовал», я много раз это делал, причём мне приходилось писать программы, переносимые между *nix'ом и виндой — это посложнее будет. И я на собственном опыте знаю, что при аккуратной работе и разборчивости в выборе библиотек все проблемы переносимости решаются парочкой #ifdef'ов. При этом я неоднократно (уже в роли майнтейнера пакетов для того же Openwall/*/GNU Linux) сталкивался с подельями идиотов, взявших на вооружение GNU automake/autoconf и сделавших в итоге так, что их ./configure сам по себе зависит от бОльшего количества внешних условий, чем основная программа. То есть средство, которое должно бы по идее обеспечивать переносимость, в итоге само оказалось основным источником _не_переносимостей.
Миллионы людей вокруг, как это ни печально, действительно идиоты, идиоты вообще преобладают. Среди программистов идиотов меньше, чем «в целом по больнице», но и тут их более чем хватает, и сто три системных вызова, выданные программой, которая по сути своей должна была бы состоять из трёх машинных команд — тому подтверждение (кстати, опять же — по существу есть что сказать на эту тему? Или вы всерьёз полагаете, что 103 вызова в исполнении /bin/true — это нормально?) Но идиоты идиотами, а с чего это вы решили, что я «один»? Между делом, круг моих знакомств среди людей, имеющих прямое отношение к ядрам и дистрибутивам, тоже можно было бы достаточно легко установить — ссылки есть прямо здесь на сайте, да и на гугле никого пока не забанили. Не, ну ладно, вы вот другое скажите: вы пробовали когда-нибудь читать исходники glibc? Я пробовал. Эти люди мне бы зачёт не сдали со своим кодинг стайлом (как они сами ЭТО читают — для меня вопрос открытый). А ещё мне как-то раз пришлось в GNU tar добавлять лишнюю опцию, так я туде тоже занырнул. И сходу нашел супер-конструкцию: парочка не-статических функций в модуле (не только не статических, но и вынесенных в хидер), которые реально вызываются только из статических (!) функций того же модуля. Причём всё это было обнаружено при попытке пофиксить два предупреждения компилятора. Мой отчёт по этому поводу можно вот тут, например, посмотреть: http://permalink.gmane.org/gmane.comp.gnu.tar.bugs/3124 Что такое GNU tar, насколько плотно оно используется — объяснять надо? И что можно сказать о таких вывертах в официальном релизе? (NB: я вообще ничего специально не искал, это был мой первый и последний опыт правки мейнстримовых программ — и сходу вот такое).
Книжка Реймонда — она ничего, да (хотя утверждение о том, что pipe — механизм устаревший, поскольку есть сокеты, мне глаз резануло в своё время весьма и весьма). Пару раз я её уже читал, перечитывать в третий раз, пожалуй, всё-таки не стану, некогда. Кстати, вы могли бы и заметить, что в моей книжке 2006 года издания имеются ссылки и на Реймонда, и на Стивенса, и на Танненбаума (хотя его я не люблю, он вечно пишет не о том), и на Торвальдса. Но за язык никто не тянул: берём с полки Реймонда и читаем главу 20. Лучше с карандашиком. Хотя что-то мне сдаётся, что вы сами Реймонда если и открывали, то ни хрена там не увидели.
Но самое занятное, конечно, что вы меня антиглобалистом назвали — вот тут я, извините, долго ржал. Я вообще-то либертарианец, а либертарианство и антиглобализм несовместимы принципиально. Опять же, мою принадлежность к либертарианцам можно было бы установить прямо тут, вот на этом же сайте, из текста вот этого вот сборника. Тьфу.
Да, так вот — мы с вами что-то в неравном положении. Вам про меня известно практически всё — можно легко простым поиском узнать моё имя, возраст, квалификацию, место работы, список публикаций, информацию об участии в разных проектах и всё прочее (если вы этого ещё не сделали, то это исключительно ваши проблемы), но вот мне про вас неизвестно вообще ничего, кроме имени. При этом вы тут пальцы гнёте, что я якобы о том не слышал, того не видел, этого не читал, того не делал, сего не пробовал (хотя я и видел, слышал, и делал, и читал, и пробовал) — а вы сами-то чем можете похвастаться? Основания для пальцовки есть? Или кроме пальцев ни хрена за душой? Пока что от ваших постов впечатление именно такое.
Отправить комментарий