История изменений
Исправление MOPKOBKA, (текущая версия) :
На ассемблере оперируешь отдельно регистрами, отдельно памятью, явно указываешь векторные операции.
В С отдельно оперируешь стековыми переменными, отдельно памятью, явно можно указать векторные операции. Есть ключевое слово register, можно привязать его к rax.
Учитывая как часто С используется в низкоуровневом коде, логично знать как его писать, и связывать с С.
Я же написал «а за ней другая переменная». Это и есть «друг за другом».
Нет, это когда ты определяешь переменную в каком то одном memory layout (не знаю как называется точно), переменная как я уже сказал может быть и extern. В С тоже так можно, задаешь структуру, упаковку.
Еще в ассемблере может быть задано выравнивание переменных, поэтому ничего в следующую переменную тоже не запишется.
Семантика совсем другая. Навыки, полученные в ассемблере, в Си вредят. С таким же успехом можно питон изучать перед Си.
Семантика обрезает ассемблерную от разных платформ в рамках переносимости, при этом часто в проекте используется семантика некоторого круга платформ. Кого поможет подготовить изучение С только по стандарту, скрывая то на чем он основывается? Комитетчика?
Стандарт же не появился как особое ответвление, он вырос из платформ.
Навыки, полученные в ассемблере, в Си вредят.
Они не могут вредить. Вредить может попытка программировать на %a-lang-name% в %b-lang-name%.
Тогда перед Haskell’ом и лиспом тоже ассемблер изучать? Чтобы смотреть, во что раскрываются замыкания и ленивые списки.
Конечно, и очень желательно еще знать С/C++, на которых от части написаны GHC и SBCL.
Исправление MOPKOBKA, :
На ассемблере оперируешь отдельно регистрами, отдельно памятью, явно указываешь векторные операции.
В С отдельно оперируешь стековыми переменными, отдельно памятью, явно можно указать векторные операции. Есть ключевое слово register, можно привязать его к rax.
Учитывая как часто С используется в низкоуровневом коде, логично знать как его писать, и связывать с С.
Я же написал «а за ней другая переменная». Это и есть «друг за другом».
Нет, это когда ты определяешь переменную в каком то одном memory layout (не знаю как называется точно), переменная как я уже сказал может быть и extern. В С тоже так можно, задаешь структуру, упаковку.
Еще в ассемблере может быть задано выравнивание, поэтому ничего в следующую переменную тоже не запишется.
Семантика совсем другая. Навыки, полученные в ассемблере, в Си вредят. С таким же успехом можно питон изучать перед Си.
Семантика обрезает ассемблерную от разных платформ в рамках переносимости, при этом часто в проекте используется семантика некоторого круга платформ. Кого поможет подготовить изучение С только по стандарту, скрывая то на чем он основывается? Комитетчика?
Стандарт же не появился как особое ответвление, он вырос из платформ.
Навыки, полученные в ассемблере, в Си вредят.
Они не могут вредить. Вредить может попытка программировать на %a-lang-name% в %b-lang-name%.
Тогда перед Haskell’ом и лиспом тоже ассемблер изучать? Чтобы смотреть, во что раскрываются замыкания и ленивые списки.
Конечно, и очень желательно еще знать С/C++, на которых от части написаны GHC и SBCL.
Исправление MOPKOBKA, :
На ассемблере оперируешь отдельно регистрами, отдельно памятью, явно указываешь векторные операции.
В С отдельно оперируешь стековыми переменными, отдельно памятью, явно можно указать векторные операции. Есть ключевое слово register, можно привязать его к rax.
Учитывая как часто С используется в низкоуровневом коде, логично знать как его писать, и связывать с С.
Я же написал «а за ней другая переменная». Это и есть «друг за другом».
Нет, это когда ты определяешь переменную в каком то одном memory layout (не знаю как называется точно), переменная как я уже сказал может быть и extern. В С тоже так можно, задаешь структуру, упаковку.
Семантика совсем другая. Навыки, полученные в ассемблере, в Си вредят. С таким же успехом можно питон изучать перед Си.
Семантика обрезает ассемблерную от разных платформ в рамках переносимости, при этом часто в проекте используется семантика некоторого круга платформ. Кого поможет подготовить изучение С только по стандарту, скрывая то на чем он основывается? Комитетчика?
Стандарт же не появился как особое ответвление, он вырос из платформ.
Навыки, полученные в ассемблере, в Си вредят.
Они не могут вредить. Вредить может попытка программировать на %a-lang-name% в %b-lang-name%.
Тогда перед Haskell’ом и лиспом тоже ассемблер изучать? Чтобы смотреть, во что раскрываются замыкания и ленивые списки.
Конечно, и очень желательно еще знать С/C++, на которых от части написаны GHC и SBCL.
Исправление MOPKOBKA, :
На ассемблере оперируешь отдельно регистрами, отдельно памятью, явно указываешь векторные операции.
В С отдельно оперируешь стековыми переменными, отдельно памятью, явно можно указать векторные операции. Есть ключевое слово register, можно привязать его к rax.
Я же написал «а за ней другая переменная». Это и есть «друг за другом».
Нет, это когда ты определяешь переменную в каком то одном memory layout (не знаю как называется точно), переменная как я уже сказал может быть и extern. В С тоже так можно, задаешь структуру, упаковку.
Семантика совсем другая. Навыки, полученные в ассемблере, в Си вредят. С таким же успехом можно питон изучать перед Си.
Семантика обрезает ассемблерную от разных платформ в рамках переносимости, при этом часто в проекте используется семантика некоторого круга платформ. Кого поможет подготовить изучение С только по стандарту, скрывая то на чем он основывается? Комитетчика?
Стандарт же не появился как особое ответвление, он вырос из платформ.
Навыки, полученные в ассемблере, в Си вредят.
Они не могут вредить. Вредить может попытка программировать на %a-lang-name% в %b-lang-name%.
Тогда перед Haskell’ом и лиспом тоже ассемблер изучать? Чтобы смотреть, во что раскрываются замыкания и ленивые списки.
Конечно, и очень желательно еще знать С/C++, на которых от части написаны GHC и SBCL.
Исходная версия MOPKOBKA, :
На ассемблере оперируешь отдельно регистрами, отдельно памятью, явно указываешь векторные операции.
В С отдельно оперируешь стековыми переменными, отдельно памятью, явно можно указать векторные операции.
Я же написал «а за ней другая переменная». Это и есть «друг за другом».
Нет, это когда ты определяешь переменную в каком то одном memory layout (не знаю как называется точно), переменная как я уже сказал может быть и extern. В С тоже так можно, задаешь структуру, упаковку.
Семантика совсем другая. Навыки, полученные в ассемблере, в Си вредят. С таким же успехом можно питон изучать перед Си.
Семантика обрезает ассемблерную от разных платформ в рамках переносимости, при этом часто в проекте используется семантика некоторого круга платформ. Кого поможет подготовить изучение С только по стандарту, скрывая то на чем он основывается? Комитетчика?
Стандарт же не появился как особое ответвление, он вырос из платформ.
Навыки, полученные в ассемблере, в Си вредят.
Они не могут вредить. Вредить может попытка программировать на %a-lang-name% в %b-lang-name%.
Тогда перед Haskell’ом и лиспом тоже ассемблер изучать? Чтобы смотреть, во что раскрываются замыкания и ленивые списки.
Конечно, и очень желательно еще знать С/C++, на которых от части написаны GHC и SBCL.