Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
Третья беда - полное отсутствие статической типизации 24.12.03 15:53 Число просмотров: 1745
Автор: amirul <Serge> Статус: The Elderman
|
> какие могут быть еще новые условия существования - обновление вирусной > базы или смена сервиспака в W2k/XP ? не смеши. Или смена ОС или платформы. Скажи, ты дествительно не видел AVP под линух? Только не надо мне говорить про врапперы и абстрагирующий layer. Это попытка создать из асма высокоуровневую среду программирования. Это гораздо лучше сделано в том же C (хотя и тоже не без косяков).
> а вообще-то сабж. :) как честно заплативший. убытки от > лишних тормозов можно посчитать хоть в блоках rc5, хоть в > нервах юзеров в моменты сильной нагрузки. на выбор. У меня уже сейчас есть несколько проектов по ~10000 строк (которые я тяну в одиночку). При этом статическая типизация ой как помогает избавиться от лишних ошибок.
Четвертая беда - чрезмерная избыточность кода, не приводящая однако к его ошибкоустойчивости. Для реализации цикла надо вводить с десяток инструкций, причем цикл так и останется неявным (инкремент-проверка-условный переход ни одно из этих явлений не говорит о непосредственно цикле). Для вызова функции - еще пара десятков. Код растет - его понимаемость снижается -> количество ошибок растет (особенно если учесть предыдущую проблему) - простой юзер недоволен (если до него вообще когда нибудь дойдет проект из хотя бы десятков-сотен тысяч строк, который принципиально пишут на асме).
У асма еще очень много бед.
Повторю для непонятливых: в ПОДАВЛЯЮЩЕМ БОЛЬШИНСТВЕ случаев оптимизирующий компилятор генерирует код не хуже (а зачастую и лучше) человека. В самых крайних случаях есть inline-ассемблер. На спринте (коротких и нетривиальных кусках кода) человек еще может посоревноваться с компилятором, но на марафонных дистанциях (>1000 строк) компилятор всегда побеждает.
|
<site updates>
|
![](/img/dot.gif) |
Ох... 03.12.03 01:42
Автор: jammer <alex naumov> Статус: Elderman
|
не внесет ли сей ученый муж в свой списочек корову? я все чаще и чаще этого побаиваюсь.
|
![](/img/dot.gif) | ![](/img/dot.gif) |
Ну вот оно и начинается 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 чешем репу?
|
![](/img/dot.gif) |
Здравствуйте,
02.12.03 02:27
Автор: Serge3leo Статус: Незарегистрированный пользователь
|
Здравствуйте,
Всё понимаю кроме следующего предложения:
"..., но не более того. И больше всего умиляют его попытки представить себя как специалиста в области безопасности)."
Оно как-то совершенно не связанно, ни с обсуждаемой проблемой, ни с остальными частями статьи.
Или есть соображения о низком уровне профессионализма сотрудников "Лаборатории Касперского" и у них следует отозвать лицензию ГосТехКоммиссии на разработку, производство, распространение и поддержку. Или быть может ПО от "Лаборатории Каспреского" не безопасно и у них следует отозвать сертификаты ГосТехКоммиссии на те или иные продукты?
Вероятно, и продукты хорошие, и специалисты хорошие, просто рабочие моменты, связанные с совместимостью разных продуктов.
P.S.
Следует заметить, что ссылки по теме на http://www.kaspersky.ru/ не хватает.
|
![](/img/dot.gif) | ![](/img/dot.gif) |
hi 03.12.03 01:31
Автор: jammer <alex naumov> Статус: Elderman
|
> Всё понимаю кроме следующего предложения: > "..., но не более того. И больше всего умиляют его попытки > представить себя как специалиста в области безопасности)." > Оно как-то совершенно не связанно, ни с обсуждаемой > проблемой, ни с остальными частями статьи.
Женька лапы не только к защите от вирусов, а вообще к защите как таковой тянет - это не секрет.
> Или есть соображения о низком уровне профессионализма
однозначно есть. начать с таких мелочей, как нормальный приоритет сканера по умолчанию и тормознутый монитор (на Си чтоли написан, или вообще на бейсике?). ключевые файлы - так просто курам на смех. не могу сказать что я особо много юзал касперского, но в серьезных конторах я замечаю что его сносят и ставят NAV например. повод задуматься или нет?
> сотрудников "Лаборатории Касперского" и у них следует > отозвать лицензию ГосТехКоммиссии на разработку, > производство, распространение и поддержку. Или быть может > ПО от "Лаборатории Каспреского" не безопасно и у них
видимо, раз он любит корежить безобидные файлы, никак не безопасно.
> следует отозвать сертификаты ГосТехКоммиссии на те или иные > продукты?
это не нам решать. это бизнес ;) - инвестиции, клиенты, продажи, конкуренты, налоги, отстегивания. знаю я примерно как это делается. я даже в коммерческом вузе работал 2 года, там похожий расклад, все просто.
вобщем я к тому что к делу это все не относится. сертификат о качестве софта говорит весьма мало.
> Вероятно, и продукты хорошие, и специалисты хорошие, просто > рабочие моменты, связанные с совместимостью разных продуктов.
Женьке все прямо было сказано, ан нет, Женька уперся рогом.
честно сказать, есть у меня подозрения, что он из тех, кто любит пускать пыль в глаза лапшой на уши на тему собственной супер-пупер важности, и приводить тщательно отфильтрованный список аргументов, скрывая невыгодные. мне такой подход к делу никогда не нравился.
> Следует заметить, что ссылки по теме на > http://www.kaspersky.ru/ не хватает.
а это, видимо, либо и так понятно, либо следует написать вебмастеру security.nnov.ru
а хватает ли ссылки писать сюда размах!
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
Оффтоп: вопрос по поводу причин тормознутости 03.12.03 11:23
Автор: amirul <Serge> Статус: The Elderman
|
> приоритет сканера по умолчанию и тормознутый монитор (на Си > чтоли написан, или вообще на бейсике?). ключевые файлы - На C получаются тормозные проги или я чего то неправильно понял (насчет бейсика спорить не стану)?
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
asm forever :| 06.12.03 07:06
Автор: jammer <alex naumov> Статус: Elderman
|
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
Одна беда - непереносим. То есть вообще нинасколько. 06.12.03 14:21
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
"бед"-то много 24.12.03 15:08
Автор: jammer <alex naumov> Статус: Elderman
|
время на разработку, отладку и модификацию существенно больше.
непереносимость? между чем и чем (если про монитор говорим) - уточните.
только клиенты платят как раз деньги для того чтобы кривописаки в авп работали, а не писульки на сях через клипбоард копировали. лично мне графический интерфейс для монитора и засирание места в трее не нужны - а скорость работы файл-сервера куда важнее.
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
Вторая беда - рефакторинг невозможен практически 08.12.03 13:07 [Ktirf, JINN]
Автор: amirul <Serge> Статус: The Elderman
|
Уже не реюз, как я писал раньше. Для того, что я имел в виду есть другое более умное слово :-)
Собственно подгонка кода под новые условия существования - БОЛЬШАЯ проблема для асма. И на пару порядков меньшая для C
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
а давайте немного уйдем от девелоперских проблем. представим себе: я - юзер 24.12.03 15:23
Автор: jammer <alex naumov> Статус: Elderman
|
> Уже не реюз, как я писал раньше. Для того, что я имел в > виду есть другое более умное слово :-) > > Собственно подгонка кода под новые условия существования - > БОЛЬШАЯ проблема для асма. И на пару порядков меньшая для C
какие могут быть еще новые условия существования - обновление вирусной базы или смена сервиспака в W2k/XP ? не смеши.
если хороший хирург поможет плохому танцору - разница в размере проблемы окажется куда меньшей.
а вообще-то сабж. :) как честно заплативший. убытки от лишних тормозов можно посчитать хоть в блоках rc5, хоть в нервах юзеров в моменты сильной нагрузки. на выбор.
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
Третья беда - полное отсутствие статической типизации 24.12.03 15:53
Автор: amirul <Serge> Статус: The Elderman
|
> какие могут быть еще новые условия существования - обновление вирусной > базы или смена сервиспака в W2k/XP ? не смеши. Или смена ОС или платформы. Скажи, ты дествительно не видел AVP под линух? Только не надо мне говорить про врапперы и абстрагирующий layer. Это попытка создать из асма высокоуровневую среду программирования. Это гораздо лучше сделано в том же C (хотя и тоже не без косяков).
> а вообще-то сабж. :) как честно заплативший. убытки от > лишних тормозов можно посчитать хоть в блоках rc5, хоть в > нервах юзеров в моменты сильной нагрузки. на выбор. У меня уже сейчас есть несколько проектов по ~10000 строк (которые я тяну в одиночку). При этом статическая типизация ой как помогает избавиться от лишних ошибок.
Четвертая беда - чрезмерная избыточность кода, не приводящая однако к его ошибкоустойчивости. Для реализации цикла надо вводить с десяток инструкций, причем цикл так и останется неявным (инкремент-проверка-условный переход ни одно из этих явлений не говорит о непосредственно цикле). Для вызова функции - еще пара десятков. Код растет - его понимаемость снижается -> количество ошибок растет (особенно если учесть предыдущую проблему) - простой юзер недоволен (если до него вообще когда нибудь дойдет проект из хотя бы десятков-сотен тысяч строк, который принципиально пишут на асме).
У асма еще очень много бед.
Повторю для непонятливых: в ПОДАВЛЯЮЩЕМ БОЛЬШИНСТВЕ случаев оптимизирующий компилятор генерирует код не хуже (а зачастую и лучше) человека. В самых крайних случаях есть inline-ассемблер. На спринте (коротких и нетривиальных кусках кода) человек еще может посоревноваться с компилятором, но на марафонных дистанциях (>1000 строк) компилятор всегда побеждает.
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
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.
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
Есть закон неограниченности потребностей. В том плане, что... 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. Поздравляю. Во первых не забывайте о позиционировании. Во вторых вспомните, сколько всего вынесено в реестр (опять таки не станем спорить зачем столько настроек) и подумайте с какой скоростью выполнялся бы поиск по текстовой базе. Реестр - это база данных. А БД для эффективной работы просто обязана быть бинарной.
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
проблемы девелоперов быстро превращаются в проблемы юзеров 26.12.03 13:23
Автор: dl <Dmitry Leonov>
|
Раз и навсегда написанные программы - это идеальный случай. Меняются условия, меняются требования, программу нужно обновлять, причесывать, поддерживать. Самый идеальный код на ассемблере начиная с какого-то уровня сложности проекта развалится точно так же, как кривая поделка на васике или дельфи, и исправить в нем что-то станет просто нереально.
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
или начиная с NT4 ничего не меняется - или я что-то пропустил? 26.12.03 13:45
Автор: jammer <alex naumov> Статус: Elderman
|
это на тему монитора.
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
NT, Linux и многое прочее на С написано 26.12.03 13:59
Автор: Killer{R} <Dmitry> Статус: Elderman Отредактировано 26.12.03 14:06 Количество правок: 1
|
Есть конечно фрагменты на асме, но в основном - С. Единственная ОС писанная на чистом асме которую я знаю - Menuet OS. Причем я бы не сказал что она очень шустрая (для своих размеров) да и существует она тока для х86. Что касается скорости асма - во первых никто тебя не вынуждает использовать тот же MFC или даже вообще пользоваться стандартными функциями С. Во вторых трудновато тебе будет держать в памяти тайминги всех инструкций, расставлять их так чтобы они работали максимально быстро на современных процессорах с ихним кэшированием и предсказанием переходов. Этим как раз прекрасно занимается компилятор тогоже С.
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
наверное даже компилятор С написан на С? ваау. это прямо таки pkunzip.zip! ;) 26.12.03 15:10
Автор: jammer <alex naumov> Статус: Elderman
|
> Есть конечно фрагменты на асме, но в основном - С.
я блин про "фрагменты" и говорил. полсекунды или секунду будет выполняться подпрограмма, которая выполняется раз в сутки, меня абсолютно not a bird. просьба: читать если меня, то ВНИМАТЕЛЬНО и ничего НЕ ДОДУМЫВАТЬ и не фантазировать, не подставлять свой субъективный контекст - вы заведомо ошибетесь и сознательно меня не поймете.
> касается скорости асма - во первых никто тебя не вынуждает > использовать тот же MFC или даже вообще пользоваться > стандартными функциями С.
да вообще этим нечитабельным языком, только в котором и возможны ляпсусы типа (см. ссылку ниже).
> Во вторых трудновато тебе будет > держать в памяти тайминги всех инструкций, расставлять их > так чтобы они работали максимально быстро на современных > процессорах с ихним кэшированием и предсказанием переходов. > Этим как раз прекрасно занимается компилятор тогоже С.
в памяти нет смысла держать. занимается не настолько прекрасно как тебе кажется, и простое дизассемблирование тебя в этом легко убедит. напиши int x = 10 и собери екзешник, вместо 10 байт у тебя получится 100К.
указанный Ktirf-ом глюк
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
Ты прав, 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 в коде состоящем и гораздо большего количества строк мог бы привести к примерно такому же эффекту.
|
![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) | ![](/img/dot.gif) |
Ага. И это называется раскрутка компилятора. 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.
|
|
|