У меня довольно глупый вопрос,но нужно ли сначала учить СИ,а потом ассемблер или можно сразу начинаться с ассемблера?

| Сообщение посчитали полезным:

DenCoder мне хочется поскорее попробовать реверс,так что полагаю лучше сначала ассемблер изучить,чтоб поскорее к практике приступить

| Сообщение посчитали полезным:

Один асм без базового WinApi (или linux api) мало чего даст. Там в асме особо изучать-то и нечего! -> mov, cmp, test, add, xor, or, and, jcc, jmp, call, ret, push/pop - основной набор. И на изучение этого меньше одного дня хватит! Привыкнуть - может, больше потребуется. Привыкать лучше всего с детства, и лучше вообще для практики реверса не с x86 начинать, а с ARM! Т.к. набор команд всегда ограничен, а различных схем логики на них несчётное кол-во... Привыкнуть к arm'овским movgt, carry-флаг при сравнениях имеет смысл наоборот... - мозг должен уметь динамично, без шаблонов работать. Такая динамичность лучше всего с детства вырабатывается. А в x86 всё просто, не знаю, как для остальных... Но если с этим проблем нет, то лучше всего и не париться - Вы уже всё знаете, вперёд!

Добавлено спустя 9 минут
А для того, чтоб всё-таки привыкнуть быстрей - полезно видеть код в 2х представлениях: на языке выского уровня и асме

-----
IZ.RU

| Сообщение посчитали полезным: hors

plutos пишет:
Он будет много и горячо говорить об умном, выдавать глубокомысленные сентенции вместо того, чтобы сесть да и заняться делом, т.е. надеть кондом и вставить.

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

DenCoder пишет:
В своё время мне 2х недель хватило, чтоб быть готовым к написанию первых курсовых работ на C++. При этом не имелось компа под рукой. Изучение было чисто теоретическим. И мне, кстати, не нравился тогда си, я был за дельфи и асм... Так что 21 день - это даже с запасом. Получить необходимые основы - вполне хватит. Всё зависит от стремления и захламлённости мозга...

Не только от стремлённости и захламленности мозга, но и ещё от наличия времени, которого у некоторых порой просто нет.

DenCoder пишет:
Как правило, сколько доводилось видеть, человек, больше болтающий о том, чего он хочет, на десятки лет оставляет это в желаниях...

Не поспоришь, но у меня другая ситуация, был поглощён другой областью.

| Сообщение посчитали полезным:

spinz пишет:
В те времена в "Науке и жизни" был раздел, посвященный кодингу на МК-61 (и аналогичных типа МК-52 и пр).
ох времена ох нравы... я на свой мк52 покупал внешний БРП-3 модуль, а потом спаял по журналу радио переходник который позволял сливать все программы на кассетный магнитофон или обратно с магнитофона заливать

| Сообщение посчитали полезным: script_kidis

roseroserose пишет:
У меня довольно глупый вопрос,но нужно ли сначала учить СИ,а потом ассемблер или можно сразу начинаться с ассемблера?
Начинать - с ассемблера. Заканчивать - С++11.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: hors

DenCoder пишет:
полезно видеть код в 2х представлениях: на языке выского уровня и асме
Да, но не после студийного оптимизатора, он создает хорошо оптимизированый код, но плохо читаемый и понимаемый, без определенной сноровки.

-----
xchg dword [eax], eax

| Сообщение посчитали полезным: hors, dsrabot

void пишет:
он создает хорошо оптимизированый код
тут часто можно поспорить... иногда его "оптимизированный" код можно свернуть до нескольких команд. И задаёшься вопросом что именно он пытался тут оптимизировать и почему через ж...

-----
z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh

| Сообщение посчитали полезным:

Isaev пишет:
иногда его "оптимизированный" код можно свернуть до нескольких команд
Которые возможно будут работать медленее. Но MS далёк от идеальной оптимизации, тут лучше сравнивать с Intel cpp. Вот с ним соревноваться крайне трудно.

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

Второе применение ассемблера - случаи когда писать на си невозможно (всякие загрузчики, стартовый код биос, стабы сплайсинга, итп.). Обычно на асме пишут подготовку среды исполнения к запуску си кода, а также специфичные процедуры. Основная часть программы всё-же пишется на си, даже если она будет работать на голом процессоре в PEI стадии загрузки.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

ntldr пишет:
лучше сравнивать с Intel cpp. Вот с ним соревноваться крайне трудно

intel больше не подкидывает чужим процессорам менее оптимизированный код?

| Сообщение посчитали полезным:

Gideon Vi пишет:
intel больше не подкидывает чужим процессорам менее оптимизированный код?
И никогда не подкидывал. Просто в свитче есть ветки для ряда процессоров Intel и ветка по-умолчанию для всего остального. Я интелом компилю отдельные модули с настройкой под конкретный процессор и такой проблемы не имею. Думаю при компиляции программы целиком, эта проблема лечится правильным выбором настроек.
Производительность кода скомпиленного под процессоры Intel на процессорах других фирм я не изучал.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

Unfortunately, the CPU detection mechanism in Intel compilers has several flaws:
* The best possible version of the code is chosen only when running on an Intel processor. The CPU dispatcher checks whether the processor is an Intel before it checks which instruction set it supports. An inferior version of the code is selected if the processor is not an Intel, even if the processor is compatible with a better version of the code. This can lead to a dramatic degradation of performance on AMD and VIA processors.
* Explicit CPU dispatching works only with Intel processors. A non-Intel processor makes the dispatcher signal an error simply by performing an illegal operation that crashes the program.
* The CPU dispatcher does not check if XMM registers are supported by the operating system. It will crash on old operating systems that do not support SSE.
Several function libraries published by Intel have similar CPU dispatch mechanisms, and some of these also treat non-Intel CPUs in a suboptimal way.

ntldr пишет:
проблема лечится

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

| Сообщение посчитали полезным: