The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Ричарда Столлман опубликовал книгу по языку Си и расширениям GNU, opennews (ok), 07-Сен-22, (0) [смотреть все] –1

Сообщения [Сортировка по времени | RSS]


21. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +1 +/–
Сообщение от pashev.ru (?), 07-Сен-22, 10:43 
И проблема там не только в стеке.
Ответить | Правка | Наверх | Cообщить модератору

102. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +3 +/–
Сообщение от Аноним (101), 07-Сен-22, 12:40 
Восхваляя рекурсивные алгоритмы, забывают, что проблема именно в стеке. Да, кстати, и факториал так считать неэффективно. Примеры должны быть простыми, но не тупыми.
Ответить | Правка | Наверх | Cообщить модератору

155. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +2 +/–
Сообщение от Аноним (-), 07-Сен-22, 14:14 
> Восхваляя рекурсивные алгоритмы, забывают, что проблема именно в стеке. Да, кстати, и
> факториал так считать неэффективно. Примеры должны быть простыми, но не тупыми.

Понимаешь ли в чем дело, чудак...
1) Си сам по себе на уровне спеков ... вообще ничерта не говорит про стек и аллокацию.
2) У оптимизера на этот счет бывают какие-то очень сильно свои идеи. Он настолько умный что даже щеленаправленые попытки уронить программу подобной по смыслу конструкцией ронять ничего не хотят, потому что оптимизер вообще ухитрился аннулировать работу со стеком, а иной раз и вообще скостив весь код до условного "return 10050", ну или сколько там получалось :)

Ответить | Правка | Наверх | Cообщить модератору

166. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +2 +/–
Сообщение от vdb (?), 07-Сен-22, 15:45 
> Восхваляя рекурсивные алгоритмы, забывают, что проблема именно в стеке.

Следующая глава книги: "1.2 The Stack, And Stack Overflow".

Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

181. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  –1 +/–
Сообщение от n00by (ok), 07-Сен-22, 16:57 
>> Восхваляя рекурсивные алгоритмы, забывают, что проблема именно в стеке.
> Следующая глава книги: "1.2 The Stack, And Stack Overflow".

Такая глава следует после рекурсивной Фибоначчи:

if (n <= 2)
  return 1;
else
  return fib (n - 1) + fib (n - 2);

В исходном сообщении совсем другая функция:

    if (x < 1)
        return 1;
    else
        return (x * factorial (x - 1));

Не знаю, откуда взял её автор сообщения, но это не просто рекурсия, а хвостовая рекурсия - ей не нужен стек.

Ответить | Правка | Наверх | Cообщить модератору

184. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от другой аноним (?), 07-Сен-22, 17:13 
(занудно) это НЕ хвостовая рекурсия. Хвостовая рекурсия -- это ТОЛЬКО return factorial(...) и ничего больше. Вызов функции должен быть строго последним действием перед возвратом, а у Вас последнее действие -- умножение. Факториал МОЖНО переписать в виде хвостовой рекурсии, но Вы этого не сделали. Вам для этого потребуется вспомогательная функция с двумя аргументами.
Ответить | Правка | Наверх | Cообщить модератору

187. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +1 +/–
Сообщение от n00by (ok), 07-Сен-22, 17:20 
> (занудно) это НЕ хвостовая рекурсия. Хвостовая рекурсия -- это ТОЛЬКО return factorial(...)
> и ничего больше. Вызов функции должен быть строго последним действием перед
> возвратом, а у Вас последнее действие -- умножение.

А вот код из главы 1.2 The Stack, And Stack Overflow без изменений:

int
fill_stack (int n)
{
  if (n <= 1) /* This limits the depth of recursion. */
     return 1;
  else
    return fill_stack (n - 1);
}

Подходит? :)

Ответить | Правка | Наверх | Cообщить модератору

307. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от другой аноним (?), 08-Сен-22, 21:03 
Слишком хорошо тоже нехорошо: это gcc оптимизирует сразу до готового ответа. Чтобы содержательно хвостовая рекурсия соптимизировалась, но сами вычисления остались, нужно что-нибудь чуток посложнее. Как-то так:

#include <stdio.h>

