информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Задрал... Штраф за флейм! 06.01.04 06:49  Число просмотров: 1389
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
Что против прогресса-то идти?

Вот ты тут с пеной у рта доказываешь, что стетоскоп лучше томографа... Для каждого инструмента — своё применение... Что со стетоскопом хороший доктор совершит меньше ошибок, чем другой доктор, используя томограф...

Ассемблер появился с самого начала. Для того, чтобы упростить программирование в машинных кодах. И он реально нужен до сих пор, никто не спорит... Но только там, где он реально нужен ;-)
<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-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach