desperius
0
Ну тогда напишите вычисления, с помощью которых у Вас получился такой результат…
desperius
+1
Видимо уже очень поздно и я что-то упускаю… У Вас есть байт в памяти со значением 00010010 = oct 22 = dec 18 = hex 12. Что не так?
desperius
0
Ну давайте сверятся… Я выбрал режим Programmer. Переключил радиокнопку на hex. Набрал 12 и переключил радиокнопку на bin, что приводит к конвертации числа в другой тип. Согласно этому, Ваш вариант — это А или же 10…
desperius
0
Извините, но калькулятор в Windows с Вами не согласен :)
desperius
0
Буду признателен, если укажите на ошибки. Большая просьба в ЛС.
desperius
+1
Буду только благодарен, если укажите в ЛС и обязательно исправлю!
desperius
0
Большое спасибо, что все-таки откликнулись, но я уже решил эту проблему!
desperius
0
Как большой поклонник игры Divine Divinity, не могу не подметить, что в Beyond Divinity студия Larian наплевательски отнеслась к критериям U и E, и что-то не сильно похоже, что это было сделано в пользу какого-то компромиса…
desperius
0
Сложность роли не играет. Главное получить хоть какое-то вменяемое решение!
desperius
0
Удалять вершины — не совсем подходит, потому как можем, даже при существовании верного пути, его себе отрезать, если придем в промежуточную точку заведомо неверным маршрутом…
desperius
0
Плохо поняли условие? Имеется ввиду, что есть определенное место (вершина графа), через которое нужно обязятельно пройти по пути к выходу (еще какая-то определенная вершина графа), но вершини пути не должны повторяться дважды!
desperius
0
Может кто подскажет, как модернизировать этот алгоритм так, чтобы он искал путь к выходу, который будет проходить через определенную точку в лабиринте и при этом не будет проходить через одну и туже ячейку дважды. Буду весьма признателен!
desperius
+6
И теперь сидите в недоумении и думаете, почему все анекдоты плюсуют, а вам минусы? :)
desperius
0
Огромное Вам спасибо! Теперь все прояснилось!
desperius
0
Извините за тупость и глупый вопрос, но разложите кто-нибудь более детально формулу получения из 1.01e-3 числа 0,15625. Очень хочется разобраться во всем, но своих мозгов что-то не хватает…
desperius
0
К сожалению, я лиш дублирую оформление автора… Здесь могу лиш предложыть заменить название на предложенное моим коллегой — «Спагетти-статья о спагетти-коде»!
desperius
+1
Все, что смог...
1.
> Правильно сказать так: В большинстве инструкций, в т. ч. использующих 2 операнда хотя бы один из них должен являться регистром. В других случаях операнд может быть памятью или указан непосредственно в инструкции, но вариант с регистром всегда исполняется заметно быстрее.

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

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

2.
> К слову, я вообще не профессионал, и моя деятельность не имеет к ИТ никакого отношения. Впрочем, в юношестве, я разрабатывал один проект, и, из-за юношеского-же максимализма делал его на АСМ. Это было адово, когда файл разросся до 10к строк кода. Я использовал только переходы (аналог на C — go to), и попробуйте представить, какой там был спагетти код. И конечно-же (кто-бы мог подумать?) поддерживать программу стало сложнее. Нестройные ряды пользователей до сих пор поминают меня незлым тихим словом и лелеют надежду, что я выпушу исправления…

Все еще сильны в этой области, а значит в какой то мере профессионал. Да и такой бесценный опыт за плечами!

7.
> Да, OllyDbg — только под windows, как уже и написали ниже. Но она действительно крутая.

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

Что ж, пытался оправдать автора (да и себя), как мог! :)
desperius
0
Возможно, даже совсем близко... :)
1.
> Ну нет же. В статье говорится — используем регистры, потому что так быстрее. На самом деле по другому просто нельзя.

Ну здесь похоже дело в моей формулировке. Более точнее перевод может звучать как: «Скорость доступа к регистрам очень высокая и в них часто хранятся операнды арифметических и логических операций», что вроде и не противоречит тому, что говорите Вы (хотя может что и противоречит)…

2.
> Вот именно, так поступает большинство компиляторов. А не «так было и будет всегда».

Ну это начинающему еще предстоит узнать, в контексте пунктов 4 и 5, с коими я полностю соглашусь. Разбиратся придется и чем детальнее, тем лучше. Но не все сразу. Вам, как профессионалу, эта статья просто таки пестрит оплошностями, а вот мне, например, с не таким высоким уровнем низкоуровневого програмирования она была достаточно информативна. Очевидно, что чем дальше в лес… Ну Вы знаете…

7.

Мне кажется, здесь своеобразный порог и для каждого свой. Но азы есть азы… И все равно начавший с GDB человек рано или поздно будет искать инструмент с бОльшими возможностями. Тот же Olly… Вы уже начали с него, что плюс для Вас же… И, к стати, как я вижу он только для Windows?
desperius
0
Нужно понемногу сводить число обсуждаемого к минимуму :)
1.
> В x86-32 для инструкции ADD допустимы следующие операнды: reg,reg / mem,reg / reg,mem / reg,imm / mem,imm / accum,imm. Вариант mem,mem не предусмотрен, т. е. что бы сложить две переменные — хотя бы одну надо загрузить в регистр.

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

2.
> Бла-бла-бла описание вариантов работы с процедурами, бла-бла-бла описание работы со стеком и локальными переменными, бла-бла-бла большинство компиляторов так и поступают. И Вывод: при таком использовании действительно, BP будет иметь большее значение, чем SP. Вот с этим конечно нельзя не согласиться. С другой стороны компилятор X вообще делает все по другому, и уже такое утверждение не справедливо. Просто нельзя так обобщать.

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

3.
> По ссылке «This article describes the calling conventions used on the x86 architecture». Тут я действительно придрался к формулировке, но в самой архитектуре как таковой соглашения и нет.

Вас понял. Поправил формулировку!

4. и 5.
> В Ъ АСМ нет понятия переменной. Есть понятие данных (памяти) и меток/аддрессов, по которым осуществляется доступ. Далее, стек — точно такая же память, и если посмотреть, как он работает, то просто станет очевидным, и почему перезаписываются локальные переменные, и почему в них может содержаться мусор, и почему не меняются сами собой статичные переменные. И про память, и про секцию инициализированных данных станет все ясно.

Я уже говорил, что для автора ассемблер здесь инструмент, а разбираемся мы в С, поэтому и оперируем понятиями С.

6.
> В GDB перед именем переменных идет символ $, а в синтаксисе AT&T — символ %

Поправил на что-то среднее :)

7.
> Вот и зря. В ней все просто, слева листинг кода, справа — регистры, внизу память и стек. И все это можно запускать пошагово, и видеть, как после какой инструкции изменилось состояние, вот например описание www.cracklab.ru/faq/OllyDbg

С точки зрения профессионального использования — Вы безусловно правы. Но чтобы ознакомиться на маленькой программке лучше все же GDB. Ввел простенькую команду — получил наглядный результат — осознал происходящее.
desperius
0
Что ж, очевидно Вы хотите, чтобы я отдувался за автора. Раз уж я запостил эту статью, то сделаю, что в моих силах :)

> Скорость доступа к регистрам очень высокая и именно из-за этого в них часто хранятся операнды арифметических и логических операций.

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

Здесь разве попрошу пояснить более детально…

> Регистр %rbp всегда имеет высшее значение нежели %rsp

> Нет, регистр имеет то значение, которое в него поместили (или изменили соответствующими командами).

Очевидно имеется ввиду адрес участка памяти, который там хранится, и если его не менять, то традиционно он выше у первого. Если же значение регистра изменено руками, то глупо ожидать магии :)

> Соглашение о вызовах, в архитектуре x86 гласит, что возвращаемые функцией значения хранятся в регистре %eax

> Нет, в архитектуре x86 нет соглашения о вызовах, и его не может быть в архитектуре. В архитектуре есть набор команд, которым можно реализовать вызовы процедуры. Причем, возвращение значения в регистре EAX вообще ничем не обусловлено, с таким-же успехом его можно было-бы возвращать в EBX, участке памяти и на на стеке. С другой стороны, момент о типах вызовов и передаче аргументов вообще упущен в статье.

Я так понимаю, вот это самое несуществующее соглашение. Возможно стоит исправить на «Соглашение о вызовах для архитектуры x86»…

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

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

Здесь раздел Scope однозначно нам все объясняет…

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

> Нет, она сохраняет свое значение потому, что нет инструкции, которая бы меняла его (вне процедуры). Стек аддрессует точно такую же память, и к ней применимы все (почти) правила, которые и применимы к памяти, которая считается секцией данных (в семействе Windows, никогда не разбирая ядро других ОС). Впрочем, говорить об этом в статье без объяснения локальных переменных, вызовов процедур и прочего смысла нет.

Что Вы подразумеваете под «нет инструкции». Если воздействовать на этот участок памяти руками, то смотрите ответ выше, касающейся регистров.

> Также Вы можете обратить внимание, что GDB устанавливает значения для наших переменных, и так же как и во всех переменных в GDB, перед их именем стоит префикс $, в то время как префикс % используется в ассемблере от AT&T.

> С какого раза можно понять смысл предложения?)

Посоветуйте, как написать более понятко. Если дело не в сложно построеном предложении, то поправте мою ошибку.

Что касается OllyDbg… Я совсем недавно познакомился с GDB, и скажу честно, если бы увидел сразу такого монстра, как OllyDbg, то не стал бы продолжать. Полносту соглашаясь с gaelpa. Начинать нужно с простого и GDB подходит под эту категорию.
desperius
0
Чтобы гуглить нада же какая-то отправная точка. Сферически гуглить в вакууме не всегда приведет к должному результату :)

Предыдущих статей нету. Эта статья — ответ на указанную в начале статью другого автора.
desperius
0
Если нашли опечатки, пожалуйста, укажите в ЛС. А то мне текст уже приелся. Перечитывать для проверки бесполезно!
desperius
0
Относительно «охвата большинства аспектов», здесь частично с Вами согласен, но в защиту автора могу сказать, что определить это самое «большинство» не так уж и просто. У каждого свой уровень знаний. Что то не понятно, лучше отложить на потом и откатится на одну ступень назад. Я вот о регистрах последний раз что-то внятное еще на первом курсе университета слышал. Ассемблер видел там же. Но прочитав статью и прогуглив попутно то, что не совсем понимал или призабыл, нормально разобрался о чем идет речь. Так что вполне уместно считать, что у статьи есть целевая аудитория.
desperius
+3
Я думаю, что вы опять таки не совсем поняли, автор пытается добиться бОльшего понимания С за счет приоткрытия уровней абстракции с помощью ассемблера, а не собирается досконально обучить читателя последнему. Ассемблер здесь средство, а не цель.

Что же касается GDB, то этот вопрос уже обсуждался в коментариях к предыдущей статье (http://habrahabr.ru/post/181738/ ). Присоединяйтесь…
desperius
+4
Вы наверное не совсем поняли, но я имел ввиду перевод специфических понятий, ведь я не являюсь непосредственным автором статьи! А касательно самой статьи, то, на мой субьективный взгляд, она очень даже ничего для начинающих. Поэтому я и взялся за ее перевод!
desperius
0
Очень жаль, что пример 5 не описан так детально, как и предыдущие, а просто копипаст с cmake-кого wiki. Не могу разобратся куда и как вставить этот кусок кода, чтобы все собралось без ошибок. Может кто еще здесь подскажет?
desperius
+1
Картинок не обещаю, но кое-какая визуализация будет.
desperius
+4
Сейчас как раз в процессе работы над переводом по теме изучения ассемблера с помощью GDB :)
desperius
0
К сожалению, у автора это единственная статья по теме. Но мне в голову приходила такая же мысль и я подумывал над тем, чтобы самому заняться этим вопросом…
desperius
+33
Так это ж данные только за один день, после выкладывания крякнутой версии…
desperius
+1
А у нас на физмате часто говорили, что студень — это человек, который с легкостью может взять сложнейший интеграл, но не сразу сможет вспомнить таблицу умножения. Что, как мне кажется, легко переносимо и в сферу программирования… Отсюда и смешные ситуации на собеседованиях, когда человек с большим опытом и серьезными проэктами за плечами с ходу не может строку инвертировать :)
desperius
0
Насколько я помню, то вымерание динозавров в следствии падения метеорита лиш одна из многочисленных теорий. И, к тому же, вымерание динозавров не эквивалентно вымиранию всего, что было сложнее за микробы и бактрерии, а как же насекомые, рыбы, ранние млекопитающие и так далее?..
desperius
–3
Если файлы проекта категорически не должны попасть за пределы корпоративной сети под страхом увольнения, то из дома много не на работаеш :)
desperius
0
Исправил на «вещественного числа», потому как, вроде бы, красивее звучит. Спасибо за поправку.
desperius
0
Спасибо. Исправил.
desperius
+7
Это мой первый перевод и топик на хабре, по этому конструктивная критика приветствуется!