int fill_stack(int n)
{
    int m = n;
    while (m) {
        m >>= 1;
        n ^= m;
    }
    --n;
    if (n <= 0) return 0;
    n = n ^ (n >> 1);
    return fill_stack(n);
}

int main()
{
    int n = 1000000000;
    n = n ^ (n >> 1);
    printf("%d\n", fill_stack(n));
}

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

Ответить | Правка | Наверх | Cообщить модератору

320. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от Аноним (-), 08-Сен-22, 23:06 
Тут господа вообще упражняются в выпячинивании конкретных corner case как истины в последней инстанции. При том что спеки сей вообще нихрена не говорят про то как вон то должно делаться. Так что конкретная реализация имеет право сделать что угодно, вплоть до прогона вычислений в compile time и выдачи результата 1 константой в регистре. Если это вообще потом где-то применяется. Иначе dead code elimination это совсем выпилит - и никто не заметит разницу. Как код которого нет может переполнить стек? :)
Ответить | Правка | Наверх | Cообщить модератору

335. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от n00by (ok), 09-Сен-22, 10:33 
Я так понял, что Ричард тот ещё тролль. Он в принципе может написать в книжке что угодно - попросил же указать на ошибки. Чем больше к содержанию претензий с обсуждениями - тем в итоге лучше для читателей.
Ответить | Правка | Наверх | Cообщить модератору

381. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от Аноним (-), 11-Сен-22, 09:12 
> Я так понял, что Ричард тот ещё тролль. Он в принципе может
> написать в книжке что угодно - попросил же указать на ошибки.
> Чем больше к содержанию претензий с обсуждениями - тем в итоге
> лучше для читателей.

Если он тут кого и потроллил - то экспертов которые спеки толи не читали, толи забыли, но почему-то решили что их частный случай - единственно возможный вариант дел.

В сишных спеках нет вообще ни единого слова про стек, аллокацию на стеке и тому подобные вещи, это implementation defined behavior, странно его выпячивать как единственно верный и потом удивляться что где-то так, где-то не так...

Ответить | Правка | Наверх | Cообщить модератору

384. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от n00by (ok), 11-Сен-22, 10:18 
А мне интересно, почему компиляторы автоматические переменные пихают в стек, а потом обвиняют язык в исполнении постороннего кода. Даже в IA32 с традиционной адресацией через EBP достаточно просто разделить стеки данных и вызовов. Одно время Intel даже рекомендовала заменять push/pop на mov, ради ускорения.
Ответить | Правка | Наверх | Cообщить модератору

388. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от Аноним (-), 11-Сен-22, 14:09 
> А мне интересно, почему компиляторы автоматические переменные пихают в стек,

Насколько я понимаю - потому что это быстрее и без ряда дурных проблем. Ну то-есть разворачивать механику аллокатора на кучу всякой мелочи которую обычно в стек предлагается пихать - сильно убьет скорость. К тому же аллокатор - где то там в жирном стдлибе. А ее может и не быть. И тогда вообще как?

Я так понимаю что идея что идея такая что в heap выделяется несколько больших блоков по возможности. Если там что-то иное, будет фрагментация памяти, и в хучшем случае довольно серьезный факап перфоманса и оверхед.

> а потом обвиняют язык в исполнении постороннего кода.

Эм... ну был бы не stack based overflow а heap based, сильно бы полегчало? Алсо в современных тулчейнах и сборках стэк обычно NX и это напрямую уже неэксплойтабельно.

ЧСХ это все ловить железом в принципе можно, скажем, redzones, вплоть до страницы без доступа после объекта, но не халявно по оверхеду уж очень. А вон там ubsan довольно много чего умеет ловить даже не очень дорого, но все равно не халявно и очень от кода зависит.

> Даже в IA32 с традиционной  адресацией через EBP достаточно просто разделить
> стеки данных и вызовов.

Я не знаю детали микроархитектуры IA32 _настолько_ чтобы прикинуть факапы с этого. Как минимум мы там точно не хотим чтобы обращение в стек было реальным доступом в реальный адрес RAM, т.к. скорость немедленно станет полным ацтоем. У этих красавцев видите ли есть хардварный буфер на стек как я помню, выделенный для именно этой роли, чтобы это все максимально быстро и похоже на clock-freq проца по скорости было. Насколько вон то попортит эту механику черт его знает, вам виднее.

