информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetГде водятся OGRыПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 The Great Suspender предположительно... 
 Десятилетняя уязвимость в sudo 
 Блокировка Flash поломала китайскую... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Вторая беда - рефакторинг невозможен практически 08.12.03 13:07  Число просмотров: 1561 [Ktirf, JINN]
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
Уже не реюз, как я писал раньше. Для того, что я имел в виду есть другое более умное слово :-)

Собственно подгонка кода под новые условия существования - БОЛЬШАЯ проблема для асма. И на пару порядков меньшая для C
<site updates>
Как proxy стал злобным вирусом 28.11.03 12:20  
Publisher: cybervlad <cybervlad> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Как proxy стал злобным вирусом
security.nnov.ru http://www.security.nnov.ru/articles/antiantivirus2.asp

Популярная программа 3proxy (http://www.security.nnov.ru/soft/3proxy) стала определяться антивирусными программами как вредоносная. Попытка "выяснить отношения" с разработчиками антивирусов имела странный результат. Подробности своей беседы с Евгением Касперским публикует на своем сайте 3APA3A.


Полный текст
Ох... 03.12.03 01:42  
Автор: jammer <alex naumov> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
не внесет ли сей ученый муж в свой списочек корову? я все чаще и чаще этого побаиваюсь.
Ну вот оно и начинается 03.12.03 03:13  
Автор: jammer <alex naumov> Статус: Elderman
Отредактировано 03.12.03 03:33  Количество правок: 2
<"чистая" ссылка> <обсуждение закрыто>
> не внесет ли сей ученый муж в свой списочек корову? я все
> чаще и чаще этого побаиваюсь.

"We have had several reports from users that Norton AV 2003 is
detecting the file dnetc.com from build 483 as a Trojan. We
have confirmed this as well as confirming that Norton AV
corporate edition 8 has the same behavior."

(с)

Проблема с NAV
чешем репу?
Здравствуйте, 02.12.03 02:27  
Автор: Serge3leo Статус: Незарегистрированный пользователь
<"чистая" ссылка> <обсуждение закрыто>
Здравствуйте,

Всё понимаю кроме следующего предложения:

"..., но не более того. И больше всего умиляют его попытки представить себя как специалиста в области безопасности)."

Оно как-то совершенно не связанно, ни с обсуждаемой проблемой, ни с остальными частями статьи.

Или есть соображения о низком уровне профессионализма сотрудников "Лаборатории Касперского" и у них следует отозвать лицензию ГосТехКоммиссии на разработку, производство, распространение и поддержку. Или быть может ПО от "Лаборатории Каспреского" не безопасно и у них следует отозвать сертификаты ГосТехКоммиссии на те или иные продукты?

Вероятно, и продукты хорошие, и специалисты хорошие, просто рабочие моменты, связанные с совместимостью разных продуктов.

P.S.

Следует заметить, что ссылки по теме на http://www.kaspersky.ru/ не хватает.
hi 03.12.03 01:31  
Автор: jammer <alex naumov> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Всё понимаю кроме следующего предложения:
> "..., но не более того. И больше всего умиляют его попытки
> представить себя как специалиста в области безопасности)."
> Оно как-то совершенно не связанно, ни с обсуждаемой
> проблемой, ни с остальными частями статьи.

Женька лапы не только к защите от вирусов, а вообще к защите как таковой тянет - это не секрет.

> Или есть соображения о низком уровне профессионализма

однозначно есть. начать с таких мелочей, как нормальный приоритет сканера по умолчанию и тормознутый монитор (на Си чтоли написан, или вообще на бейсике?). ключевые файлы - так просто курам на смех. не могу сказать что я особо много юзал касперского, но в серьезных конторах я замечаю что его сносят и ставят NAV например. повод задуматься или нет?

> сотрудников "Лаборатории Касперского" и у них следует
> отозвать лицензию ГосТехКоммиссии на разработку,
> производство, распространение и поддержку. Или быть может
> ПО от "Лаборатории Каспреского" не безопасно и у них

видимо, раз он любит корежить безобидные файлы, никак не безопасно.

> следует отозвать сертификаты ГосТехКоммиссии на те или иные
> продукты?

это не нам решать. это бизнес ;) - инвестиции, клиенты, продажи, конкуренты, налоги, отстегивания. знаю я примерно как это делается. я даже в коммерческом вузе работал 2 года, там похожий расклад, все просто.

