Re[9]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 21.10.09 17:30
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, thesz, Вы писали:


T>>Да, соглашусь.


G>Рановато, ИМХО .


У меня есть соображения.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Есть ли будущее у Native Code?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.10.09 18:54
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, gandjustas, Вы писали:


G>>А для чего может понадобиться ассемблер, кроме установки служебных регистров, работы с портами и прерываниями?


G>К примеру, в процессорах ARM есть специальные инструкции, предназначенные для сохранения 8 регистров сразу. Применются много где — и в коде переключения контекста, и в коде банального memcpy.

G>К примеру, в процессорах ARM есть специальное расширение системы инструкций NEON — применяется при сигнальной обработке и в мультимедийных кодеках. Библиотеки пишутся ручками на ассемблере.

Ну это все говорит только о слабости компиляторов\оптимизаторов. Косвенно о слабости языков разработки.

G>>В Singularity они необходимость ассемблера обошли таким образом: коду драйвера передается экземпляр класса, который отвечает за всю низкооуровневую работу (обращения к этому классу вполне могут компилиться в нужный нативный код).


G>Подстава с применением managed кода здесь не в классах, а в том, что многие безобидные на вид периферийные устройства требуют реакции на прерывания в условиях жесткого реального времени — и это при том, что требования real-time не распространяются на всю систему. Простейший пример — большинство видеоконтроллеров в бытовой электронике требуют от драйвера реакции на каждый полукадр, причем — в жестко отведенное временное окно. А некоторые их них требуют тщательной оптимизации интерфейсного кода.

А причем тут managed код? Разве нельзя обеспечить жесткий реалтайм в таких условиях?
Singularity заявлена как реалтайм система, правда непонятно какой там реалтайм.

G>>Почему нельзя будет для других архитектур процессоров сделать другие классы, наследники какого-либо базового?

G>Есть еще причины. Например, потому, что далеко не все процессоры устроены одинаково. Посмотри внимательно на архитектуру Blackfin — в качестве примера, на что это может быть похожа популярная архитектура.
К несчастью я писал на blackfin (и на других процессорах от Analog Devices). Я например не вижу причин по которым что-либо будет плохо работать на blackfin.
Кстати .NET Microframewok уже есть на этих процессорах.
Re[10]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 21.10.09 20:26
Оценка:
WH>>1)Я конечно в разработки процессоров мало что понимаю но что-то мне подсказывает что уменьшение длинны конвейера (а именно это произойдет при выкидывании нашлепки) скажется на производительности в лучшую сторону.
G>Глубина конвейера не сократится. Декодер команд ты никуда не выкинешь — единственная разница будет в том, что декодер будет выплевывать одну трехадресную микрокоманду в конвейер вместо группы, как это происходит сейчас, и станет чуть-чуть меньше площадью — от туда уйдут конечные автоматы, реализующие трансляцию x86 в трехадресный микрокод.

Глубина конвейера сократится.

Декодирование команды в современных x86 делается в пять этапов, что ли. Больше трёх, это точно.

G>Учитывая возросший размер исполняемого кода, и, как следствие — требования к пропускной способности памяти и размеру кэшей, после твоей модификации для выполнения той же работы (CISC-код заметно компактнее, чем RISC — я наблюдал до 2-х раз, сравни размеры бинарей для SPARC и x86), эффект будет отрицательным, а не положительным.


Beyond Architecture. Система команд load-store, длина команд варьируется. Декодирование делается в один такт. 30-40 процентов сокращения объёма кода.

http://www.beyondsemi.com/page/products/processor_cores
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Есть ли будущее у Native Code?
От: thesz Россия http://thesz.livejournal.com
Дата: 21.10.09 20:48
Оценка:
G>Они простенький такой (по сравнению с остальным фаршем) блок внедряют в декодер команд, в самом начале конвейера, который преобразует х86 в нормальный трехадресный код.

Коллеги по Prosoft жалуются, что им пришлось использовать китайский клон x86. Он был сделан на китайском же варианте какого-то RISC, с нашлёпкой в виде декодера x86 команд.

Так вот, им пришлось отыскать и обойти в ПО плавающую ошибку в этом процессоре — pop ss иногда срабатывал неправильно.

Поэтому этот простенький блок только выглядит простеньким. На самом деле он очень сложен.

G>И весь основной конвейер у таких процессоров построен примерно на тех же принципах, что и конвейер RISC-процессора.


Сложней. Тебе нужны ещё блоки переименования регистров туда и обратно.

G>Оверхэд по площади — смешной для суперскалярного проца на 6 каналов арифметики, а производительность, как ни парадоксально, при таком подходе выше.


Если ты посмотришь на floorplan любого x86, то там здоровенную часть будет занимать x87, хотя даже 2xdouble должно быть в районе, не знаю, миллиметров 16 по площади. А x87 занимает десятки.

Всё потому, что надо переводить из стековой системы команд в регистровую.

G>А знаешь, почему? CISC код более компактен, чем RISC, что снижает требования к пропускной способности памяти, размеру кэшей, итд. А именно это — узкое место в настоящее время.


http://sourceforge.net/mailarchive/forum.php?thread_name=200609161650.k8GGoBSr028429%40pandora1.cs.utsa.edu&forum_name=math-atlas-devel

I've been puzzling over why the best Core2 code uses only 8 active registers,
where the best AMD can use all 16. Dean sent in the missing piece, by
pointing to this technical info goldmine:
http://www.agner.org/optimize/

Turns out that the weakest link on Core2 (and, I think, pretty much all
Intel procs) is the decode step. When you use registers the registers greater
than 7 (eg., %xmm8), this adds a byte to all such operations. 8 output
registers give you only a few instructions that require larger storage,
resulting in ATLAS's kernel using 114 bytes for a given iteration of
the kernel loop. This is important, because this is two 64-byte gulps by
the decoder. Once you add another register as output, this increases the
computation to 3 windows, which apparently is the killer.

Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Есть ли будущее у Native Code?
От: CreatorCray  
Дата: 22.10.09 05:49
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>А что будет если ребятам из интела дать возможность сделать такую систему команд которую они захотят?

А они уже давно сделали
Погугли про Itanium
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Есть ли будущее у Native Code?
От: CreatorCray  
Дата: 22.10.09 07:51
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Объясни пожалуйста вот такой факт:

WH>Каким образом 2х байтовый loop оказался в 5 раз медленней чем 3х байтовая связка из dec и jnz?
Исключительно потому, что LOOP не изменяет флаги вообще. Дальше сам думай.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Есть ли будущее у Native Code?
От: IID Россия  
Дата: 22.10.09 08:09
Оценка:
Здравствуйте, Gaperton, Вы писали:

IID>>Гы, а у меня два x86 компа дома, два компа на Z-80, два на 6502, один на К1801ВМ1 и ещё один — двухпроцессорный на КМ1801ВМ2.


G>И что, это годные, хорошие компы — ты с этих компов можешь писать в RSDN?


С x86 конечно, без проблем Что же касается раритетов... Да, это годные, хорошие компы. Только не понятно как "годность" компа коррелирует с писательством в RSDN Эти компы решают свои задачи ничуть не хуже чем 20-27 лет назад. Современное же железо, строго говоря, эти задачи на 100% решить не может, даже учитывая эмуляцию:
— Отсутствие софта. Да, софт можно написать заново. Но покуда это не будет сделано — задача не решается.
— Ошибки и недочёты в эмуляторах. Буквально месяц назад добавил поддержку аппаратного скроллинга ATM-Turbo2 в эмулятор Spectrum-а unreal. Ковыряние в сорцах эмулятора показало, что многие вещи делаются ужасно неточно и различие с реальным железом будет. Возможно, будет даже фатальным (например чёрный экран или экран с мусором вместо картинки).
— Принципиальная несовместимость железа. Например, PC-шный контроллёр FDD сходит с ума при попытках прочитать защищённые диски ZX-Spectrum. Софт с такого диска ни в одном эмуляторе не прочтётся. А, значит, и не запустится.
kalsarikännit
Re[12]: Есть ли будущее у Native Code?
От: WolfHound  
Дата: 22.10.09 09:48
Оценка:
Здравствуйте, CreatorCray, Вы писали:

WH>>Каким образом 2х байтовый loop оказался в 5 раз медленней чем 3х байтовая связка из dec и jnz?

CC>Исключительно потому, что LOOP не изменяет флаги вообще. Дальше сам думай.
И как это опровергает утверждение о вредности устаревших систем команд?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 22.10.09 09:51
Оценка:
Здравствуйте, kig, Вы писали:

kig>>ИМХО: Не знаю, что там Нортон утверждал и когда, но в начале 60 годов за предложение резервировать часть такого дорогого ресурса (на тот момент), как память под стек при загрузке кода, сослали бы точно.


kig>А объяснить -1?


Памяти ни больше, ни меньше не станет, если частью ее оперировать по стековому механизму. Кроме того, для загрузки кода стек не используется — при чем тут код ?
With best regards
Pavel Dvorkin
Re[23]: Есть ли будущее у Native Code?
От: kig Россия  
Дата: 22.10.09 11:33
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, kig, Вы писали:


kig>>>ИМХО: Не знаю, что там Нортон утверждал и когда, но в начале 60 годов за предложение резервировать часть такого дорогого ресурса (на тот момент), как память под стек при загрузке кода, сослали бы точно.


kig>>А объяснить -1?


PD>Памяти ни больше, ни меньше не станет, если частью ее оперировать по стековому механизму. Кроме того, для загрузки кода стек не используется — при чем тут код ?


Речь о физической памяти? Если о ней — точно больше не станет.
Или речь о механизме виртуальной памяти? Если о ней, боюсь на момент запуска железячного проекта 360 о ней если и говорили, то только в академических кругах. А при отсутствии механизма виртуализации памяти, при загрузке на выполнение кода необходимо в физической памяти зарезервировать место под стек заданной глубины. А если учесть, что в 360 одновременно могло исполняться 15 заданий (+ сам супервизор), резервирование памяти под стек для заданий при запуске в общем случае понижали общую пропускную способность системы.
Что бы не было недопонимания — под заданием подразумевается код, исполняющийся под конкретным (!=0x0) ключом защиты в PSW.
Re[24]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 22.10.09 12:48
Оценка:
Здравствуйте, kig, Вы писали:

kig>Речь о физической памяти? Если о ней — точно больше не станет.

kig>Или речь о механизме виртуальной памяти?

Виртуальной памяти в первых версиях OS/360 (MFT, MVT) не было. Впервые появилась ИМХО в OS/SVS для 370.
With best regards
Pavel Dvorkin
Re[25]: Есть ли будущее у Native Code?
От: kig Россия  
Дата: 22.10.09 14:13
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, kig, Вы писали:


kig>>Речь о физической памяти? Если о ней — точно больше не станет.

kig>>Или речь о механизме виртуальной памяти?

PD>Виртуальной памяти в первых версиях OS/360 (MFT, MVT) не было. Впервые появилась ИМХО в OS/SVS для 370.


После появления 370 с аппаратной поддержкой механизма виртуализации памяти первой ОС, которая этот механизм пользовала — была MVS/370 (70 год). А в 72 IBM выкатила сразу четверку — OS/VS1 (наследник MFT), SVS aka OS/VS2R1 (наследник MVT), DOS/VS (наследник DOS/360) и VM/370.

Ну а по поводу стека сказать что-нибудь?
Re[26]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 23.10.09 12:51
Оценка:
Здравствуйте, kig, Вы писали:

kig>После появления 370 с аппаратной поддержкой механизма виртуализации памяти первой ОС, которая этот механизм пользовала — была MVS/370 (70 год). А в 72 IBM выкатила сразу четверку — OS/VS1 (наследник MFT), SVS aka OS/VS2R1 (наследник MVT), DOS/VS (наследник DOS/360) и VM/370.


Все верно. После. А при проектировании 360 его "сослали". 370 еще не было.

kig>Ну а по поводу стека сказать что-нибудь?


Да то же самое. Не было тогда еще никакой виртуальной памяти, в 1964 году, когда первые модели 360 появились. И аппаратной поддержки не было, ты сам об этом пишешь. Если же говорить вообще о системе с ограниченной памятью — так в IBM PC на базе 80286 виртуальная память была (на основе LDT-GDT), хотя объем памяти был 1 Мб, как правило. Это не мешало выделить под стек свой сегмент размером не более 64 Кб. И стеки эти у разных задач (в смысле задач процессора 80286, которые реально в Windows 3.1 не использовались) были свои.
With best regards
Pavel Dvorkin
Re[27]: Есть ли будущее у Native Code?
От: kig Россия  
Дата: 26.10.09 14:47
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, kig, Вы писали:


kig>>После появления 370 с аппаратной поддержкой механизма виртуализации памяти первой ОС, которая этот механизм пользовала — была MVS/370 (70 год). А в 72 IBM выкатила сразу четверку — OS/VS1 (наследник MFT), SVS aka OS/VS2R1 (наследник MVT), DOS/VS (наследник DOS/360) и VM/370.


PD>Все верно. После. А при проектировании 360 его "сослали".


Если при проектировании сослали, где же стек в 360?

kig>>Ну а по поводу стека сказать что-нибудь?


PD>Да то же самое. Не было тогда еще никакой виртуальной памяти, в 1964 году, когда первые модели 360 появились. И аппаратной поддержки не было, ты сам об этом пишешь. Если же говорить вообще о системе с ограниченной памятью — так в IBM PC на базе 80286 виртуальная память была (на основе LDT-GDT), хотя объем памяти был 1 Мб, как правило. Это не мешало выделить под стек свой сегмент размером не более 64 Кб. И стеки эти у разных задач (в смысле задач процессора 80286, которые реально в Windows 3.1 не использовались) были свои.


Как то ты на 80286 переключился... Мы говорим вообще о системах с ограниченной памятью, или о 360, за "которую сослали"?

Так то же самое говоришь? Сравни — из первых трех продаваемых моделей — страшая из них — 40 могла иметь аж до 256 Кб. Память до 1 Мб появилась только в самых дорогих 65 и 75 моделях (конец 65 — начало 66). Вот здесь характерное замечание по поводу оперативной памяти уже более поздней эпохи (начало 70-х):

One interesting thing you might add to your 360/30 info is that in the early 70's a company in Edina Minnesota, Fabri-tek, manufactured core memory for IBM computers. 32K was about $40,000 dollars.


А теперь вернемся к началу 60 годов, операционках для 360 и стеку.

В MFT надо было сразу резервировать, сколько тебе памяти под задание отводить — и в этом случае, что стек, что не стек, память на задание сразу "кушалась". Запрос на динамическое выделение памяти возвращал адрес из остатка резерва — по сути куча на задание.

В MVT ситуация была другая. В ней, в отличии от MFT, было не только переменное кол-во разделов под задание, но и заказывать надо было возможный максимальный размер памяти на задание, который выделялся не сразу. И запрос на динамическое выделение памяти возвращал адрес из общей кучи, которая управлялась супервизором. Естественно, с учетом аппаратной защиты супервизор выделял память для каждого задания с наименьшей атомарность == странице (оффтоп: в PL/1 для этого был свой манагер памяти).

А теперь представь, как в MVT изменилось бы поведение, при многозадачной пакетной обработке, если бы при запуске задания необходимо было бы сразу резервировать непрерывное пространство памяти под стек. Как бы уменьшилась общая пропускная способность системы. Что для повышения пропускной способности необходимо было бы учеличивать общий объем оперативной памяти. И при этом не забудь учесть эпоху — стоимость памяти на начало проектирования и переспектив ее понижения. Кто тогда делал прогнозы, что стоимость оперативной памяти через 20 лет рухнет на порядки? Что те шкафы, которая и была ОП в 360, превратиться в сборку нескольких кристаллов (PC/AT)?
Re[28]: Есть ли будущее у Native Code?
От: Pavel Dvorkin Россия  
Дата: 27.10.09 05:06
Оценка:
Здравствуйте, kig, Вы писали:


kig>>>После появления 370 с аппаратной поддержкой механизма виртуализации памяти первой ОС, которая этот механизм пользовала — была MVS/370 (70 год). А в 72 IBM выкатила сразу четверку — OS/VS1 (наследник MFT), SVS aka OS/VS2R1 (наследник MVT), DOS/VS (наследник DOS/360) и VM/370.


PD>>Все верно. После. А при проектировании 360 его "сослали".


kig>Если при проектировании сослали, где же стек в 360?


Так зато и сослали, что не заложил


PD>>Да то же самое. Не было тогда еще никакой виртуальной памяти, в 1964 году, когда первые модели 360 появились. И аппаратной поддержки не было, ты сам об этом пишешь. Если же говорить вообще о системе с ограниченной памятью — так в IBM PC на базе 80286 виртуальная память была (на основе LDT-GDT), хотя объем памяти был 1 Мб, как правило. Это не мешало выделить под стек свой сегмент размером не более 64 Кб. И стеки эти у разных задач (в смысле задач процессора 80286, которые реально в Windows 3.1 не использовались) были свои.


kig>Как то ты на 80286 переключился... Мы говорим вообще о системах с ограниченной памятью, или о 360, за "которую сослали"?


Ты сам сделал упор на то, что причиной отсутствия стека было ограниченное количество памяти, вот я и привел контрпример.

kig>Так то же самое говоришь? Сравни — из первых трех продаваемых моделей — страшая из них — 40 могла иметь аж до 256 Кб. Память до 1 Мб появилась только в самых дорогих 65 и 75 моделях (конец 65 — начало 66). Вот здесь характерное замечание по поводу оперативной памяти уже более поздней эпохи (начало 70-х):


Да, знаю. Джермейна я еще не забыл


kig>А теперь вернемся к началу 60 годов, операционках для 360 и стеку.


kig>В MFT надо было сразу резервировать, сколько тебе памяти под задание отводить — и в этом случае, что стек, что не стек, память на задание сразу "кушалась". Запрос на динамическое выделение памяти возвращал адрес из остатка резерва — по сути куча на задание.


kig>В MVT ситуация была другая. В ней, в отличии от MFT, было не только переменное кол-во разделов под задание, но и заказывать надо было возможный максимальный размер памяти на задание, который выделялся не сразу.


Сразу он выделялся. Команду DA я хорошо помню. Да и как можно не сразу выделить при отсутствии виртуальной памяти ? куда потом расширять ? Не было там перераспределения памяти. А вот число разделов, да, было переменным.

Вот, кстати (выделено мной)

It treated all memory not used by the operating system as a single pool from which contiguous "regions" could be allocated as required by an indefinite number of simultaneous application programs. This scheme was more flexible than MFT's and in principle used memory more efficiently, but was liable to fragmentation — after a while one could find that, although there was enough spare memory in total to run a program, it was divided into separate chunks none of which was large enough.[2]

http://en.wikipedia.org/wiki/OS/360#cite_note-AuslanderJaffeIBMVSOSsDAT-1

Если бы можно было выделять не непрерывные участки — какая такая фрагментация могда бы мешать ?

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


Хм. Если бы это было так, то неизбежно память выделялась бы задаче кусками, фрагментами. Но я прекрасно помню, что по команде DA показывался адрес начала и размер, то есть один кусок.

>Естественно, с учетом аппаратной защиты супервизор выделял память для каждого задания с наименьшей атомарность == странице (оффтоп: в PL/1 для этого был свой манагер памяти).


Не помню про страницы, ИМХО их не было вообще. Были какие-то блоки с ключами защиты. Впрочем, не помню точно.

kig>А теперь представь, как в MVT изменилось бы поведение, при многозадачной пакетной обработке, если бы при запуске задания необходимо было бы сразу резервировать непрерывное пространство памяти под стек. Как бы уменьшилась общая пропускная способность системы. Что для повышения пропускной способности необходимо было бы учеличивать общий объем оперативной памяти. И при этом не забудь учесть эпоху — стоимость памяти на начало проектирования и переспектив ее понижения. Кто тогда делал прогнозы, что стоимость оперативной памяти через 20 лет рухнет на порядки? Что те шкафы, которая и была ОП в 360, превратиться в сборку нескольких кристаллов (PC/AT)?


Поскольку память выделялась отдельным непрерывным участком, от того, что к части ее доступ был бы по стековому механизму, ничего в плане потребностей по памяти не изменилось бы.
With best regards
Pavel Dvorkin
Re: Есть ли будущее у Native Code?
От: TimurSPB Интернет  
Дата: 27.10.09 20:54
Оценка:
Здравствуйте, Chrome, Вы писали:

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?

C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

Вопрос из серии:
Есть ли будущее у программистов, или их вытеснит искусственный интеллект?
Make flame.politics Great Again!
Re[29]: Есть ли будущее у Native Code?
От: kig Россия  
Дата: 29.10.09 16:08
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

[]

kig>>В MVT ситуация была другая. В ней, в отличии от MFT, было не только переменное кол-во разделов под задание, но и заказывать надо было возможный максимальный размер памяти на задание, который выделялся не сразу.


PD>Сразу он выделялся. Команду DA я хорошо помню.


Да. Ты прав. Разделяемая память только в MVS появилась, но там уже виртуальная память была.
Так что все соображения по поводу стека и резервирования памяти снимаются

PD>Да и как можно не сразу выделить при отсутствии виртуальной памяти ? куда потом расширять ? Не было там перераспределения памяти. А вот число разделов, да, было переменным.


Ниже.

PD>Вот, кстати (выделено мной)


PD>It treated all memory not used by the operating system as a single pool from which contiguous "regions" could be allocated as required by an indefinite number of simultaneous application programs. This scheme was more flexible than MFT's and in principle used memory more efficiently, but was liable to fragmentation — after a while one could find that, although there was enough spare memory in total to run a program, it was divided into separate chunks none of which was large enough.[2]


PD>http://en.wikipedia.org/wiki/OS/360#cite_note-AuslanderJaffeIBMVSOSsDAT-1


PD>Если бы можно было выделять не непрерывные участки — какая такая фрагментация могда бы мешать ?


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


PD>Хм. Если бы это было так, то неизбежно память выделялась бы задаче кусками, фрагментами. Но я прекрасно помню, что по команде DA показывался адрес начала и размер, то есть один кусок.


Для того, что бы реализовать такой механизм (алгоритм), ничего придумывать. Он уже в MVT был. По сути, тот же, который выделяет непрерывные участки под разделы. И потом смежные "дырки" схлопывает в непрерывный участок. Правда, это бы еще больше увеличило фрагментацию памяти.

>>Естественно, с учетом аппаратной защиты супервизор выделял память для каждого задания с наименьшей атомарность == странице (оффтоп: в PL/1 для этого был свой манагер памяти).


PD>Не помню про страницы, ИМХО их не было вообще. Были какие-то блоки с ключами защиты. Впрочем, не помню точно.


Были. По 2К (возможно на старших моделях — по 4К. В 370 — точно по 4К).

[]

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


Да. Согласен.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.