Ага, спасибо. Я изучал PM по русскоязычным учебникам ассемблера, там очень плохо было это описано. Потом уже добрался до англоязычного руководства по 386, но именно этот вопрос тогда уже не интересовал. А сейчас внезапно вспомнил. Писал тогда свою ОС, вспоминаю проект с теплотой.
Это понятно. Перемапить кусок можно. Я задумался над тем, как стыковать с новым буфером — ведь файлмаппинг займет свой адрес, и нет гарантии, что можно получить кусок встык за ним.
Особенность этого аллокатора была в том, что пространство выделяется размером равным степени двойки. Возможно поэтому повелось удваивать пространство при реаллокации.
Я наивно думал, что любой аллокатор стремится оперировать блоками размера степени двойки. Более того, точно знаю, что с некоторыми аллокаторами (например, FastMM для Delphi) затребование блоков именно такого размера уменьшает фрагментацию.
Кроме того не вижу ни одного повода не удваивать его
Размер растет слишком быстро, в итоге получается, что после определенного момента мы для записи лишнего байта будем выделять мегабайты памяти, это неоптимально.
Мне кажется, логичным был бы множитель вроде логарифма от какого-то параметра, т.е. крутой рост в самом начале, когда будет много вызовов и более пологий рост в конце.
То-есть, сегмент, который «растет вниз» действительно растет вниз, от базового адреса в сторону младших, т.е. не last address=base + size, а last address = base-size, так что ли?
В чем суть стратегии «увеличивать вдвое»? Почему именно вдвое? Если неизвестно, какие данные записываются и с какой скоростью, непонятно, какой необходим прирост. Есть ли какие-то изыскания по этой теме?
Раз статья 0, позволю себе немного оффтопный вопрос.
Что будет, если при переходе в защищенный режим загрузить в SS селектор сегмента, который описан как сегмент данных (Бит ED = 0 в байте AR дескриптора, т.е. признак «рост вниз» отключен)? Точнее — я знаю, что ничего не случится, стек будет работать как обычно, но зачем тогда этот бит?
Разве не было бы логично обновить веб-сервер (и не только), чтобы он корректно эскейпил заголовки и прочее непосредственно при передаче в баш?
Веб-сервер отрабатывает корректно. Это bash не проверяет свои входные данные на корректность. Если у вас есть программа с одним окном и одним editboxом, в который пользователь вводит делитель, и при вводе 0 программа выпадает с division by zero, проблема в вашем коде, а не коде графической оболочки, реализующей editbox.
Зависит от ВУЗа. У нас было такое требование — дипломный проект надо оформлять по ЕСПД, соответственно, есть минимальный комплект документации. Т.е. есть исходники, описание алгоритмов, рук-во оператора и пр. Это идет в приложение, не в сам диплом (я приложение на CDшке подклеивал).
Если у вас дипломная работа, то можно и не включать.
Но если дипломный проект (специалитет), то проект выполняется полностью. с документацией.
Выбил 11 из 15, т.е. Ready for real-life C.
Вариант 6 "… by tricking the system" и первый запуск с отключенными скриптами в браузере, при которых ответ сразу высвечивается справа, навел на мысли…
У меня 158 страниц было без каких бы то ни было исходников или других приложений (это еще сотни, на компакт пошло).
Не представляю, как может быть диплом с экономикой в 50 стр.
Да и не всегда радуга на экране хороша. Порой идеал — два-три цвета. Просматривая исходники в FARе, понимаешь, почему и зачем придумали форматирование, определенный шаблон комментариев и расстановки скобок — эти участки различаешь очень быстро и без цвета. Потом рассматривая какой-нибудь нечитаемый код в современной ИДЕ с радужной подсветкой, думаешь, что автор никогда не использовал бы вот такие дурацкие идентификаторы и такое идиотское форматирование, если бы не было цвета.
Не говоря об этих флагах:
// CONTEXT_CONTROL specifies SegSs, Rsp, SegCs, Rip, and EFlags.
//
// CONTEXT_INTEGER specifies Rax, Rcx, Rdx, Rbx, Rbp, Rsi, Rdi, and R8-R15.
//
// CONTEXT_SEGMENTS specifies SegDs, SegEs, SegFs, and SegGs.
//
// CONTEXT_DEBUG_REGISTERS specifies Dr0-Dr3 and Dr6-Dr7.
//
// CONTEXT_MMX_REGISTERS specifies the floating point and extended registers
// Mm0/St0-Mm7/St7 and Xmm0-Xmm15).
//
Помню, где-то была статья о helloworld в несколько килобайт.
Зависит от конкретного менеджера памяти.
И я тоже. Странно, что вы мне это пишете.
Значительно меньшую чем при каком выделении?
Все как всегда — нельзя выиграть одновременно в силе и перемещении.
Я наивно думал, что любой аллокатор стремится оперировать блоками размера степени двойки. Более того, точно знаю, что с некоторыми аллокаторами (например, FastMM для Delphi) затребование блоков именно такого размера уменьшает фрагментацию.
Размер растет слишком быстро, в итоге получается, что после определенного момента мы для записи лишнего байта будем выделять мегабайты памяти, это неоптимально.
Мне кажется, логичным был бы множитель вроде логарифма от какого-то параметра, т.е. крутой рост в самом начале, когда будет много вызовов и более пологий рост в конце.
Можно подробнее, что вы имеете в виду, что это даст?
Интересно, как это реализовано в Win32…
Что будет, если при переходе в защищенный режим загрузить в SS селектор сегмента, который описан как сегмент данных (Бит ED = 0 в байте AR дескриптора, т.е. признак «рост вниз» отключен)? Точнее — я знаю, что ничего не случится, стек будет работать как обычно, но зачем тогда этот бит?
Веб-сервер отрабатывает корректно. Это bash не проверяет свои входные данные на корректность. Если у вас есть программа с одним окном и одним editboxом, в который пользователь вводит делитель, и при вводе 0 программа выпадает с division by zero, проблема в вашем коде, а не коде графической оболочки, реализующей editbox.
Если у вас дипломная работа, то можно и не включать.
Но если дипломный проект (специалитет), то проект выполняется полностью. с документацией.
Вариант 6 "… by tricking the system" и первый запуск с отключенными скриптами в браузере, при которых ответ сразу высвечивается справа, навел на мысли…
Не представляю, как может быть диплом с экономикой в 50 стр.