вобщем я к тому что к делу это все не относится. сертификат о качестве софта говорит весьма мало.

> Вероятно, и продукты хорошие, и специалисты хорошие, просто
> рабочие моменты, связанные с совместимостью разных продуктов.

Женьке все прямо было сказано, ан нет, Женька уперся рогом.
честно сказать, есть у меня подозрения, что он из тех, кто любит пускать пыль в глаза лапшой на уши на тему собственной супер-пупер важности, и приводить тщательно отфильтрованный список аргументов, скрывая невыгодные. мне такой подход к делу никогда не нравился.

> Следует заметить, что ссылки по теме на
> http://www.kaspersky.ru/ не хватает.

а это, видимо, либо и так понятно, либо следует написать вебмастеру security.nnov.ru

а хватает ли ссылки писать сюда
размах!
Оффтоп: вопрос по поводу причин тормознутости 03.12.03 11:23  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
> приоритет сканера по умолчанию и тормознутый монитор (на Си
> чтоли написан, или вообще на бейсике?). ключевые файлы -
На C получаются тормозные проги или я чего то неправильно понял (насчет бейсика спорить не стану)?
asm forever :| 06.12.03 07:06  
Автор: jammer <alex naumov> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Одна беда - непереносим. То есть вообще нинасколько. 06.12.03 14:21  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
"бед"-то много 24.12.03 15:08  
Автор: jammer <alex naumov> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
время на разработку, отладку и модификацию существенно больше.
непереносимость? между чем и чем (если про монитор говорим) - уточните.

только клиенты платят как раз деньги для того чтобы кривописаки в авп работали, а не писульки на сях через клипбоард копировали. лично мне графический интерфейс для монитора и засирание места в трее не нужны - а скорость работы файл-сервера куда важнее.
Вторая беда - рефакторинг невозможен практически 08.12.03 13:07   [Ktirf, JINN]
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
Уже не реюз, как я писал раньше. Для того, что я имел в виду есть другое более умное слово :-)

Собственно подгонка кода под новые условия существования - БОЛЬШАЯ проблема для асма. И на пару порядков меньшая для C
а давайте немного уйдем от девелоперских проблем. представим себе: я - юзер 24.12.03 15:23  
Автор: jammer <alex naumov> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Уже не реюз, как я писал раньше. Для того, что я имел в
> виду есть другое более умное слово :-)
>
> Собственно подгонка кода под новые условия существования -
> БОЛЬШАЯ проблема для асма. И на пару порядков меньшая для C

какие могут быть еще новые условия существования - обновление вирусной базы или смена сервиспака в W2k/XP ? не смеши.

если хороший хирург поможет плохому танцору - разница в размере проблемы окажется куда меньшей.

а вообще-то сабж. :) как честно заплативший. убытки от лишних тормозов можно посчитать хоть в блоках rc5, хоть в нервах юзеров в моменты сильной нагрузки. на выбор.
Третья беда - полное отсутствие статической типизации 24.12.03 15:53  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
> какие могут быть еще новые условия существования - обновление вирусной
> базы или смена сервиспака в W2k/XP ? не смеши.
Или смена ОС или платформы. Скажи, ты дествительно не видел AVP под линух? Только не надо мне говорить про врапперы и абстрагирующий layer. Это попытка создать из асма высокоуровневую среду программирования. Это гораздо лучше сделано в том же C (хотя и тоже не без косяков).

> а вообще-то сабж. :) как честно заплативший. убытки от
> лишних тормозов можно посчитать хоть в блоках rc5, хоть в
> нервах юзеров в моменты сильной нагрузки. на выбор.
У меня уже сейчас есть несколько проектов по ~10000 строк (которые я тяну в одиночку). При этом статическая типизация ой как помогает избавиться от лишних ошибок.

Четвертая беда - чрезмерная избыточность кода, не приводящая однако к его ошибкоустойчивости. Для реализации цикла надо вводить с десяток инструкций, причем цикл так и останется неявным (инкремент-проверка-условный переход ни одно из этих явлений не говорит о непосредственно цикле). Для вызова функции - еще пара десятков. Код растет - его понимаемость снижается -> количество ошибок растет (особенно если учесть предыдущую проблему) - простой юзер недоволен (если до него вообще когда нибудь дойдет проект из хотя бы десятков-сотен тысяч строк, который принципиально пишут на асме).

У асма еще очень много бед.

Повторю для непонятливых: в ПОДАВЛЯЮЩЕМ БОЛЬШИНСТВЕ случаев оптимизирующий компилятор генерирует код не хуже (а зачастую и лучше) человека. В самых крайних случаях есть inline-ассемблер. На спринте (коротких и нетривиальных кусках кода) человек еще может посоревноваться с компилятором, но на марафонных дистанциях (>1000 строк) компилятор всегда побеждает.
back to the user! 26.12.03 11:04  
Автор: jammer <alex naumov> Статус: Elderman
Отредактировано 26.12.03 11:04  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
> > какие могут быть еще новые условия существования -
> обновление вирусной
> > базы или смена сервиспака в W2k/XP ? не смеши.
> Или смена ОС или платформы.

а зачем все время сменять? есть монитор под OS1 и... скажем, OS2 ;) и под платформы. надо что-то дописать - дописывается. переносить смысла не вижу.

> Скажи, ты дествительно не видел AVP под линух?

именно. да я вообще с линуксом дел не имею и стараюсь не иметь... мне компромиссы не по душе. ;) (личная точка зрения)

> Только не надо мне говорить про врапперы и
> абстрагирующий layer. Это попытка создать из асма
> высокоуровневую среду программирования. Это гораздо лучше
> сделано в том же C (хотя и тоже не без косяков).

я и не собирался об этом говорить, я не настолько повернут на девелоперстве. слова твои понятны поодиночке, а в сочетаниях я просто даже не знаю о чем конкретно ты говоришь (только догадываюсь, вспоминая высшую школу и теорию).

> > а вообще-то сабж. :) как честно заплативший. убытки от
> > лишних тормозов можно посчитать хоть в блоках rc5, хоть в
> > нервах юзеров в моменты сильной нагрузки. на выбор.
> У меня уже сейчас есть несколько проектов по ~10000 строк
> (которые я тяну в одиночку). При этом статическая типизация
> ой как помогает избавиться от лишних ошибок.

когда во время компиляции и даже выполнения контролируются допустимые значения для переменных? да кто ж с этим поспорит, только до стандартного стародоброобучающего паскаля си все равно не дотягивает в этом контроле - во всяком случае ощущение правильности исходника у меня отсутствует. си, т.о. не изящен и нечитабелен. объявить int x и присвоить ему 'a' - ну где еще такое проканает, кроме сей. также радует и логический тип задавать целочисленным, опупенный расклад, особенно если вспомнить о разнице выполнения операций NOT, AND, OR, XOR etc над логическими и цифровыми величинами.

> Четвертая беда - чрезмерная избыточность кода, не

я думаю именно на выходе твоего компилятора получается чрезмерная избыточность кода, когда 100 байт инструкций обрамляются 100 килобайтами MFC и прочей срани.

> приводящая однако к его ошибкоустойчивости. Для реализации
> цикла надо вводить с десяток инструкций, причем цикл так и
> останется неявным (инкремент-проверка-условный переход ни
> одно из этих явлений не говорит о непосредственно цикле).

и комментариям ты тоже не обучен? ;)

> Для вызова функции - еще пара десятков. Код растет - его

а, мышление функциями, одна из убогостей сишного взгляда на программирование, в ассемблере нет функций вообще. хотя скорее тут расхождение во мнениях терминологическое, если не думать о том что скорее всего ты забываешь, что результат функции - одна величина некоторого типа, результатом процедуры может быть от нуля до множества величин.

> понимаемость снижается -> количество ошибок растет
> (особенно если учесть предыдущую проблему) - простой юзер
> недоволен (если до него вообще когда нибудь дойдет проект
> из хотя бы десятков-сотен тысяч строк, который
> принципиально пишут на асме).

кстати, про принципиальность написания я ничего не говорил. такие вещи как открытие файла или сообщение об ошибке я не вижу смысла писать на языке низкого уровня. pure asm скорее фетиш и на деле действительно - на мой взгляд - оправдывается только если приносит удовольствие автору.

> Повторю для непонятливых: в ПОДАВЛЯЮЩЕМ БОЛЬШИНСТВЕ случаев
> оптимизирующий компилятор генерирует код не хуже (а

всегда хуже - как минимум из-за обрамления ненужными кусками двоичного кода в объектных и исполняемых файлах, ненужной масштабируемостью, и прочей фигней, которую даже днем с огнем всю не выключишь. я сейчас говорю на примере борландовского и мелкософтовского компилятора, про другие тонкостей не помню.

> зачастую и лучше) человека. В самых крайних случаях есть

ну если настолько неграмотен человек - место ему в вебмастерах, а не в программерах.

> inline-ассемблер.

об этом и речь. про тот же монитор можно уверенно сказать что наиболее популярные проверяющие циклы он крутит не эффективно из-за пренебрежения такой возможностью, лени, а возможно и простой неграмотности разработчиков.

> на марафонных дистанциях (>1000 строк) компилятор всегда побеждает.

в скорости и комфорте разработки, но не в результате.

типичная беда нашего времени - сделать все впопыхах. сграбить фильм с DVD, неэффективно пожать его в divx, криво перевести название на русский язык и записать его траснлитом в имя файла - утверждая что компилятор всегда побеждает. смешно.

настолько же нелепо делать гуй из монитора, которому сервисом положено было бы работать, а темы XP лепить в виде сервиса.

имхо.

PS. ну и опять же повторюсь - мы только о проблемах девелоперов рассуждаем, а проблема юзера в том что он зазря гоняет байтики в памяти по причине ленивой криворукости девелопера. я в своих попытках что-то сдевелопить поражаюсь быстродействию таких машин на которых AVP Monitor будет прорисывывать свои FUCKING иконки минут несколько при разворачивании гуевого окна. мне иконки не нужны, и регедит тоже, я бы с большим удовольвием отредактировал конфиг фаром - по образу и подобию того как я редактирую фаром конфиги freebsd.
Есть закон неограниченности потребностей. В том плане, что... 26.12.03 14:53  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
> а зачем все время сменять? есть монитор под OS1 и...
> скажем, OS2 ;) и под платформы. надо что-то дописать -
> дописывается. переносить смысла не вижу.
Есть закон неограниченности потребностей. В том плане, что потребности постоянно меняются. И именно потому, что можно убить два года на проект средней крупности, а он уже будет не нужен появилось eXtreme Programming. Это не только в программировании есть. Любая система, которая пытается останвится в развитии очень быстро начинает деградировать.

> именно. да я вообще с линуксом дел не имею и стараюсь не
> иметь... мне компромиссы не по душе. ;) (личная точка
> зрения)
Ой ли. Компромиссы не по душе. А по моему обычный снобизм фрибсд-шников. :-) Я тут недавно ссылку кидал с реальными бенчмарками фри и линуха. Не в пользу BSD-систем вообще кстати (хотя фря из BSD систем действительно оказалась лучше всех)

> я и не собирался об этом говорить, я не настолько повернут
> на девелоперстве. слова твои понятны поодиночке, а в
Я тоже не повернут, между прочим. Не такие уж это и сложные понятия. Ну да ладно. :-)


> когда во время компиляции и даже выполнения контролируются
> допустимые значения для переменных? да кто ж с этим
> поспорит, только до стандартного стародоброобучающего
> паскаля си все равно не дотягивает в этом контроле - во
> всяком случае ощущение правильности исходника у меня
> отсутствует. си, т.о. не изящен и нечитабелен. объявить int
> x и присвоить ему 'a' - ну где еще такое проканает, кроме
> сей. также радует и логический тип задавать целочисленным,
> опупенный расклад, особенно если вспомнить о разнице
> выполнения операций NOT, AND, OR, XOR etc над логическими и
> цифровыми величинами.
Написал же. Что и там не без косяков, большинство из которых запросто обходятся в самом C, а в C++ уже внесены в язык.

> я думаю именно на выходе твоего компилятора получается
> чрезмерная избыточность кода, когда 100 байт инструкций
> обрамляются 100 килобайтами MFC и прочей срани.
Не обязательно линковаться с MFC, необязательно линковаться даже с рантаймом.

> и комментариям ты тоже не обучен? ;)
Ага. Комментировать каждый цикл, если это можно выразить средствами самого языка. Кстати, все более-менее сведущие программисты говорят, что этот вид комментариев - один из самых плохих. Не стоит комментировать то, что выражено в самом языке:
a = b + c; // Заносим в a сумму b и c

---

