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, доминаторы — а Клифф потом покажет, как это всё сделать без боли и анальной акробатики.

Пытаюсь изучать SSA. С детства не нравились графы, и все что с ними связано. Приобрёл книжку. Автор препод МФТИ Константин Владимиров ‘Оптимизирующие компиляторы’. Целиком посвящена SSA оптимизациям. У него ещё 4 видео лекции по теме. Читаю в бумажном варианте. Тяжело (((. Еще нашел в электронном виде. Если не встречали могу переслать ))).

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

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

Соглашусь с Вами. На самом деле книжка не произвела сильного впечатления. Правда прочитал тольку половину. А по дизайну обложки, автор как минимум претендует на один ряд с книгой Дракона. А по существу много недосказанности, отсылок к первоисточникам. Хотя есть и плюс. Раскрывается принятая терминология. Автор утверждает, что придерживается исключительно англоязычных терминов.

А по поводу Inria книжки, читаю. Но до устойчивого понимания ещё очень и очень далеко. Надо тянуть и тянуть базовый английский.

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

полистал. на удивление — не очень плохо. правда, необходимость обратного перевода терминов изрядно утомляет. тем не менее — всё ещё не советую.

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

но пока я читал, у меня было стойкое ощущение déjà vu. и через некоторое время я всё-таки понял, что это за книга: такие книги пишут преподаватели чтобы впаривать студентам. не купил — не сдал. полезной же информации там ноль. ещё подобные фолианты удлиняют профессуре список публикаций — который как борода у шаолиньских монахов из старых фильмов «про кун-фу»: бесполезно, но выглядит круто.

если вас угораздило купить это в бумаге, то знайте: вас тупо обули на бабки. именно такими терминами.

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

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

p.s.: без гениальной шутки про «за лупы» (простите, но из песни…) тоже не обошлось. я категорически поддерживаю неформальный стиль изложения (и вообще считаю, что лучший стиль учебника — как в почившей лурке), но шутка и дурацкая, и к месту так же, как дизель на пингвине.

Спасибо. Нет, что подобное и предполагал ещё при покупке книжки. Глянув на обложку, и в особенности на заднию часть, с портретом афтора. А при прочтении обратил внимание на предлагаемые иллюстрационные примеры на неком псевдо языке, понятном только афтору. Бедные, бедные студенты (((.

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

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

p.s.: что характерно — автор или не знает, или старательно избегает libFirm, которая как раз использует SoN (не идеально, насколько я вижу по быстрому листанию кода, но намного лучше, чем ничего). и вместо этого пихает LLVM, которую никому никогда использовать не надо вообще. если хочется «классический» SSA — почему не взять QBE? почему не взять libjit? почему не рассмотреть Nanojit, который очень интересный проект, где автор почти-почти добрался до идеи SoN? QBE вообще почти идеально подходит для изучения: простой входной язык, из которого QBE делает строгий SSA, возможность дампа обратно в этот язык из любой фазы, очень компактный код. бери да разбирай её на кусочки, поясняя, что где как сделано, что ещё можно сделать, и так далее.

Жаль (((. Про столярова, месяца три назад услышал. Порекомендовали для чтения. Посмотрел, сколько-ко то тысяч страниц. Приклеил ярлык - графоман. Закрыл. И сейчас сразу и не вспомнил о каком столярове речь ))).

Ещё интересно Ваше мнение по видео докладу еще одного гуру (там час - но можно по диагонали, основные концепции). Не буду озвучивать свое. Выскажу после Вашего https://www.youtube.com/watch?v=hkK8bvvz9OI

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

а столяров хуже, чем графоман: он вредитель.

Порнолаб у меня в категории 18+ . Это видео пометил, как 21+, а лучше 25+. То есть смотреть можно, но очень осторожно. Кстати он в составе какой то группы разрабатывает компилятор, на основе изложенных идей и приглашает всех желающих.

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

Полностью согласен !!!!!!! Правда, при этом не раз и не два сталкивался. ОУ - у вас самописная программа, мы серьезная организация с таким не работаем (((.