> Одно время Intel даже рекомендовала заменять push/pop на mov, ради ускорения.

А в какой-то момент сделал какой-то выделеный костыль в виде буфера стека, чтобы он супербыстро работал. У ARM в этом смысле некоторые вещи логичнее, если аргументов и переменных немного они через регистры идут и там стека как такового может и не юзаться, кроме сохранения/восстановления состояния проца где это надо, где mov не поможет. У x86-64 такой пересмотр ABI тоже вроде сделали. Классическому x86 это ессно не грозило из-за убогого набора регистров. Да и за адресацию он должен умереть - relative он не умеет толком, так что вон там какие чудесные костылищи с релоками полпрограмы весом ему вбили, чтобы адресное пространство хотя-бы не было предсказуемым. А то видите ли предсказуемый выбор целей сильно результативнее для атак. Ну и вон там оптимизатор тоже как видим линеаризовал факториал до вида когда не надо ему никакого стека. Оно это вообще умеет, делая иногда мягко говоря совсем не тот код который можно было бы подумать.

Ответить | Правка | К родителю #384 | Наверх | Cообщить модератору

390. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от n00by (ok), 11-Сен-22, 15:08 
>> А мне интересно, почему компиляторы автоматические переменные пихают в стек,
> Насколько я понимаю - потому что это быстрее и без ряда дурных
> проблем. Ну то-есть разворачивать механику аллокатора на кучу всякой мелочи которую
> обычно в стек предлагается пихать - сильно убьет скорость. К тому
> же аллокатор - где то там в жирном стдлибе. А ее
> может и не быть. И тогда вообще как?

Такому аллокатору не нужна ни стдлиб, ни куча. Нужен отдельный от стека блок памяти, по типу tread local storage.

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

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

>> а потом обвиняют язык в исполнении постороннего кода.
> Эм... ну был бы не stack based overflow а heap based, сильно
> бы полегчало?

Там нет адресов возврата.

> Алсо в современных тулчейнах и сборках стэк обычно NX
> и это напрямую уже неэксплойтабельно.

Это исключает исполнение кода на стеке, но не перезапись адреса возврата и исполнение ROP-цепочек.

>[оверквотинг удален]
> кода зависит.
>> Даже в IA32 с традиционной  адресацией через EBP достаточно просто разделить
>> стеки данных и вызовов.
> Я не знаю детали микроархитектуры IA32 _настолько_ чтобы прикинуть факапы с этого.
> Как минимум мы там точно не хотим чтобы обращение в стек
> было реальным доступом в реальный адрес RAM, т.к. скорость немедленно станет
> полным ацтоем. У этих красавцев видите ли есть хардварный буфер на
> стек как я помню, выделенный для именно этой роли, чтобы это
> все максимально быстро и похоже на clock-freq проца по скорости было.
> Насколько вон то попортит эту механику черт его знает, вам виднее.

На Intel адреса возвратов аппаратно «кешируется» отдельно от данных, которые пишутся рядом с ними в память стека.

>[оверквотинг удален]
> проца где это надо, где mov не поможет. У x86-64 такой
> пересмотр ABI тоже вроде сделали. Классическому x86 это ессно не грозило
> из-за убогого набора регистров. Да и за адресацию он должен умереть
> - relative он не умеет толком, так что вон там какие
> чудесные костылищи с релоками полпрограмы весом ему вбили, чтобы адресное пространство
> хотя-бы не было предсказуемым. А то видите ли предсказуемый выбор целей
> сильно результативнее для атак. Ну и вон там оптимизатор тоже как
> видим линеаризовал факториал до вида когда не надо ему никакого стека.
> Оно это вообще умеет, делая иногда мягко говоря совсем не тот
> код который можно было бы подумать.

Аргументы передаются через регистры, но автоматические переменные - это то что в тебе блока.

Ответить | Правка | К родителю #388 | Наверх | Cообщить модератору

393. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от Аноним (-), 11-Сен-22, 16:04 
> Такому аллокатору не нужна ни стдлиб, ни куча. Нужен отдельный от стека
> блок памяти, по типу tread local storage.

А сам весьма немаленький код этого аллокатора откуда вообще тогда возьмется? И что есть "thread local storage" в вон том микроконтроллере например? Heap и stack это как бы регионы, абстракции, их startup обеспечивает. Ну и поменять вот это - переделывать очень много придется, до самых оснований. И наверное много чего и кого отвалится.

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

Только в стеке оно видите ли железом некисло подперто, начиная с того что "деаллокацию" stack pointer оформляет с хардварной поддержкой этсамого. Агаблин, когда вы пушпопаете, не надо математику над SP самому делать. Некоторые типа cortex M еще дальше развили идею и при входе в исключение (irq/fault/etc) проц сам сэйвит соотв. регистры ABI, меняет SP, и вот вы завалились в ваш стандартный сишный void handler(void) по бырому, и это стандартное сишное ABI сразу, просто функцию железка дернула.

А в случае heap всякие там корректировки указателей будут уже значительно менее халявны. Да и использование там предполагается в ином стиле, с возможностью фрагментации. В стеке это обычно не практикуется, и пойнт наполовину в том что SP менеджит железо, а не...

> Там нет адресов возврата.

Как бы да, однако в конечном итоге логику программы можно сломать основательно и то что станет сильно лучше уже не факт. А вот железо там уже не будет указатели менеджить за вас, да и стиль использования предполагается несколько иной. Вы хотите SP который как бы SP но не SP? :)

> Это исключает исполнение кода на стеке, но не перезапись адреса возврата и
> исполнение ROP-цепочек.

Да, но это достаточно неудобно и с ALSR не особо хорошо работает. И все же дает шансы сохранить "хардварное" управление указателем. В общем случае софтварные эквиваленты менее эффективны, т.к. лишний опкод на декодирование, лишний бандвиз на шинах в виде этого опкода и проч.

> На Intel адреса возвратов аппаратно «кешируется» отдельно от данных, которые
> пишутся рядом с ними в память стека.

Мне сложно прикинуть насколько все испортится от такого натяга совы на глобус и насколько это вообще проблематично. А еще см. выше, у стека очевидный плюс что он HW-assisted. На хип эта благодать не распостраняется. Потому что он не стек, лол. И в целом hw-assisted все же эффективнее чем софтом это эмулировать, не?

> Аргументы передаются через регистры, но автоматические переменные - это то что в
> тебе блока.

В случае ARM например есть ряд сохраняемых регистров и ряд не сохраняемых регистров. Часть для передачи аргументов, часть для временных вычислений. И в лучшем случае там операций со стеком может по сути и не быть. А зачем, если в ABI дали право менять вон те регистры и возвращать caller'у их испорчеными? Вот если caller'а это колыхало т.к. он имел какие-то виды на эти регистры... но вот это уже очень сильно отдельное "если". Лучший код - которого нет. Лучшая работа с стеком - та которую избежали. Если при этом логика программы обеспечена.

Ответить | Правка | К родителю #390 | Наверх | Cообщить модератору

396. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от n00by (ok), 11-Сен-22, 17:08 
>> Такому аллокатору не нужна ни стдлиб, ни куча. Нужен отдельный от стека
>> блок памяти, по типу tread local storage.
> А сам весьма немаленький код этого аллокатора откуда вообще тогда возьмется?

Код сейчас это sub rsp, NN. Будет add rbp, NN. Но можно и sub, не суть.

> что есть "thread local storage" в вон том микроконтроллере например? Heap
> и stack это как бы регионы, абстракции, их startup обеспечивает. Ну
> и поменять вот это - переделывать очень много придется, до самых
> оснований. И наверное много чего и кого отвалится.

Ещё один стек добавить, в чём вопрос то? Их и так два, один в ядре, другой в юзермоде. И кстати в ядре всё хоть немного крупное вручную аллоцируют не в стеке, даже если оно живёт мало. Проблемы есть, придётся всё пересобирать из исходников, но они решаемы. Для микроконтроллеров не обязательно это делать.

Ответить | Правка | К родителю #393 | Наверх | Cообщить модератору

405. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от Аноним (-), 12-Сен-22, 04:41 
> Код сейчас это sub rsp, NN. Будет add rbp, NN. Но можно
> и sub, не суть.

1) Что-то мне подсказывает что в HEAP оно только этим не отделывается :P. Парадигма динамической аллокации допускает что в середине деаллоцировано раньше чем в хвосте. Сломать эту парадигму = дофига ограничений на аллокации. Заимплементить как стэк без использования дыр в середине ведет к ацкому оверхеду по жрачу RAM т.к. деаллоцированые дыры в середине считаются занятыми. Вероятно это объясняет почему стэк сватают для маленьких локальных аллокаций.
2) sp железо так то в ряде случаев менеджит.
3) А еще локальная переменная может и вообще сразу в регистрах быть, например. Почему нет, если абстракция держится? Даже кейворд "register" для этого есть. Оно вообще не stack и не heap. И при возможности компилер это пытается. На IA32 это ессно плохо получится, но на ARM и даже x86-64 уже вариант.
4) Если "это будет rbp" - окей, но его тогда не удастся юзать для других целей. Минус эффективность кода.
5) Декодирование stack frames станет хрупче и сложнее.

Еще возможны всякие гибридные компромиссы, типа [локальный стек функции1][redzone][локальный стек функции2][redzone] ... где redzone это например страница с запретом доступа. Но оно RAM на такое выравнивание жрет. Кажется asan/ubasn что-то сравнимое делают. Лайтовый вариант - ловушка только в хвосте, но даже так есть некий оверхед, не решит проблему с адресами возврата, да еще в сях точный лимит использования стека не всегда предвычислим, скажем, удачи для VLA + user input. Это только в рантайме ловить, и будет это дотнет какой-то по оверхеду.

> Ещё один стек добавить, в чём вопрос то?

Вероятно, добавит оверхеда и деоптимизирует код. А если из сей очередной дотнет получится - ну и кому такой си будет нужен? В принципе из него это сейчас вполне делаемо, ubsan врубить (относительно лайтово, есть сверхлегкий режим который даже на MCU работает) а при параное и asan, но вот тут уже будет полная ява с дотнетом. Зато ловит практически все что я с наскока смог вообразить. Нормальные люди делают это с дебагбилдов и пускают fuzzer на это, а потом иногда узнают о своем коде кое-что новое. Вот такой damage control.

> Их и так два, один в ядре, другой в юзермоде. И кстати в ядре всё
> хоть немного крупное вручную аллоцируют не в стеке,

Смотря как крупное определено. IIRC там возбухают если >1К stack у функции. У них к тому есть очень особые предпосылки, это огромная многотредовая штука с модулями, кучей функций и всем таким, и все это в 1 адресном пространстве, хотя сущностей на дюжину процессов хватило бы.

> даже если оно живёт мало.

Они же не могут выгрузить вон того жиртреста в отдельный полноценный процесс.

> Проблемы есть, придётся всё пересобирать из исходников, но они
> решаемы. Для микроконтроллеров не обязательно это делать.

На мк при желании заводится лайтовый ubsan, там забавно сделано: при срабатывании вызывает "bad opcode". Ну а дальше сами разбирайтесь в обработчике как на это реагировать. А, ну это на приличных процах типа cortex M. Хрень типа avr не имеет понятия bad opcode и исключений и в этом смысле кажется пролетает. Пофигистичному процу - пофигистичный рантайм. Даже оверхед кстати не такой дикий, процентов 20 кода добавляет, ну и скорость алго ессно убивает на сколько то проверками.

Ответить | Правка | К родителю #396 | Наверх | Cообщить модератору

410. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от n00by (ok), 12-Сен-22, 11:53 
>> Код сейчас это sub rsp, NN. Будет add rbp, NN. Но можно
>> и sub, не суть.
> 1) Что-то мне подсказывает что в HEAP оно только этим не отделывается

А надо слушать опыт. Что бы он был, реализовать самому на асме, изучить вопрос.

> :P. Парадигма динамической аллокации допускает что в середине деаллоцировано раньше чем
> в хвосте.

Я вообще не пишу про динамическую аллокацию типа «куча», не надо путать. Стек это стек. И дело десятое, какой регистр используется для адресации. Если говорить про кучу, тот тут напрашивается mark-compact, но это не про Си.

Ответить | Правка | К родителю #405 | Наверх | Cообщить модератору

413. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от Аноним (413), 12-Сен-22, 15:47 
> А надо слушать опыт.

Это работает в 90% случаев но в остальных 10% забавно выставляет адепта метода раком, во всех смыслах.