> а, мышление функциями, одна из убогостей сишного взгляда на
> программирование, в ассемблере нет функций вообще. хотя
> скорее тут расхождение во мнениях терминологическое, если
> не думать о том что скорее всего ты забываешь, что
> результат функции - одна величина некоторого типа,
> результатом процедуры может быть от нуля до множества
> величин.
Точно так же деление вызвов на процедуры и функции - одна из убогостей паскалевского взгляда на вещи. А функциональная декомпозиция - всего лишь один из шагов в ЭВОЛЮЦИИ методологии программирования. Скажу лишь, что вся эта эволюция сводится к уменьшению зависимостей между частями программы. В объектной декомпозиции связей еще меньше.

> фетиш и на деле действительно - на мой взгляд -
> оправдывается только если приносит удовольствие автору.
Вот с этим, пожалуй, соглашусь.

> всегда хуже - как минимум из-за обрамления ненужными
> кусками двоичного кода в объектных и исполняемых файлах,
Либы можно не подключать, стековые фреймы не генерировать. Тогда C просто превратится в асм. А вот асм в C не превратится никогда.

> ненужной масштабируемостью, и прочей фигней, которую даже
> днем с огнем всю не выключишь. я сейчас говорю на примере
> борландовского и мелкософтовского компилятора, про другие
> тонкостей не помню.
Не уверен, что Вы знаете тонкости борландовского и мелкософтовского компилятора, раз говорите такое.

> > зачастую и лучше) человека. В самых крайних случаях
> есть
>
> ну если настолько неграмотен человек - место ему в
> вебмастерах, а не в программерах.
Ой ли. Паровать инструкции и выравнивать по границе кеш-строки в 100000 строках ИМХО лучше это удовольствие оставить компилятору. А ведь это МИНИМУМ, который делает оптимизирующий компилятор. Мне когда то пытались привести в пример VTune, который ищет возможности для оптимизации и говорит человеку, что подправить. Вот только до сих пор не понимаю зачем в этой цепочке человек.

> > inline-ассемблер.
> об этом и речь. про тот же монитор можно уверенно сказать
> что наиболее популярные проверяющие циклы он крутит не
> эффективно из-за пренебрежения такой возможностью, лени, а
> возможно и простой неграмотности разработчиков.
А вот тут не согласен. Преждевременная оптимизация - корень всех бед. НАЧИНАТЬ ручную оптимизацию следует только после того, как программа основательно погонялась под профайлером и выявлены РЕАЛЬНЫЕ бутылочные горлышки.

> > на марафонных дистанциях (>1000 строк) компилятор
> всегда побеждает.
>
> в скорости и комфорте разработки, но не в результате.
Именно в результате.

> типичная беда нашего времени - сделать все впопыхах.
> сграбить фильм с DVD, неэффективно пожать его в divx, криво
> перевести название на русский язык и записать его
> траснлитом в имя файла - утверждая что компилятор всегда
> побеждает. смешно.
Эх. Чем-то мне эта дискуссия напоминает Urix-а. Тот тоже любил заявлять что со времен PDP ничего хорошего не придумали. И все только деградирует. Смею предположить что Вы уже весьма немолоды и как следствие боитесь новизны.

> настолько же нелепо делать гуй из монитора, которому
> сервисом положено было бы работать, а темы XP лепить в виде
> сервиса.
Не будет спорить о необходимости гуя вообще. Скажу лишь, что XP, где графическая подсистема вынесена в ядро, работает все таки быстрее чем X.

> PS. ну и опять же повторюсь - мы только о проблемах
> девелоперов рассуждаем, а проблема юзера в том что он зазря
> гоняет байтики в памяти по причине ленивой криворукости
> девелопера. я в своих попытках что-то сдевелопить поражаюсь
Ленивость и криворукость девелопера между прочим никак не относится к удобству среды разработки. Можно даже сказать наоборот: чем удобнее работается девелоперу, тем лучше будет юзеру в конце концов.

> тоже, я бы с большим удовольвием отредактировал конфиг
> фаром - по образу и подобию того как я редактирую фаром
> конфиги freebsd.
Поздравляю. Во первых не забывайте о позиционировании. Во вторых вспомните, сколько всего вынесено в реестр (опять таки не станем спорить зачем столько настроек) и подумайте с какой скоростью выполнялся бы поиск по текстовой базе. Реестр - это база данных. А БД для эффективной работы просто обязана быть бинарной.
проблемы девелоперов быстро превращаются в проблемы юзеров 26.12.03 13:23  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка> <обсуждение закрыто>
Раз и навсегда написанные программы - это идеальный случай. Меняются условия, меняются требования, программу нужно обновлять, причесывать, поддерживать. Самый идеальный код на ассемблере начиная с какого-то уровня сложности проекта развалится точно так же, как кривая поделка на васике или дельфи, и исправить в нем что-то станет просто нереально.
или начиная с NT4 ничего не меняется - или я что-то пропустил? 26.12.03 13:45  
Автор: jammer <alex naumov> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
это на тему монитора.
NT, Linux и многое прочее на С написано 26.12.03 13:59  
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 26.12.03 14:06  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
Есть конечно фрагменты на асме, но в основном - С. Единственная ОС писанная на чистом асме которую я знаю - Menuet OS. Причем я бы не сказал что она очень шустрая (для своих размеров) да и существует она тока для х86. Что касается скорости асма - во первых никто тебя не вынуждает использовать тот же MFC или даже вообще пользоваться стандартными функциями С. Во вторых трудновато тебе будет держать в памяти тайминги всех инструкций, расставлять их так чтобы они работали максимально быстро на современных процессорах с ихним кэшированием и предсказанием переходов. Этим как раз прекрасно занимается компилятор тогоже С.
наверное даже компилятор С написан на С? ваау. это прямо таки pkunzip.zip! ;) 26.12.03 15:10  
Автор: jammer <alex naumov> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Есть конечно фрагменты на асме, но в основном - С.

я блин про "фрагменты" и говорил. полсекунды или секунду будет выполняться подпрограмма, которая выполняется раз в сутки, меня абсолютно not a bird. просьба: читать если меня, то ВНИМАТЕЛЬНО и ничего НЕ ДОДУМЫВАТЬ и не фантазировать, не подставлять свой субъективный контекст - вы заведомо ошибетесь и сознательно меня не поймете.

> касается скорости асма - во первых никто тебя не вынуждает
> использовать тот же MFC или даже вообще пользоваться
> стандартными функциями С.

да вообще этим нечитабельным языком, только в котором и возможны ляпсусы типа (см. ссылку ниже).

> Во вторых трудновато тебе будет
> держать в памяти тайминги всех инструкций, расставлять их
> так чтобы они работали максимально быстро на современных
> процессорах с ихним кэшированием и предсказанием переходов.
> Этим как раз прекрасно занимается компилятор тогоже С.

в памяти нет смысла держать. занимается не настолько прекрасно как тебе кажется, и простое дизассемблирование тебя в этом легко убедит. напиши int x = 10 и собери екзешник, вместо 10 байт у тебя получится 100К.

указанный Ktirf-ом глюк
Ты прав, GCC написан на С :) 26.12.03 15:37  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> > Есть конечно фрагменты на асме, но в основном - С.
> я блин про "фрагменты" и говорил. полсекунды или секунду
> будет выполняться подпрограмма, которая выполняется раз в
> сутки, меня абсолютно not a bird. просьба: читать если
> меня, то ВНИМАТЕЛЬНО и ничего НЕ ДОДУМЫВАТЬ и не
> фантазировать, не подставлять свой субъективный контекст -
> вы заведомо ошибетесь и сознательно меня не поймете.
На асме в основном делаются фрагменты работающие с железом напрямую. Ввод вывод в порты имхо на асме делать просто легче. А насчет скорости - расскажу легенду которую мне самому как то рассказывали. Был один чел у нас который весьме нехило шарил в асме. И решил он написать небольшую программку (с циклом, считала чтото) с целью обойти в скорости аналогичный код на С скомпиленный в Watcom C. Чел обломался.

> > касается скорости асма - во первых никто тебя не
> вынуждает
> > использовать тот же MFC или даже вообще пользоваться
> > стандартными функциями С.
>
> > Во вторых трудновато тебе будет
> > держать в памяти тайминги всех инструкций, расставлять
> их
> > так чтобы они работали максимально быстро на
> современных
> > процессорах с ихним кэшированием и предсказанием
> переходов.
> > Этим как раз прекрасно занимается компилятор тогоже С.
>
> в памяти нет смысла держать. занимается не настолько
> прекрасно как тебе кажется, и простое дизассемблирование
> тебя в этом легко убедит. напиши int x = 10 и собери
> екзешник, вместо 10 байт у тебя получится 100К.
Получится порядка 1 кб. Тут недавно пролетала мессага о том как отключить стандартные Сшные либы в которых содержатся такие стандартные функции как printf, malloc, и прочее. А 1кб - это изза PE заголовка. 10байтный PE ехешник ты никак не сможешь сделать. Кстати ничего страшного даже в том что в ехешнике лежит код который и выполняться то никогда не будет. Механизм запуска приложений в виндах таков, что если участок кода не юзается то он не будет никогда загружен в память.

> да вообще этим нечитабельным языком, только в котором и
> возможны ляпсусы типа (см. ссылку ниже).
В асме таких ляпусов может быть намноого больше. xor eax,eax вместо mov eax,edx в коде состоящем и гораздо большего количества строк мог бы привести к примерно такому же эффекту.
Ага. И это называется раскрутка компилятора. 26.12.03 15:31  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
Первая версия пишется на чем угодно (хоть на бейсике). Собирается компилятор. Все следующие версии компилятора пишутся на нем самом. И VC, и gcc.

> я блин про "фрагменты" и говорил. полсекунды или секунду
> будет выполняться подпрограмма, которая выполняется раз в
> сутки, меня абсолютно not a bird. просьба: читать если
> меня, то ВНИМАТЕЛЬНО и ничего НЕ ДОДУМЫВАТЬ и не
> фантазировать, не подставлять свой субъективный контекст -
> вы заведомо ошибетесь и сознательно меня не поймете.
Гы. Ну знамо дело. Все в го*не один ты д'Артаньян. "вы заведомо ошибаетесь" вот это вот как раз и есть подстановка к нам своего субъективного контекста.

> > касается скорости асма - во первых никто тебя не
> вынуждает
> > использовать тот же MFC или даже вообще пользоваться
> > стандартными функциями С.
>
> да вообще этим нечитабельным языком, только в котором и
> возможны ляпсусы типа (см. ссылку ниже).
Да уж. В асме таких ляпсусов не бывает. Там просто можно побочноый эффект изменения какого нибудь флага использовать. Или я видел прикол (еще под досом): в кеш загружалась строка, в которой есть одно обращение к памяти и один безусловный переход. Причем обращение к памяти - это запись адреса перехода следующей инструкции. Но так как инструкция уже в кеше (или даже прошла пол-конвейера), переход осуществлялся по старому адресу. А отладчики всегда уходили по новому.
Не надо говорить, что инструмент плохой, только потому, что вы не умеете им пользоваться. После некоторого опыта работы (не сильно большого к слову), программист уже никогда случайно не напишет вместо сравнения присвоение.

Чтобы не переливать из пустого в порожнее, давайте я вам попросим кого нибудь написать реализацию какого-нибудь нетривиального алгоритма на C и на асме (можно даже откомпилировать исходную программу в асм). И дать без комментариев разным людям. Вы действительно уверены, что человек, которому попадется асм без комментариев столкнется с меньшими проблемами при чтении, чем С-шник. Если да, то мне просто не о чем с Вами больше говорить. Таких людей не прошибешь НИКАКИМИ аргументами. Тут уже был такой, который обвинял меня в ошибках (по его мнению) в СТАНДАРТЕ C++.

> > Во вторых трудновато тебе будет
> > держать в памяти тайминги всех инструкций, расставлять
> их
> > так чтобы они работали максимально быстро на
> современных
> > процессорах с ихним кэшированием и предсказанием
> переходов.
> > Этим как раз прекрасно занимается компилятор тогоже С.
>
> в памяти нет смысла держать. занимается не настолько
> прекрасно как тебе кажется, и простое дизассемблирование
> тебя в этом легко убедит. напиши int x = 10 и собери
> екзешник, вместо 10 байт у тебя получится 100К.
Да? А может поспорим, что я могу написать на C программу, которая будет занимать минимальный для данного формата объем? А может заглянете в раздел FAQ? Вещи-то довольно простые и я удивлен, что Вы их не знаете.

ЗЫ: Кстати, программа из int x = 10 не будет занимать вообще ничего, т.к. компилятор соптимизирует неиспользуемую переменную. Если же написать volatile int x = 10, то программа не будет содержать ни одной ИСПОЛНЯЕМОЙ инструкции - только сегмент данных, в котором будет содержаться переменная x, проинициализированная значением 10.
1  |  2 >>  »  






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


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