Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Сб авг 24, 2019 12:52

...
Google Search
Forth-FAQ Spy Grafic

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




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - Новый подход к генерации Фортом машинного кода
Автор Сообщение
  Заголовок сообщения:  Re: Новый подход к генерации Фортом машинного кода  Ответить с цитатой
Хочу сказать огромное спасибо этой теме! Прочитав перевод статьи Антона Эртла я всерьёз задумался о том, что именно может сделать автоматически оптимизатор Форта и нашёл неожиданное решение для Каллисто-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 Побольше вдохновляющих тем!
Сообщение Добавлено: Сб фев 23, 2019 04:02
  Заголовок сообщения:  Re: Новый подход к генерации Фортом машинного кода  Ответить с цитатой
Кто хотел LLVM "Форт"? :)

LLForth Experimental Forth implementation in LLVM.

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

P.S. Ещё, возможно, интересно FLK is an optimizing native code forth compiler.
Сообщение Добавлено: Пт фев 22, 2019 02:40
  Заголовок сообщения:  Re:  Ответить с цитатой
Хищник писал(а):
Ну и тогда уж, до кучи. Вот мы сейчас смотрим на LLVM с целью написания back-endа для процессорного ядра QuarkR.

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

P.S. В начале декабря вышла 3.0 версия LLVM.
Сообщение Добавлено: Пт дек 23, 2011 08:07
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
be_nt_all писал(а):
код для gcc генерировать ещё проще (хотя у llvm оптимизатор, судя по всему, лучше). Опять же gcc - это самый что ни на есть мейнстрим, а llvm и, тем более, cacao vm - ещё нет.

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

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

P.S. Есть и компилятор stkrc для генерации байт кода.
Сообщение Добавлено: Пт фев 19, 2010 20:22
  Заголовок сообщения:   Ответить с цитатой
be_nt_all писал(а):
Вон Михаил свой оптимизатор таки забросил.

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

Что касается предлагаемого метода. Здесь завязана оптимизация на компиляцию.
Что черевато несовместимостью т.к. Форт предоставляет программисту вмешиваться
в процесс компиляции. Оптимизация при этом явно ограничена. Вообще не
вижу преимущества над моим методом.
Сообщение Добавлено: Пт янв 29, 2010 17:15
  Заголовок сообщения:   Ответить с цитатой
be_nt_all писал(а):
И кто-то должен всё это доводить, доводить и доводить... Пока всё это не доведёт его. Вон Михаил свой оптимизатор таки забросил.

Процедуры конкретных доводок просты: берете и делаете(если надо). Никому, в том числе и Михаилу уже не сильно надо. Уже и так все быстро, все основные
моменты уже выбраны. А если что-то на практике встретится медленное можно и ускорить по случаю и очень оперативно. Так сказать оптимизация по необходимости.
Возьмем форт-систему от MPE (VFX). Там уже сделано нечто подобное тому, что предлагал Ертль. И что она на
порядок быстрее СПФ? Таки нет же. Только чуть.
be_nt_all писал(а):
Любая оптимизирующая кодогенерация (если не использовать чужой промежуточный транслятор, где доводкой занимается кто то другой) включает такой элемент, но peephole из него одного и состоит.

А вот это совсем плохо - значит в оптимизаторе надо вручную подключать веер peеphole-разрешений кода.
Сообщение Добавлено: Пт янв 29, 2010 17:04
  Заголовок сообщения:   Ответить с цитатой
chess писал(а):
Оптимальность тут обеспечивается не единым алгоритмом оптимизации, а набором частных подстановок, каждая из которых доведена до ума вручную
с учетом всех возможностей целевого кода.


И кто-то должен всё это доводить, доводить и доводить... Пока всё это не доведёт его. Вон Михаил свой оптимизатор таки забросил. Любая оптимизирующая кодогенерация (если не использовать чужой промежуточный транслятор, где доводкой занимается кто то другой) включает такой элемент, но peephole из него одного и состоит.

chess писал(а):
В Форте тоже можно хорошо задействовать(если понадобится).


Или определением набора векторных слов, или через оптимизацию. Второй способ ничем, по сути, не отличается от того, что в C/Fortran.
Сообщение Добавлено: Пт янв 29, 2010 15:37
  Заголовок сообщения:   Ответить с цитатой
be_nt_all писал(а):
upd. Имхо, как раз таки peephole (щелевая) оптимизация работает с кодом целевой машины.

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

be_nt_all писал(а):
А так, SSE очень хорошо задействовать в языках вроде J и K.

В Форте тоже можно хорошо задействовать(если понадобится).
Сообщение Добавлено: Чт янв 28, 2010 11:06
  Заголовок сообщения:   Ответить с цитатой
dynamic-wind писал(а):
это ж freeforth
;;; . almost SWAP-free thanks to compile-time renaming of the two registers
;;; caching the top two DATAstack cells

замечательно! :D
Сообщение Добавлено: Ср янв 27, 2010 21:19
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
насчет оптимизаций. Появилась еще идея о возможности использования практики register renaming в достаточно простой форме.

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

возможно, кто-то уже делал подобное.?


это ж freeforth
;;; . almost SWAP-free thanks to compile-time renaming of the two registers
;;; caching the top two DATAstack cells
Сообщение Добавлено: Ср янв 27, 2010 21:17
  Заголовок сообщения:   Ответить с цитатой
Ну и тогда уж, до кучи. Вот мы сейчас смотрим на LLVM с целью написания back-endа для процессорного ядра QuarkR. Он предполагается к изготовлению на "Ангстреме" по технологии 0,13 мкм, работать должно на 200 МГц (собственно, дизайн-центр имеет неплохие контакты в ЮВА, и "Ангстрем" - не единственная доступная foundry). В процессоре 32 бита и 32 симметричных регистра, трехадресные и стековые команды выполняются одновременно, без какого-либо переключения режимов (при старте указатель стека стоит на R31, так что к нему можно получить доступ и стековыми, и не-стековыми командами). Таким образом, вопрос об оптимизации работы со стеком не стоит - Форт поддерживается аппаратно, но и Си ляжет достаточно неплохо. Я отнюдь не призываю "пристроиться в хвост колонны", но вот вам пример российского продукта, под который пока нет средств разработки. Вот табличка с системой команд, можно заметить, что правила описания back-end-а довольно-таки регулярны.
Изображение
Сообщение Добавлено: Ср янв 27, 2010 21:13
  Заголовок сообщения:   Ответить с цитатой
Могу привести в качестве примера один use case по кварку. Преимущественный способ его использования - последовательные Evaluate строк, подаваемых модулем, к которому кварк подключен как библиотека. Модуль, разумеется, может захотеть посмотреть на состояние стека после выполнения некоторых действий. Если при этом вершина будет лежать в регистре, это обернется определенными сложностями - вершину стека, и остальной стек придется смотреть по-разному.
Сообщение Добавлено: Ср янв 27, 2010 21:06
  Заголовок сообщения:   Ответить с цитатой
chess писал(а):
Там нет и вряд-ли будет даже что-то отдаленно похожее.


А что из себя их форт представляет?
Сообщение Добавлено: Ср янв 27, 2010 20:46
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
имхо, я тут согласен с Хищником: не нужно думать о резонансе, нужно думать о полезных и нужных вещах.


Это конечно да.

Ну если этой полезной вещью будет пользоваться 2 с половиной человека, она просто заглохнет.

И меня, кстати, тоже Хищник кое в чём убедил. В том, что надо планировать токую задачу, которую можно довести до конца. Незаконченной полезной вещью не будут пользоваться даже два с половиной человека.

Если дипломник Эртла (не использовавший раньше Форт) смог осилить работающий прототип компилятора подмножества gForth в Си (на gforth), который обогнал по быстродействию полученных программ все протестированные компиляторы Форта, имевшиеся в 1996, это даёт основание рассчитывать, что такой проект (только компилятора с полноценного форта) я в одиночку потяну.

А вот то, что единственный нативный OpenSource форт-компилятор, использующий что-то умнее простых inlining+peephole — это bigForth, изначально написанный как коммерческий проприетарный продукт внушает совсем другие чувства. Скажем так, опасения.
Сообщение Добавлено: Ср янв 27, 2010 20:43
  Заголовок сообщения:   Ответить с цитатой
be_nt_all писал(а):
У http://theforthsource.com/ случайно нету?

Там нет и вряд-ли будет даже что-то отдаленно похожее.
Сообщение Добавлено: Ср янв 27, 2010 20:36

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


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