> Что бы он был, реализовать самому на асме, изучить вопрос.

Я умею прогать на асме, но идея выписывать аналог аллокатора для heap и тем более гибрид со стеком душу не греет, в т.ч. и потому что я могу прикинуть проблемы.

> Я вообще не пишу про динамическую аллокацию типа «куча», не надо путать.

Т.е. это +1 стэк сугубо? Ну окей, однако мы тогда перманентно теряем регистр. Остальной код им пользоваться для себя по простому не может и общее качество генеренного кода сольется. Потому что вон там было бы удобно юзануть это, но - не судьба, так что вот вам какой-то fallback.

IIRC GCC в сферическом идеале в вакууме вообще хотел бы бесконечно регистров. Если б они были и это не вело к проблемам типа размера состояния проца и времени его сохранения.

> Стек это стек. И дело десятое, какой регистр используется для адресации.

Ну как бы SP уже был, частично подпирался хардваром в той или иной степени и он все равно для general purpose применений не подходил. А вон тот регистр был достаточно полезен.

Ответить | Правка | К родителю #410 | Наверх | Cообщить модератору

414. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от n00by (ok), 12-Сен-22, 16:51 
>> Я вообще не пишу про динамическую аллокацию типа «куча», не надо путать.
> Т.е. это +1 стэк сугубо?

Да.

> Ну окей, однако мы тогда перманентно теряем
> регистр.

Верно.

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

На IA32 оно так всегда и было, наверное со времён шестнадцатиразрядного x86 с командами enter+leave. В прологе esp копировался в ebp и далее вся работа шла через ebp. Тогда это объяснялось, что при адресации через регистр базы опкод получается на байт меньше. На деле, подозреваю, компиляторы были не очень, а адресовать через ebp проще - в отличие от esp он в теле подпрограммы не меняется. Потом появился -fomit-frame-pointer и регистр освободили.

Ответить | Правка | К родителю #413 | Наверх | Cообщить модератору

428. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 11:59 
> Да.

Ну так то оно наверное может работать, но кажется это будет не бесплатно. При том что это 1 частный случай проблемы, а есть еще более 9000 вариантов как сломать flow софта. Если каждый с пеналти затыкть, в целом получится жуть на уровне дотнета в лучшем случае.

> Верно.

И это испортит оптимизацию, не халявно. Ну вон integer overflow может быть весьма фатален если это массив или указатель. И даже если там код и не выполнится, много с этого радости дохлым водилам тойот?

> На IA32 оно так всегда и было,

И это одна из причин искренне желать ей смерти. Костылищи которые пришлось вбить на уровне железа поражают воображение. Да, там есть "register renaming" и проч, так что реально регистров сильно больше чем вывешено. Однако вывесить как доступное кодеру и компилеру апи было бы, имхо, эффективнее. Во всяком случае в разумных пределах. IA32 являет собой коллекцию костылей и подпорок compat с уродским легаси ABI.

> наверное со времён шестнадцатиразрядного x86 с командами enter+leave.
> В прологе esp копировался в ebp и далее вся работа шла через ebp. Тогда это
> объяснялось, что при адресации через регистр базы опкод получается на байт меньше.

В IA32 было очень много дурных решений. А потом... потом совместимость, и по крупному ее сломать решился только AMD в x86-64. И даже там они зассали это сделать как следует и ограничились какими-то полумерами. Могли бы и лучше, но видимо побоялись участи итаника.

> На деле, подозреваю, компиляторы были не очень, а адресовать через ebp проще - в
> отличие от esp он в теле подпрограммы не меняется. Потом появился
> -fomit-frame-pointer и регистр освободили.

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

Ответить | Правка | К родителю #414 | Наверх | Cообщить модератору

334. "Ричарда Столлман опубликовал книгу по языку Си и расширениям..."  +/–
Сообщение от n00by (ok), 09-Сен-22, 10:28 
Так в том и дело, что на практике всплывает масса нюансов с примером из книги. В учебнике (позиционируется в т.ч. для «know nothing about C») по императивному языку рекурсия зачем-то дана дана в сам начале, потом переполнение, которого на практике нет, и без всех этих пояснений. А если начать расписывать, то кто будет это читать? И на автора просто так не наедешь. :)
Ответить | Правка | К родителю #307 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру