[Kopa 0]

В данный момент читаю про кросс-компиляцию (пока наиболее актуально для меня, уже хочется что-то склепать).

 

Для кросс компиляции понадобится создание ассемблера целевой архитектуры и ядра примитивов

в рамках базиса gforth. по примеру содержимого каталога \arch а дальше необходимо изучение

интеграционных возможностей gforth

 

P.S. Схема построения gforth, возможно, переусложнена.

А тесная реализация Форт скриптования при использовании Cи реализации есть, наверное, во всех

Форт системах сделанных на Cи и не только.:)

 

В spf4 для целей макрооптимизации примитивы "разбавлены" служебной информацией и peephole тоже

присутствует, но как я понял пока задачи увеличения "абстрактной" производительности особо не актуальна, в отличии от задачи уплотнения кода.

В gforth примитивы генерируются с помощью утилиты vmgen и оптимизатор Cи не особо может повлиять

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

можно получить ассемблерные кода примитивов и далее их использовать)

Изменено 17 июня, 2009 пользователем Kopa

[MrYuran 23]

Для кросс компиляции понадобится создание ассемблера целевой архитектуры и ядра примитивов

в рамках базиса gforth

А по-моему, достаточно оформить только mashine.h, если не предусматривается использование инлайн-ассемблера

Например, вот для ARM (асм и дизасм отсутствуют)

#if !defined(USE_TOS) && !defined(USE_NO_TOS)
#define USE_TOS
#endif

#ifndef USE_FTOS
#ifndef USE_NO_FTOS
#define USE_FTOS
#endif
#endif

#include "../generic/machine.h"
#include <sys/types.h>

/* this calls a dummy function in cacheflush0.S */
/* you can replace it through "./configure arm_cacheflush=<file>" */
/* if you know how to flush the icache on the arm in general, mail me */
#define FLUSH_ICACHE(addr,size) cacheflush(addr,size)
void cacheflush(void *p, size_t size);

#if defined(FORCE_REG) && !defined(DOUBLY_INDIRECT) && !defined(VM_PROFILING)
/*
according to http://mail-index.netbsd.org/port-arm/2003/05/17/0000.html:

R0-R3: argument passing/caller-saved
R4-R10: callee-saved
R12, R14: caller-saved
R11: frame pointer
R13: stack pointer
*/
/* works with gcc-2.95.2 */
#define RPREG asm("r7")
#endif

а потом подцепить целевой компилятор в мэйкфайле

Хотя ассемблер для MSP намного проще чем для того же 8080

В gforth примитивы генерируются с помощью утилиты vmgen и оптимизатор Cи не особо может повлиять

на код примитивов.

Зато код не привязан к платформе, я тоже такой позиции придерживаюсь.

Тем более, что это всего лишь (как я понял) один из способов построения системы.

Можно и традиционным способом.

[Kopa 0]

А по-моему, достаточно оформить только mashine.h, если не предусматривается использование инлайн-ассемблера

 

Хорошо если это так. ( При этом остаётся неясным как будет создан терминальный канал)

Размер сгенерированного выходного файла может оказаться большим.

 

Зато код не привязан к платформе, я тоже такой позиции придерживаюсь.

 

Не привязан к платформе язык программирования также как и Форт можно

использовать в такой схеме ( например реализовав поддержку минимального числа примитивов, как

в eForth), но Си поддержка уже есть в MSP компиляторе.:)

 

Тем более, что это всего лишь (как я понял) один из способов построения системы.

Можно и традиционным способом.

 

Предполагаю, что это не будет последним вариантом создания Форт системы:)

 

P.S. В gforth есть ещё рекомендация использовать файл cross.fs

Изменено 17 июня, 2009 пользователем Kopa

[MrYuran 23]

Ещё вот такой вопросец не выходит из головы.

Каждое слово заканчивается джампом либо на интерпретатор, либо на следующее слово.

При большом количестве коротких слов (а гуру рекомендуют среднюю длину определения 3-4 слова) получаем большое количество переходов, которые сбрасывают конвейер и сильно замедляют работу по сравнению с линейным кодом.

Конечно, не так сильно, как переход по call-у с передачей параметров, но всё-таки.

 

Или это "обратная сторона медали", плата за компактность кода и простоту системы?

[Kopa 0]

Ещё вот такой вопросец не выходит из головы.

Каждое слово заканчивается джампом либо на интерпретатор, либо на следующее слово.

Конечно, не так сильно, как переход по call-у с передачей параметров, но всё-таки.

 

Или это "обратная сторона медали", плата за компактность кода и простоту системы?

 

Конечно плата т.к. такая реализация, а компактность ещё можно увеличить если

перейти к байт-коду.:)

 

P.S. Компромис, конечно, и в этом случае может существовать,

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

В tinyboot это примерно так и существует. Хорошо иметь при этом профилировщик для

выявления и оценки проблемных мест кода.

[MrYuran 23]

Только что ещё PFE качнул. Буду тоже смотреть.

Пока осматриваюсь для расширения кругозора.

Да и вдруг подходящее что-то готовое есть.

Хочется простенькое c-based ядро, чтобы для начала его впихнуть в общую прошивку как бонус и подцепить на технологический UART.

Активный датчик со встроенным скриптовым движком - крута!

 

Кстати, а если в си определить переменные как структуры из поля имени и поля значения, то их и из форта видно будет :)

только длину имени придётся единообразной делать.

Например, урезать до 5 символов. Заодно и расход памяти меньше.

[Kopa 0]

Только что ещё PFE качнул. Буду тоже смотреть.

Пока осматриваюсь для расширения кругозора.

 

Со своей стороны могу попробовать сделать выборку существующих решений Форт:)

( по мере возможностей ) PFE, вроде с доработкой, использовал Tectroniх.

 

Да и вдруг подходящее что-то готовое есть.

 

Наверное. Но где та "золотая" середина? Форт системы бывают такие разные.

 

Хочется простенькое c-based ядро, чтобы для начала его впихнуть в общую прошивку как бонус и подцепить на технологический UART.

 

Простые решения, бывает, по тем или иным причинам долго ими не остаются:)

 

Активный датчик со встроенным скриптовым движком - крута!

 

И компилятором, как бонус. Защиту только от "дурака" необходимо сделать.

 

Кстати, а если в си определить переменные как структуры из поля имени и поля значения, то их и из форта видно будет :)

только длину имени придётся единообразной

Например, урезать до 5 символов. Заодно и расход памяти меньше.

 

Можно вообще не иметь имён, а в посылках использовать xt идентификаторы.

 

P.S. Мнение разработчиков российской линейки ...

Форт контроллеров

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

Изменено 18 июня, 2009 пользователем Kopa

[MrYuran 23]

Можно вообще не иметь имён, а в посылках использовать xt идентификаторы.

А подробнее можно? Я пока слабо ориентируюсь в терминологии

P.S. Мнение разработчиков российской линейки Форт контроллеров K1894ВГ1T ...

Моё мнение - FPGA-based Forth Kernel - наилучшее применение.

Вместо того чтобы всякую несуразицу навроде 51 ядра туда пихать

 

За наших производителей рад, однако сайты у них - как обычно, как будто какой-то студент на полставки оформляет :laughing:

[Kopa 0]

А подробнее можно? Я пока слабо ориентируюсь в терминологии

 

xt в Форт терминологии это исполнимый токен

Например

 ' Имя ( -- хt )

Исполнить можно с помощью EXECUTE ( xt -- ... )

 

В tinyboot образ в контроллере и IDE синхронизованы ( если сильно не меняются ) и

поэтому для исполнения конкретного слова посылается xt необходимого слова

по отладочному интерфейсу.

 

Моё мнение - FPGA-based Forth Kernel - наилучшее применение.

Вместо того чтобы всякую несуразицу навроде 51 ядра туда пихать

 

Тоже за, но вот потребление и цена ...

 

За наших производителей рад, однако сайты у них - как обычно, как будто какой-то студент на полставки оформляет :laughing:

 

Это похоже на симптомы общей болезни :unsure:

Изменено 18 июня, 2009 пользователем Kopa

[Kopa 0]

Только что ещё PFE качнул. Буду тоже смотреть.

Пока осматриваюсь для расширения кругозора.

 

Pforth тоже можно посмотреть.

 

P.S. Для MSP430 ещё на sourceforge был проект FVM430 ( проект остался, а файлов нет )

можно поднять из архива.

Изменено 19 июня, 2009 пользователем Kopa

[MrYuran 23]

Pforth тоже можно посмотреть.

Спасибо, кажется, намного проще, чем PFE.

И есть забавная фича:

\ @(#) clone.fth 97/12/10 1.1

\ Clone for PForth

\

\ Create the smallest dictionary required to run an application.

\

\ Clone decompiles the Forth dictionary starting with the top

\ word in the program. It then moves all referenced secondaries

\ into a new dictionary.

\

\ This work was inspired by the CLONE feature that Mike Haas wrote

\ for JForth. Mike's CLONE disassembled 68000 machine code then

\ reassembled it which is much more difficult.

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

Если к нему ещё инлайн-оптимизатор подцепить, то вообще зашибись

 

Эх, жаль, скоро опять на работе работать заставят... Только начнешь в чего-то въезжать - опять подсунут какую-то срочную гадость...

 

P.S. Для MSP430 ещё на sourceforge был проект FVM430 ( проект остался, а файлов нет )

Да есть файлы, только в svn, а у нас сисадмин поотрубал все порты нахрен...

Дома попробую скачать.

[Kopa 0]

Хочется простенькое c-based ядро, чтобы для начала его впихнуть в общую прошивку

 

В плане возможной эффективной реализации на С:

Крис Касперски

Борьба с утечками ресурсов и переполняющимися буферами на языковом и внеязыковом уровне

 

Выдержка:

 

Одним их самых мерзких недостатков языка Си является отсутствие поддержки динамических стековых массивов. Стековая память хороша тем, что автоматически освобождается при выходе из функции, однако выделение стековых массивов "на лету" невозможно и мы должны заранее объявить их размеры при объявлении переменных. В C99 сделаны небольшие подвижки в этом направлении и теперь мы можем объявлять массивы, размер которых задается аргументом, передаваемым функции, однако это не решает всех проблем и к тому же C99 поддерживают далеко не все компиляторы.

Изменено 19 июня, 2009 пользователем Kopa

[MrYuran 23]

Начинаю закапываться вглубь :)

Разбираюсь с реализацией шитого кода.

Вот с непрямым (подпрогрсмным) - вроде всё понятно.

Пишем CALL на начало тела следующего слова, в конце слова RET.

Вроде всё сходится.

А прямой код что делает?

Каждый раз возвращает управление интерпретатору?

А тот джампит на следующее слово.

По-моему, так.

Сейчас идея забавная в голову пришла. А что, если немного модифицировать данную схему?

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

Или не встраивать, а вызывать.

Только тогда нужно будет ещё длину слова где-то обозначить.

А в конце каждого слова ставим RET.

Получается, что мы вызываем интерпретатор один раз (оптом) на всё слово.

Таким образом, получаем максимально короткий код, с одной стороны, а с другой - повышенное быстродействие и уменьшение количества переходов и перезагрузок конвейера (говорят, в АРМах это очень критично)

 

Или я тут ерунду понаписал?

[Kopa 0]

Начинаю закапываться вглубь :)

Разбираюсь с реализацией шитого кода.

 

Поиск обсуждения Шитый код на Форт форуме

можно и там проводить обсуждения.

 

А прямой код что делает?

Каждый раз возвращает управление интерпретатору?

А тот джампит на следующее слово.

По-моему, так.

 

В проблематику шитого кода мне не приходилось глубоко вникать:)

 

Но есть такое понимание, что после передачи управления на заданное слово

само слово может поуправлять процессом исполнения адресных ссылок и

коректно произвести возврат. ( исполнитель-интерпритатор ничего и не заметит)

 

Сейчас идея забавная в голову пришла. А что, если немного модифицировать данную схему?

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

Или не встраивать, а вызывать.

 

Пересылки кода возможны, если есть смысл ( подобие кеша ) и если это не приведёт

к неучтённым трудностям.:)

 

Только тогда нужно будет ещё длину слова где-то обозначить.

А в конце каждого слова ставим RET.

Получается, что мы вызываем интерпретатор один раз (оптом) на всё слово.

 

Варианты допустимы любые, на то он и Форт:)

 

Таким образом, получаем максимально короткий код, с одной стороны, а с другой - повышенное быстродействие и уменьшение количества переходов и перезагрузок конвейера (говорят, в АРМах это очень критично)

 

У ARM в самом коде операции присутствует условие её выполнения и проблем с исполнением

Форт кода, предположительно, должно быть меньше.

 

Или я тут ерунду понаписал?

 

Только практика может это определить:)

 

Пока.

Изменено 19 июня, 2009 пользователем Kopa

[mOleg 0]

А прямой код что делает?

Каждый раз возвращает управление интерпретатору?

А тот джампит на следующее слово.

По-моему, так.

вобщем почти так. Вообще классическим для Форта считается косвенный шитый код (ITC) с него стоит начинать разбираться с методикой интерпретации кода. Дело в том, что интерпретатора, как такового вобщем-то и нет. Точнее весь интерпретатор поделен между словами NEXT EXIT ENTER (последнее слово не обязательно так называется, но его суть сохранить адрес возврата на стеке возвратов и выполнить NEXT)

если вас устроит описание на английском видов ШК, то вам сюда

 

Сейчас идея забавная в голову пришла. А что, если немного модифицировать данную схему?

все же советую сначало разобраться с существующими типами ШК.

Кстати, я бы поостерегся что-то еще называть ШК за пределами Форта...

 

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

 

Да, обратите внимание (если еще не зарегистрировались на Forth форуме), что регистрация не автоматическая - надо писать письмо админу (бо спамерюги замучили)