Самый простой способ для SPF:

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


Получится нечто наподобие Форта

... и мы приходим к ShellExecute. Где тут Форт-то? И сейчас можно вызвать компилятор Си, заставить его сделать dll, и обратиться к этой dll. Зачем обязательно набрать весь код транслятора Си на Форте?

Почему-то в консоли после трансляции нового NOTFOUND печатается @@@, а так
вроде работает. Вроде, потому, что неясно будут-ли побочные эффекты.

Это я в devel\~mak\locals1.f забыл убрать ." @@@"

Спасибо - нашел и убрал.

Не понял что за таблица символов и о каком тексте программы на Си идет речь.
Какая задача решается?


Ближе всего, что я имею ввиду, это использование исходного текста компилятора Си
в качестве библиотеки подпрограмм. Однако, хоть я и загнал LCC в SPF я не могу
сказать что разобрался с тем как LCC работает и тем-более что-то использовать
для других задач. Типа того, как я в Форте использую INCLUDED для обработки текстового
файла с подменой INTERPRET.



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



Чтобы избавится от внешнего транслятора Си вместе с dll и за одно, повысить
платформонезависимость. Из внешнего Си компилятора затруднительно иметь доступ
к ресурсам Форта, тем более, делать Форт-вставки. Си в рамках форта может
быть интерпретатором и компилятором в зависимости от переменной STATE,
может участвовать в управлении компиляции (из программы на Си вызывать типа COMPILE,)
и т.д.

Подобное, по-моему, уже пытались сделать в фирме Инфо-форт(сейчас Технофорт).
Надо бы узнать чем это закончилось.

Живьем я их Си не видел. Они меня приглашали, чтобы я оживил их Си
под утерянный Форт, но я несправился.

Это как понять?

Форт-систему модифицировали модифицировали и
незаметели, что старые программы не идут.

Открываем отладчик и начинаем выполнять программу на Си по шагам. При этом мы имеем возможность смотреть переменные по их именам. Компилятор для сопоставления имен и их размещения в памяти имеет таблицу символов.


Ну и зачем так делать? LCC завтра будет другой версии, и опять придется вручную перебивать все на Форте? В конце концов, если уж поставить перед собой задачу разобраться с трансляцией си-подобных языков, то это все можно освоить за приемлемое время. Уже есть и литература, и примеры, и вообще психологический барьер в целом пройден. На человека, который разрабатывает компилятор, уже не смотрят как на неграмотного прожектера, который сам не понимает, во что ввязался. Если действительно надо, можно вести свою ветку разработки. Но просто ради того, "чтобы в Форте был Си" - не знаю, не знаю...

Хм. Мне видится как раз наоборот - определения Форта, гибко "склеивающие" Си-функции в процессе работы программы, вызываются из скомпилированного кода. Си используется здесь как эффективный транслятор, способный сгенерировать быстрый код и дать доступ к библиотекам, Форт - как мощный интерпретирующий язык с возможностью докомпиляции управляющих скриптов в рантайме. Зачем может понадобиться вызов Си из Форта за пределами заранее отправленных в Форт примитивов?

Мне все-таки видится такое утверждение как некая самоцель. Ну хорошо, у нас на машине остался Форт, только Форт, и ничего кроме Форта. Чем это помогает само по себе? Какая конкретная прикладная проблема при повышении платформонезависимости решилась? Я понимаю, когда есть масса заказов, постоянные переходы с платформы на платформу, и вообще миллионные тиражи по всему миру. Тут действительно, чтобы не потерять часть рынка, крупные компании стараются делать платформонезависимые продукты. Какие конкретно "контрольные точки" ты можешь предложить для проверки этой платформонезависимости и вообще эффективности Си?

В рамках Форта это тоже можно организовать. Однако, возможность
вызвать отдельную функцию из командной строки не помешает.



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



Лично мне, плевать на Си и не хочу я с ним разбираться. Реализовать
типы и инфиксную запись в Форте, можно гораздо более простым способом.
Однако, нужно считаться с действительностью.
Для того, чтобы загнать императивный язык в Форт, особо не нужно с ним разбираться.
Один из способов:
Найти где происходит запись в древовидную структуру, как правило, это и будет промежуточное форт-представление. Заменив эту запись на выдачу мнемонических имен мы получаем конвертор в Форт. За тем просто, тупо перевести исходный текст языка на форт.



И так и этак и как угодно.



Одним словом: унификация.

Это что - часть описания работы Си-компилятора?

Это то, что я проделал с LCC для получения CinF.

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


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


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