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

Вам захотелось пофлеймить. =))) Но я вынужден предупредить что в эту игру можно даже играть вдвоём. И сейчас Вас ждёт небольшой сеанс попаболила.

Следите за руками. =)))

Знаешь, я даже посмотрел, какой код GCC под sparc32 генерирует для функций, использующих alloca(). И знаешь что? Не вызывает он там внешних функций. А ты ведь sparc32 приводил как пример платформы, на которой alloca() — функция библиотеки.

Вообще-то, у Вас классика случая «гляжу в книгу, вижу фигу». Если Вы так же с кодом на С разбираетесь, то я очень хочу знать (чтоб не влипать в это) какой же дурак держит Вас на работе и, наверное, даже тратит деньги на Вашу з/п.

Всё просто. Не, батенька, в коде под Sparc32 не должно быть вызовов внешних функций. Просто потому что этот патч и есть реализация такого рода функции. Именно это реализация __builtin_alloca() для gcc на Sparc32. Вы этого не поняли. Соболезную.

Почему Вы этого не поняли? Да потому что Вы написали ярую антинаучную фигню вот в этом Максимально допустимый размер массива на стеке? (комментарий) своём комменте.

Вообще-то, для работы со стеком в x86_64 (как я и довольно дерзко предположил выше) нужен регистр esp, содержимое которого мы либо увеличиваем, либо уменьшаем в зависимости от того, что мы делаем (резервируем пространство в стеке, либо освобождаем его). И нам на фиг тут не сдались никакие фантазии по поводу и без, кроме того, что мы смотрим за флагами процессора, чтобы не прохлопать изменение знака. За собой чистить даже ничего не нужно, т.к. стек нулить ни к чему. Вернулись из функции, обновили esp и продолжаем дальше.

Как там реализовать пролог и эпилог функции в непосредственной работе со стеком не относится (вся возня с frame pointer тут так же лесом).

Так что, если я захочу в стеке просто получить #200 (да, 200 байт), то я просто сделаю sub esp, #200, получу к ним доступ через move [esp + x], где «х» это число от 0 до 199 и потом очищу за собой пространство add esp, #200. Всё. Больше ничего. Frame pointer и связанные с ним проблемы тут лесом. Вы, не понимая этого спорного, не скрою, момента, начали чего-то там гундеть про флаги gcc. Да хоть угундитесь, как организуется работа со стеком действительно экономичным образом, Вы не в курсе. Понимаю, не ваше. =)))

Вот почему Вы начали искать в приведённом коде для Sparc32 вызовы внешних функций. Вы просто и тупо не понимаете что вот эта реализация:

ENTRY (__builtin_alloca)
	sub %sp, %o0, %sp	/* Push some stack space.  */
	retl			/* Return; the returned buffer leaves 96 */
	add %sp, 96, %o0	/* bytes of register save area at the top. */
END (__builtin_alloca)

Да, Вы не понимаете что именно эта реализация и есть вариант того, что я объяснил выше для x86_64 с регистром esp. Тут только малость другой синаксис (и не только), мнемоники-то да, другие, но подход тот же – никакого онанирования над frame pointer’ом нет.

Если Вы не поняли этого кода, то я очень хочу знать где же таким болванам з/п платят? =)))

Думаете всё? Куууда собрались?

Теперь потрудитесь объяснить следующий момент. Вот Вы пишете Максимально допустимый размер массива на стеке? (комментарий) :

alloca() нельзя реализовать функцией на x86-64 под GCC, потому что нужно как-то стек при выходе возвращать в предыдущее состояние.

С возвратом стека в предыдущее состояние мы разобрались – см. выше. Как понять Вашу фразу alloca() нельзя реализовать функцией, если чуть ниже Вы пишете:

Я не говорю, что alloca() реализуется макросом.

В особенности, если учесть что man 3 alloca говорит явно об alloca() как о функции? Скажите пожалуйста, Вы в какой из двух своих цитат «свистите»? =)))

Кстати, мне интересно, какой твой ответ на твою же загадку про сигнатуру alloca(). Мне кажется, что я знаю, что ты имел в виду, но всё-таки интересно услышать оригинальный ответ.

Не, Вы мне тут загадок уже поназадавали (я даже показал уже что код не соберётся без сборки кода), давайте теперь Вы ответите на мои вопросы выше? =)))

Я же Вас предупреждал что во флейм можно вдвоём поиграть? Вы мне не поверили? А зря… =)))

P.S. И да. Если соберётесь отвечать, то делайте это внятно. Так, чтобы Вас мне не захотелось послать по всем известному адресу. А то я начинаю задумываться о том, что пора бы… Не провоцируйте. Пожалуйста. =)

Вам захотелось пофлеймить. =))) Но я вынужден предупредить что в эту игру можно даже играть вдвоём. И сейчас Вас ждёт небольшой сеанс попаболила.

Следите за руками. =)))

Знаешь, я даже посмотрел, какой код GCC под sparc32 генерирует для функций, использующих alloca(). И знаешь что? Не вызывает он там внешних функций. А ты ведь sparc32 приводил как пример платформы, на которой alloca() — функция библиотеки.

Вообще-то, у Вас классика случая «гляжу в книгу, вижу фигу». Если Вы так же с кодом на С разбираетесь, то я очень хочу знать (чтоб не влипать в это) какой же дурак держит Вас на работе и, наверное, даже тратит деньги на Вашу з/п.

Всё просто. Не, батенька, в коде под Sparc32 не должно быть вызовов внешних функций. Просто потому что этот патч и есть реализация такого рода функции. Именно это реализация __builtin_alloca() для gcc на Sparc32. Вы этого не поняли. Соболезную.

Почему Вы этого не поняли? Да потому что Вы написали ярую антинаучную фигню вот в этом Максимально допустимый размер массива на стеке? (комментарий) своём комменте.

Вообще-то, для работы со стеком в x86_64 (как я и довольно дерзко предположил выше) нужен регистр esp, содержимое которого мы либо увеличиваем, либо уменьшаем в зависимости от того, что мы делаем (резервируем пространство в стеке, либо освобождаем его). И нам на фиг тут не сдались никакие фантазии по поводу и без, кроме того, что мы смотрим за флагами процессора, чтобы не прохлопать изменение знака. За собой чистить даже ничего не нужно, т.к. стек нулить ни к чему. Вернулись из функции, обновили esp и продолжаем дальше.

Как там реализовать пролог и эпилог функции в непосредственной работе со стеком не относится (вся возня с frame pointer тут так же лесом).

Так что, если я захочу в стеке просто получить #200 (да, 200 байт), то я просто сделаю sub esp, #200, получу к ним доступ через move [esp + x], где «х» это число от 0 до 199 и потом очищу за собой пространство add esp, #200. Всё. Больше ничего. Frame pointer и связанные с ним проблемы тут лесом. Вы, не понимая этого спорного, не скрою, момента, начали чего-то там гундеть про флаги gcc. Да хоть угундитесь, как организуется работа со стеком действительно экономичным образом, Вы не в курсе. Понимаю, не ваше. =)))

Вот почему Вы начали искать в приведённом коде для Sparc32 вызовы внешних функций. Вы просто и тупо не понимаете что вот эта реализация:

ENTRY (__builtin_alloca)
	sub %sp, %o0, %sp	/* Push some stack space.  */
	retl			/* Return; the returned buffer leaves 96 */
	add %sp, 96, %o0	/* bytes of register save area at the top. */
END (__builtin_alloca)

Да, Вы не понимаете что именно эта реализация и есть вариант того, что я объяснил выше для x86_64 с регистром esp. Тут только малость другой синаксис (и не только), мнемоники-то да, другие, но подход тот же – никакого онанирования над frame pointer’ом нет.

Если Вы не поняли этого кода, то я очень хочу знать где же таким болванам з/п платят? =)))

Думаете всё? Куууда собрались?

Теперь потрудитесь объяснить следующий момент. Вот Вы пишете Максимально допустимый размер массива на стеке? (комментарий) :

alloca() нельзя реализовать функцией на x86-64 под GCC, потому что нужно как-то стек при выходе возвращать в предыдущее состояние.

С возвратом стека в предыдущее состояние мы разобрались – см. выше. Как понять Вашу фразу alloca() нельзя реализовать функцией, если чуть ниже Вы пишете:

Я не говорю, что alloca() реализуется макросом.

В особенности, если учесть что man 3 alloca говорит явно об alloca() как о функции? Скажите пожалуйста, Вы в какой из двух своих цитат «свистите»? =)))

Кстати, мне интересно, какой твой ответ на твою же загадку про сигнатуру alloca(). Мне кажется, что я знаю, что ты имел в виду, но всё-таки интересно услышать оригинальный ответ.

Не, Вы мне тут загадок уже поназадавали (я даже показал уже что код не соберётся без сборки кода), давайте теперь Вы ответите на мои вопросы выше? =)))

Я же Вас предупреждал что во флейм можно вдвоём поиграть? Вы мне не поверили? А зря… =)))

Вам захотелось пофлеймить. =))) Но я вынужден предупредить что в эту игру можно даже играть вдвоём. И сейчас Вас ждёт небольшой сеанс попаболила.

Следите за руками. =)))

Знаешь, я даже посмотрел, какой код GCC под sparc32 генерирует для функций, использующих alloca(). И знаешь что? Не вызывает он там внешних функций. А ты ведь sparc32 приводил как пример платформы, на которой alloca() — функция библиотеки.

Вообще-то, у Вас классика случая «гляжу в книгу, вижу фигу». Если Вы так же с кодом на С разбираетесь, то я очень хочу знать (чтоб не влипать в это) какой же дурак держит Вас на работе и, наверное, даже тратит деньги на Вашу з/п.

Всё просто. Не, батенька, в коде под Sparc32 не должно быть вызовов внешних функций. Просто потому что этот патч и есть реализация такого рода функции. Именно это реализация __builtin_alloca() для gcc на Sparc32. Вы этого не поняли. Соболезную.

Почему Вы этого не поняли? Да потому что Вы написали ярую антинаучную фигню вот в этом Максимально допустимый размер массива на стеке? (комментарий) своём комменте.

Вообще-то, для работы со стеком в x86_64 (как я и довольно дерзко предположил выше) нужен регистр esp, содержимое которого мы либо увеличиваем, либо уменьшаем в зависимости от того, что мы делаем (резервируем пространство в стеке, либо освобождаем его). И нам на фиг тут не сдались никакие фантазии по поводу и без, кроме того, что мы смотрим за флагами процессора, чтобы не прохлопать изменение знака. За собой чистить даже ничего не нужно, т.к. стек нулить ни к чему. Вернулись из функции, обновили esp и продолжаем дальше.

Как там реализовать пролог и эпилог функции в непосредственной работе со стеком не относится (вся возня с frame pointer тут так же лесом).

Так что, если я захочу в стеке просто получить #200, то я просто сделаю sub esp, #200, получу к ним доступ через move [esp + x], где «х» это число от 0 до 199 и потом очищу за собой пространство add esp, #200. Всё. Больше ничего. Frame pointer и связанные с ним проблемы тут лесом. Вы, не понимая этого спорного, не скрою, момента, начали чего-то там гундеть про флаги gcc. Да хоть угундитесь, как организуется работа со стеком действительно экономичным образом, Вы не в курсе. Понимаю, не ваше. =)))

Вот почему Вы начали искать в приведённом коде для Sparc32 вызовы внешних функций. Вы просто и тупо не понимаете что вот эта реализация:

ENTRY (__builtin_alloca)
	sub %sp, %o0, %sp	/* Push some stack space.  */
	retl			/* Return; the returned buffer leaves 96 */
	add %sp, 96, %o0	/* bytes of register save area at the top. */
END (__builtin_alloca)

Да, Вы не понимаете что именно эта реализация и есть вариант того, что я объяснил выше для x86_64 с регистром esp. Тут только малость другой синаксис (и не только), мнемоники-то да, другие, но подход тот же – никакого онанирования над frame pointer’ом нет.

Если Вы не поняли этого кода, то я очень хочу знать где же таким болванам з/п платят? =)))

Думаете всё? Куууда собрались?

Теперь потрудитесь объяснить следующий момент. Вот Вы пишете Максимально допустимый размер массива на стеке? (комментарий) :

alloca() нельзя реализовать функцией на x86-64 под GCC, потому что нужно как-то стек при выходе возвращать в предыдущее состояние.

С возвратом стека в предыдущее состояние мы разобрались – см. выше. Как понять Вашу фразу alloca() нельзя реализовать функцией, если чуть ниже Вы пишете:

Я не говорю, что alloca() реализуется макросом.

В особенности, если учесть что man 3 alloca говорит явно об alloca() как о функции? Скажите пожалуйста, Вы в какой из двух своих цитат «свистите»? =)))

Кстати, мне интересно, какой твой ответ на твою же загадку про сигнатуру alloca(). Мне кажется, что я знаю, что ты имел в виду, но всё-таки интересно услышать оригинальный ответ.

Не, Вы мне тут загадок уже поназадавали (я даже показал уже что код не соберётся без сборки кода), давайте теперь Вы ответите на мои вопросы выше? =)))

Я же Вас предупреждал что во флейм можно вдвоём поиграть? Вы мне не поверили? А зря… =)))