LINUX.ORG.RU

История изменений

Исправление 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.