информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медСетевые кракеры и правда о деле ЛевинаЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 TeamViewer обвинил в своем взломе... 
 Docker Hub закрыл доступ из России 
 Google заблокировала 2 с лишним... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
согласись, сложно ошибиться в команде repz, и даже в and... 06.01.04 04:54  Число просмотров: 1396  Штраф: 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'ой того проекта и ее АСМовый листинг

и ты конечно же хочешь сказать что тут лишнего почти нет? :)

удачи.
<site updates> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach