Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт сен 19, 2019 06:08

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 35 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Пт янв 29, 2010 17:15 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
be_nt_all писал(а):
Вон Михаил свой оптимизатор таки забросил.

В какой-то мере. Руки не доходят. Я продвину оптимизатор если появится
критический по быстродействию фрагмент кода. Быстродействие моих программ
меня устраивает. Если кому надо, предъявляйте фрагменты кодов.
Если кто самостоятельно захочет добавить правило, пусть задает вопросы.

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт фев 19, 2010 20:22 
Не в сети
Moderator
Moderator

Зарегистрирован: Ср май 10, 2006 15:37
Сообщения: 1132
Откуда: Chelyabinsk ( Ural)
Благодарил (а): 0 раз.
Поблагодарили: 9 раз.
mOleg писал(а):
be_nt_all писал(а):
код для gcc генерировать ещё проще (хотя у llvm оптимизатор, судя по всему, лучше). Опять же gcc - это самый что ни на есть мейнстрим, а llvm и, тем более, cacao vm - ещё нет.

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

Stacker Forth-подобный язык в LLVM

P.S. Есть и компилятор stkrc для генерации байт кода.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re:
СообщениеДобавлено: Пт дек 23, 2011 08:07 
Хищник писал(а):
Ну и тогда уж, до кучи. Вот мы сейчас смотрим на LLVM с целью написания back-endа для процессорного ядра QuarkR.

продвижение LLVM back-end существует?
В репозитарии LLVM есть реализация front-enda некоторого стекового языка Stacker.

P.S. В начале декабря вышла 3.0 версия LLVM.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: Новый подход к генерации Фортом машинного кода
СообщениеДобавлено: Пт фев 22, 2019 02:40 
Не в сети

Зарегистрирован: Пн янв 07, 2013 22:40
Сообщения: 1107
Благодарил (а): 3 раз.
Поблагодарили: 41 раз.
Кто хотел LLVM "Форт"? :)

LLForth Experimental Forth implementation in LLVM.

Немного другой подход и инструментарий FirmForth

P.S. Ещё, возможно, интересно FLK is an optimizing native code forth compiler.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Новый подход к генерации Фортом машинного кода
СообщениеДобавлено: Сб фев 23, 2019 04:02 
Хочу сказать огромное спасибо этой теме! Прочитав перевод статьи Антона Эртла я всерьёз задумался о том, что именно может сделать автоматически оптимизатор Форта и нашёл неожиданное решение для Каллисто-2, основанное на комбинации шитого и подпрограммного кода. Интересно, был ли у кого-нибудь опыт подобного?

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

Вот, как это будет устроено. Допустим, у нас есть слово высокого уровня COUNT:
: COUNT ↑ 1+ ↔ C@ ;

В таблице свёрток есть адрес обработчика этого слова, например ZCount. Через эту таблицу COUNT будет вызывать высокоуровневый код из области данных. Поэтому он будет обращаться к реализации Count в подпрограммном коде через преамбулу, КБП9 передаёт управление на NEXT:

ZCount: ПП Count КБП9
Count: ПП Dup 1 + ↔ БП Cat

Адрес Count используется для обращения к Count из подпрограммного кода в памяти программ. Такие же метки Dup и Cat используются для подпрограммной реализации примитивов ↑ и C@ например:

Cat: ПА ↔ КИПА В/О

Обращение к последнему слову C@ происходит через БП. Это обычная оптимизация более длинной и долгой фразы ПП Cat В/О. В теории даже от БП можно избавиться, размещая обработчики друг за другом. Простые обработчики слов 1+ и ↔ помещены прямо в код COUNT, в виде команд на языке МК-161.

Конечно же, для ↑ 1+ ↔ C@ существуют свои трёхшаговые «преамбулы» для вызова из шитого кода. Впрочем, адресный интерпретатор может при вызове обработчика сам делать КПП вместо КБП, самостоятельно делая NEXT после возврата. Над этим ещё подумаю, но в целом картина оптимистичная и существенно повышает быстродействие Каллисто.

Пока оптимизацию буду делать вручную, но сама возможность перехода на более быстрый и хорошо оптимизирующийся подпрограммный код, с сохранением исполнения шитого кода из области данных (основное требование гарвардской архитектуры 8051), обрадовал. Пользуясь случаем, поздравляю всех с 23 февраля. :D Побольше вдохновляющих тем!


Вернуться к началу
  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 35 ]  На страницу Пред.  1, 2, 3

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB