OberonCore

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

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

Хорошо. Начну от печки. Мне так легче. Стандартные процедуры языка Oberon делим на три группы:

1. ORD, CHR, VAL . . . - механическая замена типа. Внутренняя кухня компилятора.
2. ASH, SHL, INC . . . - алиасы для команд ассемблера. Внутренняя кухня компилятора.
3. NEW, OUT, NewSTR, SumSTR . . . - внешние по отношению к компилятору процедуры. Зона ответственности сборщик исполняемого файла.

Нас интересует 3-я группа. На этапе компиляции адреса процедур не известны. Процедуры размещаются в Kernel (рантайме), присоединяемом на этапе сборки готового приложения.

Теперь динамические строки. Для их размещения используется куча процесса (malloc). Соотвественно, все такие процедуры - создание, удаление, слияние размещаются в Kernel. По другому никак.

Есть вариант вместо malloca использовать alloca, то есть хранить динамические строки не в куче, а на стеке. С точки зрения механики - мало что дает. Если бы не одно но. Управлять кучей можно непосредственно из компилятора (доступ к регистру sp). И тогда alloca не нужен, а динамические строки станут составной частью компилятора. Его внутренней кухней. Никак независящей от внешних составляющих.

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

ps1: Могу, попробовать сделать ассемблерный вариант на своем risc. Но для понимания это мало, что даст. А других ассемблеров у меня нет. Сразу перегоняю в железные инструкции (опкоды) целевого процессора.

ps2: В BB добавить процедуру в 1-ю группу легко, во 2-ю группу уже сложнее. Добавление в 3-ию группу без танцев с бубном и хождения по граблям не получилось. Если требуется могу положить здесь архив со своими добавлениями. Все изменения помечены цветом и выделением.

это очень плохой вариант. во-первых, размер стека ограничен. во-вторых, весь стек просто не существует в памяти сразу, ось выделяет дополнительные стековые страницы по первому сегфолту — именно за этим в компиляторах (CP2 в частности) есть так называемые stack stompers: если размер локалов больше 4кб, то в пролог вставляется «стукалка» с шагом четыре килобайта, чтобы ось выделила все стековые страницы. не будет стукалки — можем улететь в сегфолт даже если технически лимит стека не исчерпан.

в общем, это близко к обыкновенному локальному массиву, и имеет все те же ограничения, что и явный локальный массив. плюс полная невозможность сделать COW и слайсинг. в дельфи строки — refcounted, любого размера (ну, пока память есть). если не такое — тогда нет смысла заморачиваться, можно спокойно по старинке, локальными массивами.

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

да там ничего сложного, просто CP2 очень плохо написан. точнее, он написан нормально, но не на обероне, а на модуле-2, и с приоритетом экономии памяти. поэтому без распечатаной и прибитой на стену дурацкой таблички, которая показывает расклад полей ноды каждого типа — лазить туда БОЛЬ и СТРАДАНИЯ. я, например, эту идиотскую табличку забываю ровно через день после того, как закрыл исходники CP2.

лично я рекомендую лазить в CP2 как можно меньше, и ни в коем случае не брать его как пример для подражания. там минное поле: забыл нюанс раскладки — накосячил, и день ищешь, что же не так. А.А. в Гершеле как раз приводил этот УЖОС в более-менее нормальный вид (хотя лучше его выкинуть полностью, и сделать с нуля нормально).

>>>> это очень плохой вариант. во-первых, размер стека ограничен. во-вторых, весь стек просто не существует в памяти сразу

Ну вот, такую ‘классную’ идею похоронили (((. Зато, вроде стал понимать почему у меня иногда в Linux глючит. Я там без всяких задних мыслей на стеке и по 65 Кб отматываю, без правки sp ))).

>>>> лично я рекомендую лазить в CP2 как можно меньше

Как хорошо, что мне это и не надо. Один раз добавил ORD для BOOLEAN и FRE в Kernel для полной совместимости на уровне исходников с Ormcode. И всё ))).

я вам категорически рекомендую потратить время на изучение SoN, даже если этого времени у вас нет. чтобы потом не оплакивать бесцельно прожитые годы. я вот про SoN знал много лет, но всё как-то руки не доходили внимательно посмотреть. на самом деле я туда залез очень недавно — и натурально понял, что потратил кучу лет на фигню, которую SoN делает играючи.

поверьте, когда вы грок SoN — вы больше никогда не станете писать «простые дубовые» компиляторы. потому что сделать компилятор на SoN не намного сложнее, чем в прямом стиле «чо вижу то и пою», а профита куча.

Судя по тому, что пока удалось понять про SoN. Вся его замечательная прелесть в том, что он позволяет писать «простые дубовые» компиляторы в стиле «чо вижу то и пою». При этом на выходе получая код, открывающий безграничные возможности мультиархитектурной поддержки желелезных процессоров (как и у меня в risc), так и безграничные возможности по оптимизации выходного железного кода (чего да, в risc нет).

Да, придется стать грок SoN. Иначе дальше по-видимому двигаться нет смысла !!!. Спасибо ))).

прелесть SoN в том, что у нас вместо кучи графов с разными сущностями (разными уровнями абстрактного представления кода) — один граф для всего. который обрабатывается очень простым алгоритмом. нам не надо заботиться о синхронизации с другими графами, не надо заводить новые сущности для базовых блоков или работы с памятью — всё это очень изящно представлено такими же нодами, как и прочие, и объединено в одну структуру данных, которую очень просто и очень дёшево поддерживать консистентной. это неимоверно упрощает написание всяких трансформаций кода, на порядки буквально. они получаются чуть ли не сами по себе.

то, что вы упомянули, умеет и «классический» SSA (SoN — это тоже SSA форма). просто с «классикой» намного сложнее работать. SoN даёт всё то же самое, но проще и быстрее. как только у вас в голове уложится то, что порядок инструкций (нод) не имеет никакого значения, всё определяется только связями между ними (constraints) — SoN перейдёт в разряд: «ну ёлы… это же так очевидно!» ;-) там есть минимально достаточный (это важно) набор constraints, который позволяет на финальном этапе из «аморфного» графа построить обратно линейную последовательность. но до этого финального этапа она нам нафиг не нужна. ни она, ни явный отдельный CFG, ни базовые блоки.

p.s.: вам, наверное, сейчас это всё не очень понятно, но не переживайте. почитайте книгу про SSA, там всё нужное есть. а потом читайте про SoN — и увидите, как все те же самые концепции красиво унифицированы в одну общую. в книге вам расскажут, что такое control flow graph (CFG), def-use chains, доминаторы — а Клифф потом покажет, как это всё сделать без боли и анальной акробатики.