Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
согласись, сложно ошибиться в команде repz, и даже в and... 06.01.04 04:54 Число просмотров: 1245 Штраф: 40 [HandleX, amirul]
Автор: jammer <alex naumov> Статус: Elderman
|
> > > Да уж. В асме таких ляпсусов не бывает. Там
> > мимо тазика2 - асм не задумывался как ЯВУ
> Ошибка - это удел человека а не компилятора. И высокого тот
> уровня низкого или вообще машинные коды - ошибки делают
> люди.
согласись, сложно ошибиться в команде repz, и даже в and ecx, 00000003 (цитирую твой же код). асм изначально рассчитан на другой уровень аккуратности, чем ЯВУ. так что и ошибки в нем другие.
> Гы. Как раз современные программах больше всего
> нетривиальных алгоритмов.
а нетривиальный алгоритм раскладывается на тривиальные части.
> Кстати тривиальный алгоритм -
> разделить число на 10. Как вы его реализуете на асме? (если
> знаете этот фокус то хорошо, но ведь таких фокусов ОЙ как
> много, причем намного менее очевидных, причем на разных
> аппаратных платформах, даже с разными процессорами фокусы
> разные, имхо под интеловские процессоры лучше всего код
> генерит Intel CPP compiler)
да не нравятся мне интеловские процессоры :) тормозят.
> Ах так вы еще вспоминаете DOS'овские программы, и вероятно
> соответствующие компиляторы имеете ввиду.. Рассчитанные под
> 8086. А между тем современные программы это не
> десяток-сотня строчек считающих там чтото а десятки и сотни
> тысяч строк кода различных модулей на С которые между
> прочим очень взаимосвязаны. Вы писали когда нибудь проект
нет смысла повторять идентичный вопрос. нет. это последний ответ об этом.
> больше 5000 строчек на С? И как у вас было сильное желание
> переписать все это на асме чтобы оно работало надежнее и
> быстрее? Учитывая что последовательные обращения к областям
> памяти лучше делать через инструкции необращаюиеся к
> памяти. А еще непомешало бы посчитать время выполнения
> каждой инструкции и собрать их стока чтоб за время их
> выполнения как раз прошел тик генератора тактовой частоты
> системной шины чтоб были минимальны задержки при очередном
> обращении к памяти. Что обращения по возможноти надо делать
> так чтобы они влезали в кэш. А если чтото не влезает то
> лучше бы его отнести в другое время. + еще учтите
> многозадачную архитектуру современных ОС когда несколько
> участков кода могут работать одновременно, и ежели мы пишем
> крупный проект который может работать на сервере то не
> мешало бы его оптимизировать под многопроцессорные
> архитектуры что тоже знаетеле не просто так и может дать
> выигрыш от совсем никакого до почти двухкратного.
> Компилятор это все знает, и считатет тайминги намного
> быстрее человека. Я говорю не про Borland CPP 5.01.
не стану с этим спорить, но это не отменяет пользы от ручной оптимизации на уровне асма (или изначального написания на асме) некоторых критических участков, где компилятор лажается. особенно если учесть что один и тот же екзешник, оптимизированный под интел, будет работать на АМД гадко, и наоборот. для развития мысли можно применить твой аргумент о том, что платформ множество - более двух.
> Так вот касательно моего проекта на 20000 строчек на С++.
> Он работает. Вполне реально. И имхо он проще антивиря
> касперского хотя антивирей я не писал. А вот ежели это все
> переписать на асме... И положим отладить до приемлемого
> уровня.. Боюсь там не то что в 3 раза будет больше кода а в
> 10. Во первых я за это время на него попросту забью пока
> чтото там заработает, во вторых даже если не забью и не
> помру от старости очень врядли что мне удастся сделать код
> более эффективный чем это делает компилятор.
это все проблемы девелоперов, и не играет роли.
> И возвращаясь к топику. Вам бы хотелось каждый раз
> перекачивать весь антивирь касперского после каждого
> обновления? Еслиб все процедуры обнаружения вирей были
> писаны на асме имхо так бы оно и было. + гораздо более
не вижу связи. обновление иполняемых бинарников и так идет не кусками файлов, а целиковыми файлами, причем большими целиковыми файлами, содержащими немаленькую кучу рожденного компилятором мусора. да что мешало бы обновлять это по частям при изменении языка исходника?
> сделает их гораздо больше на АСМе. Любой компилятор в этом
> смысле гораздло идеальнее перегоняет большое количество
> кода в машинные коды нежели человек сразу это все вдруг
> вздумает написать.
я не сравнивал машину и человека в процессе "перегоняния" (какие у тебя самогонные термины, однако :) вМАШИННЫЕ_КОДЫ так что попрошу не передергивать.
> Напоследок пару листингов кину - одной маааленькой функции
> экспортируемой DLL'ой того проекта и ее АСМовый листинг
и ты конечно же хочешь сказать что тут лишнего почти нет? :)
удачи.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
