Легенда об ассемблере
Я смотрю об ассемблере (вероятно речь идёт про ассемблер для Intel x86) легенды слагают:
Наиболее продвинутые ассемблеры содержали такие фишки, как имитация стека и вызова функций, а наиболее продвинутые программисты умели этими фишками пользоваться.
Стек в ассемблере есть — команды PUSH/POP, вызов функции — CALL, возврат — разнообразные RET. Никакой имитации.
Однако, ассемблер был низкоуровневым языком: в нем отсутствовали даже такие элементарные команды, как умножение и деление, которые разработчикам приходилось описывать вручную с помощью низкоуровневых команд.
Умножение и деление: MUL и DIV (есть ещё IMUL и IDIV), умножать и делить можно 32-битные числа, если нехватает, идёт к математическому сопроцессору, он встроен со времён 80486.
Поэтому, на смену ассемблеру пришли языки высокого уровня. Ассемблер при этом физически никуда не делся — все программы на высокоуровневых языках компилируются во все тот же ассемблерный код. В уродский неэффективный ассемблерный код.
Не поэтому, почему — отдельный вопрос, но вовсе не потому, что было мало ассемблерных библиотек для реализации каких-то распространённых вещей. А программы компилируются не в «уродский неэффективный ассемблерный код», а в машинные коды.
Может, они о более древних временах? ^_^
(Когда я на «Спектруме» программировал — там с умножением плохо было. О_о)
Мда, Хабр по-прежнему доставляет...
На редкость бестолковая статья ни о чем.
Комментарий для bakabaka.livejournal.com:
На «Спектруме» был встроенный язык калькулятора. Его можно и нужно было использовать для математике.
Комментарий для nathrezim.livejournal.com:
Одна банальная, очевидная мысль и куча спорной воды.
Комментарий для bakabaka.livejournal.com:
Подробнее о калькуляторе «Спектрума» (это софтварная эмуляция сопроцессора) можно почитать у Toni Baker «Machine Code Calculator» ( http://www.users.globalnet.co.uk/%7Ejg27paw4/type-ins/zx-comp/mccalc.zip ).
Впрочем, я не на тот вопрос отвечаю. Думаю, что автор статьи вряд ли говорит о древних временах. Там контекст другой.
Ну да.
С остроумным пятибайтным представлением чисел :-)
(Хотя, если результат умножения за 2 байта не выходил, число оставалось целым, да ^_^)
Комментарий для bakabaka.livejournal.com:
Но был же! В любом случае, автор, судя по всем, рассматривает всё-таки ассемблер Intel x86.
Если быть совсем точным, то 486DX
486SX не имел встроеного математического сопроцессора.
Человек пришет такую херню и не стесняется, а у поста тем временем уже +75.
«Уродский, неэффективный, ассемблерный код». Как они не умирают при рождении?
«Неэффективный» — это супер. Куда уж прямому программированию процессора до аццких Ява машин по скорости то.
Легенды именно так и рождаются: молодые дилетанты берутся пересказывать что-то, случившееся ещё до их инициации, а седым гуру лень объяснять им как всё обстоит на самом деле.
Комментарий для bakabaka.livejournal.com:
Эх, Спектрум...
В замечательном журнале ZX-Ревю очень любили, помнится, публиковать различные варианты процедур, перемножающих содержимое регистров B и C и сохраняющих результат в паре DE. Процедуры писались на ассемблере (разумеется) и присылались читателями просто пачками. Вот там была оптимизация: экономился каждый байт и каждый такт.
Ностальгия... =)
Если честно, сама статья -- shit.
Комментарий для muxa-ru.livejournal.com:
Насколько помню, SX — это был DX, но с дефектным (и отключенным) математическим сопроцессором, т. е. он там был ;)
Комментарий для jankkhvej.blogspot.com:
Надеюсь, ему там в комментах навешают, мне туда ходить не хочется.
Комментарий для nathrezim.livejournal.com:
Ох, да. Мы с братишкой тоже туда пару писем писали: всякие там бесконечные жизни и адаптации игр: у нас на компе из-за русского шрифта некоторые игры не шли, так как вектор прерывания таймера вычислялся очень хитро(-жопо), адрес, куда передавалось управление, жил в ячейке, адрес которой записывался так: старший байт адреса в специальный регистр, младший брался из определённого порт (который выдавал 255). Соответсвенно, часто практикой было выставлять старший байт так, чтобы он указывал в ПЗУ, если ПЗУ было изменено (а у нас там был русский шрифт), то вектора указывали не туда, куда расчитывал автор и ничего не работало.
Другой проблемой были машины, где упомянутый порт выдавал не 255, а другие цифры (например, в каких-то машинах там был 0, в других — 254). Какие были времена :) Ужас :)
Комментарий для aire.livejournal.com:
Со мной говорит плюшевая игрушка!!!11
Комментарий для Евгения Степанищева:
На самом деле вопрос во что компилируется программа на языке высокого уровня — сложный. Сейчас многие (некоторые?) кодогенераторы выдают действительно ассемблерный текст, который потом скармливается системному ассемблеру. Взять хоть тот же gcc для примера
freepascal компилирует именно в ассемблер, остальное делает gas.
бывает и так
Чудя по всему, во всём остальном автор тоже не разбирается. Про ASP.Net бред пишет.
В уродские неэффективные машинные коды ;-)
Я «изучал» асм на Электронике 580. Там не было никаких MUL и DIV, а тем более IMUL & IDIV...
P.S. Не могу оставить тут сообщение с логином Gmail =/
Комментарий для ajojo.livejournal.com:
У меня большие сомнения, что автор говорит именно об этом. Но спасибо за замечание, правда раньше то, что переводило программу из одного языка в другой называли трансляторами, видимо терминология сменилась.
Комментарий для altmind.livejournal.com:
Я тут подумал, что если для пользователя это более-менее монолитный процесс, то это всё-таки компиляция в машиные коды, пусть и в два прохода. Например, Turbo Assembler, которым я пользовался давал мне сначала obj-файл, которым потом другой утилитой переводился уже в полноценный exe или com, но в голову мне не приходит говорить, что tasm — транслятор ассемблера в объектник.
Комментарий для sad-wind.ya.ru:
А про Asp.NET там что (я не разбираюсь)?
Комментарий для merkushin.ya.ru:
Gmail, похоже, пора откручивать, не работает.
Я предполагаю, что человек говорит о Intel x86. Я за свою жизнь программировал на трёх ассемблерах. В двух действительно не было операций деления и умножения (в Z80 — не было, а по поводу процессора Радио-86РК могу заблуждаться, 18 лет прошло).
Конечно, есть вероятность, что он как раз говорит о каких-то совсем древних ассемблерах, но по другим ляпам в статье создаётся ощущение, что человек либо совсем статью не продумал, либо о многом знает лишь понаслышке.
Комментарий для Евгения Степанищева:
Под вечер дня ему там навешали, ага:
«Машинный код в общем случае — родной язык процессора. В случае с PC это ассемблер. Теоретически возможны процессоры с нативным кодом другого порядка. В бинарных файлах он содержится не в виде команд, а в виде 16ричных чисел, которые и означают эти команды(буквенные mov, cmp, xor — по сути мнемоники для человека), достаточно открыть файл 16риным редактором и переключиться в режим ASM. Ну и порадуйте себя, почитайте про форматы исполняемых файлов PE, ELF…»
Недавно, кстати, freebsd.org открыла официальный форум — списки рассылки и IRC не устраивают текущее поколение. Ожидаем доставки эпических легенд.
Комментарий для jankkhvej.blogspot.com:
По спискам рассылок и IRC я бы не стал плакать. Народу всё больше, среда, соответственно, тоже меняется, это неизбежно.
У IBM/360 не было аппаратного стека и умножения с делением. А это вся советская серия ЕС-ЭВМ. У PDP-11 была наишикарнейшая система команд с могучей косвенностью (отсюда ноги легенд про извращения со стеком) и тоже без mul/div. Это, соответсвенно, вся советская серия СМ-ЭВМ. У современных ARM’ов тоже веселая система команд... Похоже, хабраписатель тупо соорудил компилят по принципу «слышал звон...»
Комментарий для imap.livejournal.com:
У всех сложилось примерно то же ощущение, я посмотрел сейчас в комменты к статье.
Комментарий для Евгения Степанищева:
Вы такую хрень ещё и читаете? :)
Комментарий для develop7.info:
Ну, там такой жыр :)