Из моих скудных познаний: ассемблер — язык, использующий аббревиатуры, напоминающие англ. язык. Всё это транслируется в объектный код особыми программами-ассемблерами. Так зачем использовать ассемблер сейчас, когда есть куда более удобные языки высокого уровня?? Неужели только из-за быстродействия?! И это в эпоху пентиумов4?
При неполном освещеньи, все вы просто восхищенье!
Иоганн Вольфганг Гете.
Здравствуйте WarlockFX, Вы писали:
WFX>зачем использовать ассемблер сейчас, когда есть куда более удобные языки высокого уровня?? Неужели только из-за быстродействия?! И это в эпоху пентиумов4? :???:
Во-первых, не все компиляторы поддерживают набор команд последних версий процессоров. Во-вторых, некоторые команды процессоров, даже при наличии поддержки компилятора, не отображаются на язык/библиотеку. Например, широко известная, rdtsc. Твой вопрос некоторым образом напоминает мне вопрос: зачем хирургу скальпель, когда он может использовать намного более функциональный супер-пупер армейский нож? Каждый инструмент хорош на своем месте.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте Павел Кузнецов, Вы писали:
ПК> <...> Твой вопрос некоторым образом напоминает мне вопрос: зачем хирургу скальпель, когда он может использовать намного более функциональный супер-пупер армейский нож? <...>
ПК>Во-первых, не все компиляторы поддерживают набор команд последних версий процессоров. Во-вторых, некоторые команды процессоров, даже при наличии поддержки компилятора, не отображаются на язык/библиотеку.
В-третьих ручная оптимизация критических к скорости исполнения участков кода может увеличить производительность в полтора-два раза. Да пусть даже на 10% — и то хорошо.
Здравствуйте Igor Trofimov, Вы писали:
ПК>>Во-первых, не все компиляторы поддерживают набор команд последних версий процессоров. Во-вторых, некоторые команды процессоров, даже при наличии поддержки компилятора, не отображаются на язык/библиотеку.
IT>В-третьих ручная оптимизация критических к скорости исполнения участков кода может увеличить производительность в полтора-два раза. Да пусть даже на 10% — и то хорошо.
Если математику переписать с обычных C на SSE-инструкции, то можно и раза в 3 скорость увеличить... Т.е. если раньше P4 решал цифродробительную задачу целую ночь, то после оптимизации будет справляться за 3 часа =))
Правда, частенько "наборам команд последних версий процессоров" соответствуют интринтики, но даже с им иногда асм предпочтительнее.
Здравствуйте WarlockFX, Вы писали:
WFX>Из моих скудных познаний: ассемблер — язык, использующий аббревиатуры, напоминающие англ. язык. Всё это транслируется в объектный код особыми программами-ассемблерами. Так зачем использовать ассемблер сейчас, когда есть куда более удобные языки высокого уровня?? Неужели только из-за быстродействия?! И это в эпоху пентиумов4?
Твой вопрос некорректен. Из того, что язык использует "аббревиатуры, напоминающие англ. язык", не значит что он современен или устарел. Более того, если какой-то язык будет использовать даже слова, напоминающие русский язык, это не сделает его более современным или устаревшим, чем он есть на самом деле.
Здравствуйте Aquila, Вы писали:
A> Из того, что язык использует "аббревиатуры, напоминающие англ. язык", не значит что он современен или устарел.
А я это и не утверждаю а просто перечисляю скудные познания, т.к.
они действительно скудны и я могу в чем-то ошибаться.
При неполном освещеньи, все вы просто восхищенье!
Иоганн Вольфганг Гете.
Здравствуйте WarlockFX, Вы писали:
A>> Из того, что язык использует "аббревиатуры, напоминающие англ. язык", не значит что он современен или устарел. WFX>А я это и не утверждаю а просто перечисляю скудные познания, т.к. WFX>они действительно скудны и я могу в чем-то ошибаться.
Тогда отвечу на твой вопрос — ассемблер нужен для того, чтобы писать на нем программы .
Здравствуйте Igor Trofimov, Вы писали:
IT>В-третьих ручная оптимизация критических к скорости исполнения участков кода может увеличить производительность в полтора-два раза. Да пусть даже на 10% — и то хорошо.
С этим третьим аунктом надо быть очень осторожным. Ассемблера надо по возможности избегать, даже в time-ctritical задачах. Мне вообще до ассемблеров дела нет, я и так весь ifdef'ах. У меня целевые платформы на основе StrongARM, SH4, 486+. А использование ассемблера везде где только можно — есть зло. Некоторые программеры еще с собой носят самопальные библиотеки всяческих полезных функций на ассемблере. Поэтому сил на использование _T("") вместо "" уже не остается. Короче, я к тому, что 10% — это НИЧТО, ноль, пустое место! За эти 10% мы получаем непереносимый код, потребность в более квалифицированных программистах, кучу потенциальных ошибок и несколько самых настоящих. Например, софт для 200 мгц стронгарма (без сопроцессора!) прекрасно обходится без каких-либо ассемблерных вставок, хотя критических по времени задач много. Юзеры просто соглашаются с частичной потерей данных.
А вот первые два пункта имеют место быть: к сожалению, бывают случаи, когда асм нужен. Например, когда нет компилятора Визуал Бейсика под какой-нибудь новый процессор. Или когда ну очень надо использовать какую-нибудь новомодную SSE инструкцию.
X>С этим третьим аунктом надо быть очень осторожным. Ассемблера надо по возможности избегать, даже в time-ctritical задачах.
Не уверен, что твео мнение разделяют разработчики, реализующие криптографические алгоритмы, обработку аудио/видео, realtime-3D и проч.
X>А использование ассемблера везде где только можно — есть зло.
Никто не говорит "везде, где можно".
X>Короче, я к тому, что 10% — это НИЧТО, ноль, пустое место!
Думаю, вышеперечисленные люди с тобой не согласятся... Представь, что один mp3-кодек будет на 10% быстрее второго при одинаковых остальных показателях. Это очень неплохой разрыв — 10%.
Здравствуйте Igor Trofimov, Вы писали:
X>>Ассемблера надо по возможности избегать, даже в time-ctritical задачах.
IT>Не уверен, что твео мнение разделяют разработчики, реализующие криптографические алгоритмы, обработку аудио/видео, realtime-3D и проч.
Я, конечно, не все "разработчики, реализующие криптографические алгоритмы, обработку аудио/видео, realtime-3D и проч.", но работаю в области, сильно завязанной на все вышеперечисленное. Куски кода, когда-то написанные на ассемблере, "мочим" при первой встрече при сопровождении старого кода. При написании нового по возможности избегаем. Т.е., если что-то удается написать без использования ассемблера, без существенной потери эффективности, пишем на C/C++.
IT>Представь, что один mp3-кодек будет на 10% быстрее второго при одинаковых остальных показателях. Это очень неплохой разрыв — 10%.
Особенно, если к тому времени, когда второй будет уже на рынке несколько месяцев или год и будет продан хорошими тиражами. Первый будет по достоинству оценен тонкими ценителями, но, к сожалению, может себя не окупить :-)
Ассемблер прекрасно вписывается в места, где нужно сделать что-нибудь, что невозможно сделать на C/C++: определить тип или вызвать специфическую команду процессора, что-нибудь "намутить" со стеком/вызовами в блоке защиты, написать шаблоны для кодогенератора и т.п. И, конечно, иногда соптимизировать "узкое" место, но только как последнее средство для этого, ибо <... читай подпись ...>
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте Igor Trofimov, Вы писали:
X>>Короче, я к тому, что 10% — это НИЧТО, ноль, пустое место!
IT>Думаю, вышеперечисленные люди с тобой не согласятся... Представь, что один mp3-кодек будет на 10% быстрее второго при одинаковых остальных показателях. Это очень неплохой разрыв — 10%.
С точки зрения декодирования МП3: большинство американских пользователей все равно предпочитают пользоваться WMP. С точки зрения кодирования: создатели кодеков бьются над увеличением степени сжатия и реалистичности. Если я занимаюсь сжатием МП3 и плачу за кодек несколько сот баксов, то я запросто отдам еще стольник за более мощный процессор. На крайний случай поставлю рядом еще один компьютер 9или еще один процессор).
Это вопрос действительно философский, почти что как выход по goto из вложенных циклов.
Критичных по времени задач очень мало, решаются они железом (возможно, специализированным железом, таким, как 3Д-ускорители) и хорошими алгоритмами (сколько ни пиши пзырьковую сортировку на ассемблере, а толку мало).
Я понимаю, что существуют другие точки зрения, но их я принять не могу, Если мне работодатель захочет увидеть ассемблерную вставку в моем коде, он ее увидит. И все.
ПК>Я, конечно, не все "разработчики, реализующие криптографические алгоритмы, обработку аудио/видео, realtime-3D и проч.", но работаю в области, сильно завязанной на все вышеперечисленное. Куски кода, когда-то написанные на ассемблере, "мочим" при первой встрече при сопровождении старого кода. При написании нового по возможности избегаем. Т.е., если что-то удается написать без использования ассемблера, без существенной потери эффективности, пишем на C/C++.
Именно о существенной потере и может идти речь. 10% — это так, мелочи... а как насчет 50%? Не удивлюсь, если после ручной оптимизации такого разрыва можно будет достичь. Есть например, замечательный пример, когда за счет использования команды adc можно добавить к числу c бит переноса от сложения a и b. Это применяется, например, в одном из алгоритмов рисования отрезка прямой. Т.е. на асме — две команды — add и adc. На C... покажи, как ты это сделаешь на C. Шикарный пример ручной оптимизации — алгоритм текстурирования из Quake — цикл развернут на 16 итераций таким образом, чтобы за одну неразвернутую итерацию происходило одно параллельно выполняющееся на FPU деление. Т.е. получается огромный эффект от параллелизма CPU/FPU. Т.е. фактически даром — 50% производительности.
Здравствуйте Xentrax, Вы писали:
X>Здравствуйте Igor Trofimov, Вы писали:
IT>>В-третьих ручная оптимизация критических к скорости исполнения участков кода может увеличить производительность в полтора-два раза. Да пусть даже на 10% — и то хорошо.
X> X>С этим третьим аунктом надо быть очень осторожным. Ассемблера надо по возможности избегать, даже в time-ctritical задачах. Мне вообще до ассемблеров дела нет, я и так весь ifdef'ах. У меня целевые платформы на основе StrongARM, SH4, 486+. А использование ассемблера везде где только можно — есть зло. Некоторые программеры еще с собой носят самопальные библиотеки всяческих полезных функций на ассемблере. Поэтому сил на использование _T("") вместо "" уже не остается. Короче, я к тому, что 10% — это НИЧТО, ноль, пустое место! За эти 10% мы получаем непереносимый код, потребность в более квалифицированных программистах, кучу потенциальных ошибок и несколько самых настоящих. Например, софт для 200 мгц стронгарма (без сопроцессора!) прекрасно обходится без каких-либо ассемблерных вставок, хотя критических по времени задач много. Юзеры просто соглашаются с частичной потерей данных.
X>А вот первые два пункта имеют место быть: к сожалению, бывают случаи, когда асм нужен. Например, когда нет компилятора Визуал Бейсика под какой-нибудь новый процессор. Или когда ну очень надо использовать какую-нибудь новомодную SSE инструкцию.
Не смешите меня "переносимым кодом"....
Я тут вижу все об оптимизации говорят...
А да что мне та оптимизация....
Если бы в разработке алгоритмов меня удовлетворял С/С++, я б и не смотрел на асм...
Но не удовлетворяет...
А вот почему ... это уже другая сказка
Я не смешу, у нас реальзно без каких либо модификаций работает под Windows CE и Win32 куча кода, написанного умным человеком еще для Psion. Один и тот же код собирается для нескольких процессоров. Есть конечно некоторые особенности, связанные с глюками в SDK и сыростью некоторых платформ, но их очень мало.
Для меня переносимость — не пустой звук. Поэтому к ассемблеру отношуть крайне отрицательно, хотя и помню чувство восторга, когда писал программки типа переключателя раскладки клавиатуры или когда ломал за обещания 5 баллов автоматом по менеджменту какую-то учебную программу. Никакое шаблонное программирование и рядом не лежало
Здравствуйте Xentrax, Вы писали:
X>Здравствуйте Edmond, Вы писали:
X>
E>>Не смешите меня "переносимым кодом"....
X>Я не смешу, у нас реальзно без каких либо модификаций работает под Windows CE и Win32 куча кода, написанного умным человеком еще для Psion. Один и тот же код собирается для нескольких процессоров. Есть конечно некоторые особенности, связанные с глюками в SDK и сыростью некоторых платформ, но их очень мало.
Да кто ж этого против
Но как правило этот переносимый код -- действительно независимые от среды задачи!!!
X>Для меня переносимость — не пустой звук. Поэтому к ассемблеру отношуть крайне отрицательно,
хотя и помню чувство восторга, когда писал программки типа переключателя раскладки клавиатуры или когда ломал за обещания 5 баллов автоматом по менеджменту какую-то учебную программу. Никакое шаблонное программирование и рядом не лежало
Гм..., боюсь, что время "восторгов" для меня прошло....
Да и какое-то странное у вас представление: ломать, переключать....
Здравствуйте Edmond, Вы писали:
E>Но как правило этот переносимый код -- действительно независимые от среды задачи!!!
Как оказалось, Win32 можно перенести куда угодно. Даже на устройства с 4 — 8 мегами памяти, не говоря уже о современных 64-128 с флешками по 512 мб
E>Гм..., боюсь, что время "восторгов" для меня прошло.... E>Да и какое-то странное у вас представление: ломать, переключать....
Просто я не понимаю, почему многие используют ассемблер там, где он не нужен. Я считаю, что только потому, что нравится. Однажды встала задача заменить системный диалог открытия файла. Я, всегда ратующий за code reusability (а потому с отвтращением приступивший к выполнению очередной блажи руководства), решил поискать что-нибудь в инете. В нескольких вариантах я нашел ассемблерные вставки. И эти реализации отправилиcь в /dev/nul. Но я прекрасно понимаю авторов: им было "по приколу". До сих пор многие программисты даже не знают про юникод, Конечно, елси так подходить к прогарммированию, то про переносимость можно забыть.
А еще я вот сейчас сижу и думаю, что будут делать дорогие наши любители ассемблерных вставок после прехода на архитектуру IA-64? Лично я просто нажму Ctrl-Shift-B.
Re[8]: зчем нужен ассемблер??
От:
Аноним
Дата:
18.10.02 17:23
Оценка:
Простой пример. Кодек H263. Время более чем существенно. После применения MMX'а производительность увеличилась в 2-3 раза. Есть альтернативы?
Здравствуйте <Аноним>, Вы писали:
А>Простой пример. Кодек H263. Время более чем существенно. После применения MMX'а производительность увеличилась в 2-3 раза. Есть альтернативы?
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте <Аноним>, Вы писали:
А>>Простой пример. Кодек H263. Время более чем существенно. После применения MMX'а производительность увеличилась в 2-3 раза. Есть альтернативы? VD>А что MMX и SSE компиляторам не доступны?
Здравствуйте Aquila, Вы писали:
А>>>Простой пример. Кодек H263. Время более чем существенно. После применения MMX'а производительность увеличилась в 2-3 раза. Есть альтернативы? VD>>А что MMX и SSE компиляторам не доступны?
A>Например?
Intel С++ 5-6
Думаю, что через год-два и Шарповский будет кое-что поддерживать.
Здравствуйте VladD2, Вы писали:
А>>>>Простой пример. Кодек H263. Время более чем существенно. После применения MMX'а производительность увеличилась в 2-3 раза. Есть альтернативы?VD>>>А что MMX и SSE компиляторам не доступны? A>>Например? VD>Intel С++ 5-6
Это все? Небогатый выбор. Тем не менее на то, что он все-таки имеется, там где требуется хорошая оптимизация, пишут на ассемблере. Впрочем, на ассемблере можно писать и когда оптимизация не требуется, благо язык не слишком сложный.
VD>Думаю, что через год-два и Шарповский будет кое-что поддерживать.
А зачем ему? Он же под VM генерит. VM, по идее, должна отвечать за генерацию реального кода.
Здравствуйте Aquila, Вы писали:
A>Это все? Небогатый выбор. Тем не менее на то, что он все-таки имеется, там где требуется хорошая оптимизация, пишут на ассемблере. Впрочем, на ассемблере можно писать и когда оптимизация не требуется, благо язык не слишком сложный.
VD>>Думаю, что через год-два и Шарповский будет кое-что поддерживать.
A>А зачем ему? Он же под VM генерит. VM, по идее, должна отвечать за генерацию реального кода.
Оптимизацию алгоритмов будет делаться помпиляторм Шарпа и других языков. Ну, а оптимизацию под процессор безусловно должен делать JIT. Я же рассматривал эти вещи совместно. Т.е. с точи зрения использования MMX и т.п. конечно нужно развивать не "компилятор с языка", а JIT.
Здравствуйте Аноним, Вы писали:
А>Простой пример. Кодек H263. Время более чем существенно. После применения MMX'а производительность увеличилась в 2-3 раза. Есть альтернативы?
100-200% — это уже совсем не 10%. Кроме того, речь идет о продукте, о котором нельзя сказать: "пользователь может подождать чуть подольше" (работа не-лету), "пускай купит машину помощнее" (и так уже мощная) и "через год выйдет пентиум 10 и все будет тип-топ" (продукт нужен немедленно).
Но и тут наверное лучше не самому писать на ассемблере, а попробовать использовать интеловские библиотеки...
Здравствуйте VladD2, Вы писали:
A>>Это все? Небогатый выбор. Тем не менее на то, что он все-таки имеется, там где требуется хорошая оптимизация, пишут на ассемблере. Впрочем, на ассемблере можно писать и когда оптимизация не требуется, благо язык не слишком сложный. VD>
Всяко попроще, чем C# .
VD>>>Думаю, что через год-два и Шарповский будет кое-что поддерживать. A>>А зачем ему? Он же под VM генерит. VM, по идее, должна отвечать за генерацию реального кода. VD>Оптимизацию алгоритмов будет делаться помпиляторм Шарпа и других языков.
IlAsm
VD>Ну, а оптимизацию под процессор безусловно должен делать JIT. Я же рассматривал эти вещи совместно. Т.е. с точи зрения использования MMX и т.п. конечно нужно развивать не "компилятор с языка", а JIT.
Здравствуйте Xentrax, Вы писали:
X>Здравствуйте Edmond, Вы писали:
E>>Но как правило этот переносимый код -- действительно независимые от среды задачи!!!
X>Как оказалось, Win32 можно перенести куда угодно. Даже на устройства с 4 — 8 мегами памяти, не говоря уже о современных 64-128 с флешками по 512 мб
??? Например???
E>>Гм..., боюсь, что время "восторгов" для меня прошло.... E>>Да и какое-то странное у вас представление: ломать, переключать....
X>Просто я не понимаю, почему многие используют ассемблер там, где он не нужен. Я считаю, что только потому, что нравится.
Такая трактовка действительно есть....
Однажды встала задача заменить системный диалог открытия файла. Я, всегда ратующий за code reusability (а потому с отвтращением приступивший к выполнению очередной блажи руководства), решил поискать что-нибудь в инете. В нескольких вариантах я нашел ассемблерные вставки. И эти реализации отправилиcь в /dev/nul. Но я прекрасно понимаю авторов: им было "по приколу". До сих пор многие программисты даже не знают про юникод,
Бедненькие
Конечно, елси так подходить к прогарммированию, то про переносимость можно забыть.
А что переносимоть????
Недавно был разговор об переносе асма с платформы на платформу....
И это не так уж невозможно....
X> X>А еще я вот сейчас сижу и думаю, что будут делать дорогие наши любители ассемблерных вставок после прехода на архитектуру IA-64? Лично я просто нажму Ctrl-Shift-B.
Что делать? Выход есть....
Вы мне скажите что будут делать программисты, есил тенденция полёта ЯВУ в верх не смениться.....
Здравствуйте Xentrax, Вы писали:
X>До сих пор многие программисты даже не знают про юникод,
Проблема в том, что про юникод не "знает" Win98 (в которой нет большинства ****W функций), а совместимость с этой операционкой зачастую гораздо более важна, чем с WinCE .
X>А еще я вот сейчас сижу и думаю, что будут делать дорогие наши любители ассемблерных вставок после прехода на архитектуру IA-64? Лично я просто нажму Ctrl-Shift-B.
Здравствуйте Aquila, Вы писали:
A>>>Это все? Небогатый выбор. Тем не менее на то, что он все-таки имеется, там где требуется хорошая оптимизация, пишут на ассемблере. Впрочем, на ассемблере можно писать и когда оптимизация не требуется, благо язык не слишком сложный. VD>>
A>Всяко попроще, чем C# .
Это точно. Не нужно переменные описывать лишние и заморачиваться отступами. Хотя есть несознательные ассемблерщики которые навязывают этот дикий ситль! И ты не поверишь... есть те которые используют табуляцию или 2-4 пробела на отступ!!! Зачем так усложнять жизнь?!
A>Интересно, получится ли это у Микрософта?
Меня волнует другой вопрос... не заведет ли к этому моменту MS себе новую игрушку?!
X>>Как оказалось, Win32 можно перенести куда угодно. Даже на устройства с 4 — 8 мегами памяти, не говоря уже о современных 64-128 с флешками по 512 мб
E>??? Например???
Да полно таких, ключевой слово — Windows CE. Наша фирма даже свою разрабатывает.Внутренняя флешка на 64 мб и отсек для дополлнительной флешки. Памяти пока ставят всего 32 мега, но железка пока сырая, и думаю, скоро будут савить 64 (у нас в фирме очень хреновые программисты софта, поэтому в 18 мегов свободной оперативки уже не влезаем).
E> До сих пор многие программисты даже не знают про юникод,
E>Бедненькие
Ага, еще как. Особенно когда им предлагают выпустить японскую версию
E>Конечно, елси так подходить к прогарммированию, то про переносимость можно забыть.
E>А что переносимоть????
Переносимость — это когда код не требует серьезной переделки, чтобы работаьт где-то еще.
E>Недавно был разговор об переносе асма с платформы на платформу....
Это экономически не обосновано, как мне кажется. Заниматься такой фигней .
X>> X>>А еще я вот сейчас сижу и думаю, что будут делать дорогие наши любители ассемблерных вставок после прехода на архитектуру IA-64? Лично я просто нажму Ctrl-Shift-B.
E>Что делать? Выход есть....
Какой выход? Насколько я понимаю, 32 разрядный код будет исполнятся на ИА-64 медленно. Или есть какие-то умные конвертеры из машинного кода из х486+ в ИА-64?
E>Вы мне скажите что будут делать программисты, есил тенденция полёта ЯВУ в верх не смениться.....
Мда, тогда под программировнаием будет пониматься совсем не то, что сейчас. Нужно будет двигать картинки, наподобие UML диаграмм или еще чего попроще. Тогда все программисты будут сразу становится архитекторами. Но до этого еще относительно далеко. Пока можно развлекаться ловлей суперхитрых багов.
Здравствуйте VladD2, Вы писали:
VD>А что MMX и SSE компиляторам не доступны?
Насчет MMX и SSE — не знаю. Но я еще не видел компилятора, который перебор массива целых в цикле превращал в конструкцию :
LOCK REPNE SCASD
А более быстрого варианта решения задачи прямого перебора массива в памяти я ешшо не встречал
Хотя, возможно, есть еще более наворочаные инструкции процессоров из SSE/SSE2 — я с ними не особо знаком, но и там будет аналог данного алгоритма, а не что-то другое, так что увы других вариантов нет.
Дело в том, что разработчик, имеющий представление о данных, всегда может соптимизировать код (иногда — ТОЛЬКО с применением ассемблера) так, чтобы он работал быстрее, чем то, что нагенерит самый наворочаный компилятор ЯВУ. Увы, но это — так.
Как и многие высказавшиеся я считаю, что ассемблер — это один из последних шагов оптимизации, зато после него уже нет вариантов, да и сомнений в скорости не остается.
Еще одно важное преимущество ассемблера — достаточно малый исполняемый код. Программа, которая будет целиком (и правильно) написана на ассемблере — совсем маленькая программа.
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте Edmond, Вы писали:
E>А что переносимоть???? E>Недавно был разговор об переносе асма с платформы на платформу.... E>И это не так уж невозможно....
Да... все, наверное хоть слышали про замечательные компутеры Yamaha и Spectrum??? (ну и прочие из семейства Z80, туда же, по-моему относилась Amiga).
Так вот. Данные компьютеры (а вернее — процессор) на 100% совместимы с Intel 8086 на уровне машинного кода. так что вот
некоторая специфика, конечно есть, конкретику приводить сечас не буду, но сам факт — на лицо.
Люди писали на Yamaha достаточно приятные программки на ассемблере и балдели от их маленького размера и высокого быстродействия.
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте Hacker_Delphi, Вы писали:
HD>Да... все, наверное хоть слышали про замечательные компутеры Yamaha и Spectrum??? (ну и прочие из семейства Z80, туда же, по-моему относилась Amiga).
Амига к z80 никаким боком не относится. Совершенно иная система — в Amiga стоят процы от Motorola (680x0, 603e, 604e, etc), которые несовместимы с Intel.
HD>Так вот. Данные компьютеры (а вернее — процессор) на 100% совместимы с Intel 8086 на уровне машинного кода. так что вот
Неправда твоя Z80 совместим только с i8080.
Re[10]: зчем нужен ассемблер??
От:
Аноним
Дата:
28.10.02 07:25
Оценка:
Здравствуйте Hacker_Delphi, Вы писали:
HD>Да... все, наверное хоть слышали про замечательные компутеры Yamaha и Spectrum??? (ну и прочие из семейства Z80, туда же, по-моему относилась Amiga). HD>Так вот. Данные компьютеры (а вернее — процессор) на 100% совместимы с Intel 8086 на уровне машинного кода. так что вот
Ткнул пальцем в небо. И промахнулся...
Несовместим Zilog Z80 с Intel 8086/88, нет. А вот с Intel 8080 — совместим (на 100% — сверху вниз).
HD>некоторая специфика, конечно есть, конкретику приводить сечас не буду, но сам факт — на лицо. HD>Люди писали на Yamaha достаточно приятные программки на ассемблере и балдели от их маленького размера и высокого быстродействия.
E>>Недавно был разговор об переносе асма с платформы на платформу.... X>Это экономически не обосновано, как мне кажется.
Экономика не имеет значения в контексте исходной темы. Впрочем, многие аргументы данного треда не имеют никакого значения.
X>Заниматься такой фигней .
А WinCe не фигня?
X>Какой выход? Насколько я понимаю, 32 разрядный код будет исполнятся на ИА-64 медленно. Или есть какие-то умные конвертеры из машинного кода из х486+ в ИА-64?
А зачем конвертировать? Более того, зачем писать под IA-64? С другой стороны, если надо написать, то почему бы это не сделать? В чем проблема?
X>Мда, тогда под программировнаием будет пониматься совсем не то, что сейчас. Нужно будет двигать картинки, наподобие UML диаграмм или еще чего попроще. Тогда все программисты будут сразу становится архитекторами.
Здравствуйте Aquila, Вы писали:
X>>Заниматься такой фигней .
A>А WinCe не фигня?
Еще какая. Компетентное мнение
X>>Какой выход? Насколько я понимаю, 32 разрядный код будет исполнятся на ИА-64 медленно. Или есть какие-то умные конвертеры из машинного кода из х486+ в ИА-64?
A>А зачем конвертировать? Более того, зачем писать под IA-64? С другой стороны, если надо написать, то почему бы это не сделать? В чем проблема?
Я просто к тому, что код написанный на на бейсике, джаве шарпе, паскале, плюсах заработает под ИА-64 без особых переделок. А ассемблерный 32-разрядный код — нет. Поэтому, если писать что-то долгосрочное, то наверное не стоит эмулировать замыкания в С++ :
ну и так далее, недавно тут пробегало, все видели...
Такой код под ИА-64 работаь не будет, Это при том, что единственная оправданная цель применения ассемблера — многократное повышение скорости выполнения здесь не достигается.
X>>Мда, тогда под программировнаием будет пониматься совсем не то, что сейчас. Нужно будет двигать картинки, наподобие UML диаграмм или еще чего попроще. Тогда все программисты будут сразу становится архитекторами.
A>Больше на Дельфи похоже.
Здравствуйте Xentrax, Вы писали:
A>>А зачем конвертировать? Более того, зачем писать под IA-64? С другой стороны, если надо написать, то почему бы это не сделать? В чем проблема? X>Я просто к тому, что код написанный на на бейсике, джаве шарпе, паскале, плюсах заработает под ИА-64 без особых переделок. А ассемблерный 32-разрядный код — нет. Поэтому, если писать что-то долгосрочное, то наверное не стоит эмулировать замыкания в С++ : X>class CStdThunk{ X> BYTE m_mov; // mov ecx, %pThis X> DWORD m_this; // X> BYTE m_jmp; // jmp func X> DWORD m_relproc; // relative jmp X>ну и так далее, недавно тут пробегало, все видели...
Наверное, не стоит. Если используется C++, то почему бы на нем и не писать?
X>Такой код под ИА-64 работаь не будет, Это при том, что единственная оправданная цель применения ассемблера —
многократное повышение скорости выполнения
Это не единственная оправданная цель применения ассемблера.
X>>>Мда, тогда под программировнаием будет пониматься совсем не то, что сейчас. Нужно будет двигать картинки, наподобие UML диаграмм или еще чего попроще. Тогда все программисты будут сразу становится архитекторами. A>>Больше на Дельфи похоже. X>Я всеми руками за.
Здравствуйте Hacker_Delphi, Вы писали:
HD>Здравствуйте Edmond, Вы писали:
E>>А что переносимоть???? E>>Недавно был разговор об переносе асма с платформы на платформу.... E>>И это не так уж невозможно....
HD>Да... все, наверное хоть слышали про замечательные компутеры Yamaha и Spectrum??? (ну и прочие из семейства Z80, туда же, по-моему относилась Amiga). HD>Так вот. Данные компьютеры (а вернее — процессор) на 100% совместимы с Intel 8086 на уровне машинного кода. так что вот
Да? Ямаха говорите
Не знал.... Для меня Ямаха, это не плохие проффессиональные синтезаторы....
Здравствуйте Xentrax, Вы писали:
X>Здравствуйте Edmond, Вы писали:
X> X>>>Как оказалось, Win32 можно перенести куда угодно. Даже на устройства с 4 — 8 мегами памяти, не говоря уже о современных 64-128 с флешками по 512 мб
E>>??? Например???
X>Да полно таких, ключевой слово — Windows CE.
Ловлю на слове: полно таких... пример Windows CE )))))))))))))))))))))))))
Вам не смешно?
X>Ага, еще как. Особенно когда им предлагают выпустить японскую версию
E>>Конечно, елси так подходить к прогарммированию, то про переносимость можно забыть.
E>>А что переносимоть????
X>Переносимость — это когда код не требует серьезной переделки, чтобы работаьт где-то еще.
Это же был реторический вопрос !!!!!
E>>Недавно был разговор об переносе асма с платформы на платформу....
X>Это экономически не обосновано, как мне кажется. Заниматься такой фигней .
Гы..., имееться ввиду перенос не человеком, а машиной!!!!
E>>Что делать? Выход есть....
X>Какой выход? Насколько я понимаю, 32 разрядный код будет исполнятся на ИА-64 медленно. Или есть какие-то умные конвертеры из машинного кода из х486+ в ИА-64?
Поживём увидим
E>>Вы мне скажите что будут делать программисты, есил тенденция полёта ЯВУ в верх не смениться.....
X>Мда, тогда под программировнаием будет пониматься совсем не то, что сейчас. Нужно будет двигать картинки, наподобие UML диаграмм или еще чего попроще. Тогда все программисты будут сразу становится архитекторами. Но до этого еще относительно далеко. Пока можно развлекаться ловлей суперхитрых багов.
Боюсь что не совсем так....
Вернее так, но не с ООП и процедурным программингом...
Здесь уже нужна новая технология...
И при этом всём... это не значит что низкоуровневое программирование сомнётсья...
Скорее может быть даже наоборот
С уважением, Edmond
Re[11]: зчем нужен ассемблер??
От:
Аноним
Дата:
28.10.02 14:59
Оценка:
Здравствуйте Edmond, Вы писали:
E>Да? Ямаха говорите E>Не знал.... Для меня Ямаха, это не плохие проффессиональные синтезаторы....
Кстати, у этих школьно-игровых компьютеров был весьма неплохой звук. И графика тоже на уровне. Но меня всегда удивлял их набор цветов.
Здравствуйте Edmond, Вы писали:
X>>Да полно таких, ключевой слово — Windows CE.
E>Ловлю на слове: полно таких... пример Windows CE ))))))))))))))))))))))))) E>Вам не смешно?
Нет не смешно. Ло знакомства с WinCE я считал, что Win32 — это читстый Wintel, и всякие там альфы — это так, детские игрушки. Однако же основное подмножество Win32, подкрепленное библиотеками запросто позволяет писать под самые разнообразные платформы. Что самое удивительное, что у вполне работоспособной CE 2.0 были просто мизерные требования к памяти. Это веь не компилятор языка написать и даже не библиотеку перенести. По сути переносимость на уровне ОС, со всем соглашениями. И при этом, ни эмуляции, ни интерпретации некоего p-code здесь и рядом не лежало.
X>>Переносимость — это когда код не требует серьезной переделки, чтобы работаьт где-то еще.
E>Это же был реторический вопрос !!!!!
E>>>Недавно был разговор об переносе асма с платформы на платформу....
X>>Это экономически не обосновано, как мне кажется. Заниматься такой фигней .
E>Гы..., имееться ввиду перенос не человеком, а машиной!!!!
Вот и я к тому: то ли надо писать конвертор кода (реально ли?), то ли эмулятор процессора (с эмулятором среды выполнения на пару). Дядечки с толстыми кошельками скорее заплатят за разработку новой системы с нуля, чем за попытку конвертации больших объемов ассемблерного кода на новые платформы. Потому что понимают, что даже ежели получится, то через пяток лет им опять придется искать парней, которые должны будут писать эмулятор или конвертор под новую платформу...
И я уверен, что эти самые дядечки с толстыми кошельками будут очень внимательно следить, чтобы в новую систему не попала ни одна строчка на ассемблере.
E>Боюсь что не совсем так.... E>Вернее так, но не с ООП и процедурным программингом... E>Здесь уже нужна новая технология...
Насчет новых методик программирования я даже боюсь загадывать. Но от ООП мы еще долго не уйдем, потому что человек так думает. Хотя возможно программирование будет заключаться в генерации требований к системе. Мы просто будем говорить, что нужна база данных, клиент-сервер, для того то и того-то, пользователей будет не больше трех миллиардов, отчеты нужны будут, а потом к сгенерированному по шаблонам коду будем выдвигать новые уточняющие требования.
Самые главные гении будут заняты настройкой этих самых шаблонов с помощью мета средств создания средств мета программирования (это не оговорка ).
Ну а толпы людей будут сидеть и преобразовывать немного сумбурные требования клиентов в более четкие требования. По мере развития средств ИИ, потребность в таких людях будет снижаьтся.
Ну а там уже по плану придет Мессия и всех спасет от поголовной безработицы.
E>И при этом всём... это не значит что низкоуровневое программирование сомнётсья...
низкоуровневое программирование останется всегда — хотя вполне возможно, что новые процессоры и другие железки будут целиком и полностью разрабатываться на ЯВУ, а версия компилятора Visual Basic для этих кристаллов будет создаваться как Post-Build Step при создании схемы железки. Но это я так, немножко отвлекся от реальности
Здравствуйте, Hacker_Delphi, Вы писали:
HD>Здравствуйте VladD2, Вы писали:
VD>>А что MMX и SSE компиляторам не доступны?
HD>Насчет MMX и SSE — не знаю. Но я еще не видел компилятора, который перебор массива целых в цикле превращал в конструкцию : HD>
HD>LOCK REPNE SCASD
HD>
хахахахахах
так писали пять лет назад. это ЖУТКО тормозная инструкция на современных процессорах.
Ибо
1) префиксы — зло, долго декодируются
2) инструкция — CISC, для нёё громоздкая микропрограмма
написать по-тупому
mov esi, src
xor edx, edx
mov eax, val
@l1:
test eax, [esi + edx*4]
inc edx
jne @l1
будет БЫСТРЕЕ
HD>А более быстрого варианта решения задачи прямого перебора массива в памяти я ешшо не встречал HD>Хотя, возможно, есть еще более наворочаные инструкции процессоров из SSE/SSE2 — я с ними не особо знаком, но и там будет аналог данного алгоритма, а не что-то другое, так что увы других вариантов нет.
да при чём тут SSE ?!! SSE — это векторная обработка (к тому же с низкой точностью). И надо сказать, сильного прироста это поделие не даёт. В итоге оказывается удобнее использовать геометрический процессор какой-ньть GeForce.
HD>Дело в том, что разработчик, имеющий представление о данных, всегда может соптимизировать код (иногда — ТОЛЬКО с применением ассемблера) так, чтобы он работал быстрее, чем то, что нагенерит самый наворочаный компилятор ЯВУ. Увы, но это — так.
HD>Как и многие высказавшиеся я считаю, что ассемблер — это один из последних шагов оптимизации, зато после него уже нет вариантов, да и сомнений в скорости не остается.
HD>Еще одно важное преимущество ассемблера — достаточно малый исполняемый код. Программа, которая будет целиком (и правильно) написана на ассемблере — совсем маленькая программа.
в том то и дело, что на асме (по крайней мере intel-овском) хорошо писать только МАЛЕНЬКИЕ программы
Здравствуйте, WarlockFX, Вы писали:
WFX>Из моих скудных познаний: ассемблер — язык, использующий аббревиатуры, напоминающие англ. язык.
Ну тогда паскаль это вообще литературный английский. WFX>Так зачем использовать ассемблер сейчас, когда есть куда более удобные языки высокого уровня?? Неужели только из-за быстродействия?! И это в эпоху пентиумов4?
Ну вопервых не всегда можно обойтись языком высокого уровня
А для прекладного програмиста его не обязательно использовать, просто знать нужно
что бы понимать как компьютер работает.
Что бы понять что сгенерировал твой высокоуровненвый компилятор, когда возникла не однозначность.
Да и само быстродействие это не мало, просто не везде нужно.
Да и не кругом пеньтиумы четвёртые
Перекуём баги на фичи!
Кр-ть — с.т.
.
.
