Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пн июн 18, 2018 23:36

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 39 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Сб июл 26, 2008 20:56 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4920
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 56 раз.
А вы не знакомы с постскриптом случайно?
И, судя по всему получилась динамическая проверка типов?

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб июл 26, 2008 20:58 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4920
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 56 раз.
кстати, с сим опусом знакомы StrongForth ?

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб июл 26, 2008 21:11 
Не в сети

Зарегистрирован: Сб июл 26, 2008 06:22
Сообщения: 21
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
Хищник писал(а):
Речь немножко не об этом. Если мы уже двинулись в сторону мультиплатформенности, причем не диаметрально противоположной, то неплохо было бы сделать так, чтобы действительные различия были вынесены в отдельный слой. Иначе нам под каждую платформу и под каждый стиль придется писать свою программу, а из-за какого-нибудь "очень полезного" вызова WinAPI этот же модуль не пойдет на ARM. Хотя ARM сам по себе не такая уж слабая платформа, и вполне можно иметь некий репозиторий модулей, реализующих разные алгоритмы (скажем, сортировка массивов или поиск пути), и одинаково успешно транслирующихся под самые разные платформы. Как сегодня часто бывает, сегодня PC, завтра попросили то же самое в коробочке под ARM, а послезавтра в ПЛИС упаковали со всей периферией. Что же теперь, софт переписывать?


Давай отделим лягушек от цапель?
Есть аппаратурно-зависимые функции, есть общие для любой системы - те, что ты назвал - сортировки, поиски и прочее.
Так вот - словарь stddict - только их и содержит.

Если я буду писать слова, которые жёстко привязаны ТОЛЬКО к SAM7, например - поддержка UART - то я создам отдельный словарь, скажем sam7.dict и в нём опишу слова, что будут поддерживать UARTы этого процессора.
Например UARTWRITE и UARTREAD

Потом мне понадобятся слова для UARTов AVR - я создам словарь AVR.dict - и в нём пропишу, что мне надо.
Слова для работы с UART - те же UARTWRITE и UARTREAD.

для SAM7 файл dict.lst будет выглядеть так:

stddict
sam7.dict

А для AVR файл dict.lst будет выглядеть так:

stddict
AVR.dict

При этом всем программам будет глубоко начихать на какой из этих форт-машин они запустятся - они всё равно найдут и выполнят слова UARTWRITE и UARTREAD. И оправят-примут данные по COM-порту.

Точно так же - и с другим оборудованием.

И мешать эти одноимённые слова в разных словарях друг другу не будут - поскольку эти словари вместе НИКОГДА компилироваться не будут.

Фактически имеется вот какие варианты запуска ФОРТ-машины:

1. Форт-система на "голом" железе. Без всякой ОС как таковой. Тут без всякой болды - под каждый процессор-перефирию писать свои реализации нужных слов. В aForth - это отдельный словарь для всех аппаратно-зависимых слов под каждую платформу индивидуально. Естественно, что слова для работы с видеоускорителем на AVR ну никак не нужны. Хотя можно (как ты уже предлагал) ставить заглушки. И если уж какая хитрая и нужная фича есть в одном железе - то её можно эмулировать программно в конце концов.

2. Форт-система, как надстройка над ОС. Тогда аппаратно-зависимые слова - больше проблема самой ОС. Я уже 3 года вплотную (по работе) занимаюсь прикручиванием ОС LINUX к ARM9 (AT91RM9200). Так вот, смею заверить - после установки ядра - все программы идут абсолютно одинаково что скомпилированные под Linux на моём компе, что на платке с ARM9. И сеть и интернет и ppp и всё остальное. Поэтому при работе форт-системы в качестве надстройки над ОС - проблема "на той платформе в ос вызов есть - на этой платформе в ос вызова нет = смерть" - малореально для нормальных ОС. Виндовс к нормальным (с точки зрения переносимости) не относится и никто в здравом уме с ней не будет для этих целей связываться.

Хищник писал(а):
В принципе, разновидность тэга.
А вообще интересный подход, welcome в нашу форумную компанию! :)


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

Спасибо :) Я уже здесь :)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб июл 26, 2008 21:21 
Не в сети

Зарегистрирован: Сб июл 26, 2008 06:22
Сообщения: 21
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
mOleg писал(а):
А вы не знакомы с постскриптом случайно?


Знаком чуть-чуть. У меня (если в исходники глянете) есть файлы с расширением .dsc.
В них хранится краткое описание на каждое слово словаря в формате LaTeX (буквально пара тегов).
Если набрать make doc, то автоматически скомпилируется документ в формате pdf и он же - в формате dvi, описывающий текущие подключенные словари. Таким образом исключаются ошибки - описания слов, которых нет или наоборот "забыл вставить описание слова". А написать коротенький .dsc файл после написания нового слова - нетрудно. В общем - железная зависимость - есть слово в текщих словарях - есть и описание в документе. Очень удобно!

mOleg писал(а):
И, судя по всему получилась динамическая проверка типов?


Что имеется ввиду под динамической проверкой ? Если то, что "пихаем на стек что угодно - узнаём тип", то - да.

mOleg писал(а):
кстати, с сим опусом знакомы StrongForth ?


Нет. Но познакомлюсь.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб июл 26, 2008 21:30 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4920
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 56 раз.
SfS писал(а):
mOleg писал(а):А вы не знакомы с постскриптом случайно?
Знаком чуть-чуть. У меня (если в исходники глянете) есть файлы с расширением .dsc.

нет, речь шла вот эоб этой книге: ThinkingInPostScript

SfS писал(а):
mOleg писал(а):И, судя по всему получилась динамическая проверка типов?
Что имеется ввиду под динамической проверкой ? Если то, что "пихаем на стек что угодно - узнаём тип", то - да.

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

SfS писал(а):
mOleg писал(а):кстати, с сим опусом знакомы StrongForth ?
Нет. Но познакомлюсь.

просто там тоже контроль типов (правда статический).

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб июл 26, 2008 22:22 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6327
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
SfS писал(а):
Давай отделим лягушек от цапель?
Есть аппаратурно-зависимые функции, есть общие для любой системы - те, что ты назвал - сортировки, поиски и прочее.
Так вот - словарь stddict - только их и содержит.

Если я буду писать слова, которые жёстко привязаны ТОЛЬКО к SAM7, например - поддержка UART - то я создам отдельный словарь, скажем sam7.dict и в нём опишу слова, что будут поддерживать UARTы этого процессора.
Например UARTWRITE и UARTREAD

Все правильно. Просто мне уже давно интересно как можно тщательнее проработать интерфейс с аппаратно-зависимым слоем, поскольку при описанном подходе впереди маячит мешанина из аппаратно-зависимых слов с разными форматами вызова на разных платформах. Если, конечно, сразу не спланировать стыковку.
SfS писал(а):
1. Форт-система на "голом" железе. Без всякой ОС как таковой.

С подвариантами:
а) Форт-система на "голом" железе типа PC, ARM и прочего. Требуется эмуляция стековой машины и разработка драйверов.
б) Форт-система на Форт-процессоре.
SfS писал(а):
2. Форт-система, как надстройка над ОС. Тогда аппаратно-зависимые слова - больше проблема самой ОС.

Линукс и Windows здесь имеют одинаковые права на существование, и опять же интересно как можно сильнее расширить класс программ, которые одинаково пойдут и там, и там.
SfS писал(а):
ОС LINUX к ARM9 (AT91RM9200). Так вот, смею заверить - после установки ядра - все программы идут абсолютно одинаково что скомпилированные под Linux на моём компе, что на платке с ARM9

Для линукса это, в принципе, нормально. И, если угадаю, Форт туда пришел в том числе и для сокращения количества make all при отладке системы? :)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб июл 26, 2008 22:25 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6327
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
SfS писал(а):
Что имеется ввиду под динамической проверкой ? Если то, что "пихаем на стек что угодно - узнаём тип", то - да.

CTTI (Compile-Time Type Inference) - контроль типов в процессе компиляции, программа работает "не глядя" (считается, что компилятор не пропустил обращения с неправильным типом)
RTTI (Run-Time Type Inference) - контроль типов в процессе выполнения программы, требуется постоянное ведение "ярлычков" для всех данных, что тратит ресурсы системы. Проще в реализации, чем CTTI, к тому же не создает проблем со сторонними скриптами, из которых может приползти что-то, чего не мог учесть компилятор.


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

Зарегистрирован: Сб июл 26, 2008 06:22
Сообщения: 21
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
mOleg писал(а):
нет, речь шла вот эоб этой книге:


Нет. не читал книгу эту. А какое отношение оно к форту имеет ?

mOleg писал(а):
нет, имелось ввиду, что, например команда + перед выполнением производит контроль типов (то есть можно ли эти числа складывать?) чтобы нельзя было прибавить к, например, указателю на строку число с плавающей точкой.


Именно так. Только типов там всего 4 - целые, вещественные, строки и массивы. К целым относятся и символы. Прибавлять, кстати символы к строкам (то есть целые к строкам) - можно :) Просто к строке добавится один символ - спереди или сзади - зависит от порядка операндов:

'A' "и B" + . ( Создаст строку "A и B" и напечаатет её )
65 "и B" + . ( Создаст строку "A и B" и напечаатет её - аналогично предыдущему)

Указатель = целое. Это просто и удобно.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб июл 26, 2008 22:37 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4920
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 56 раз.
SfS писал(а):
А какое отношение оно к форту имеет ?

прямое: Postscript = Forth + Lisp.

SfS писал(а):
Именно так. Только типов там всего 4 - целые, вещественные, строки и массивы.

понятно, но тогда StrongForth интереснее за счет статической типизации (уж если таковую хочется)
У тебя же подход такой же как в Постскрипте

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


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

Зарегистрирован: Сб июл 26, 2008 06:22
Сообщения: 21
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
Хищник писал(а):
SfS писал(а):
1. Форт-система на "голом" железе. Без всякой ОС как таковой.

С подвариантами:
а) Форт-система на "голом" железе типа PC, ARM и прочего. Требуется эмуляция стековой машины и разработка драйверов.
б) Форт-система на Форт-процессоре.


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


Хищник писал(а):
Линукс и Windows здесь имеют одинаковые права на существование, и опять же интересно как можно сильнее расширить класс программ, которые одинаково пойдут и там, и там.

Де-факто - Виндовс разработан с жёсткой привязкой к одному типу железа. Поэтому пускать Венду на АРМ или на Спарк какомнибудь - занятие хоть и интересное - но практически неразумное. Посему проще всё писать под POSIX, а ежели надо это пускать под виндой - то ставишь cyhwin (эмулаятор вызовов юникса для винды) - и большинство проблем снимаются.


Хищник писал(а):
Для линукса это, в принципе, нормально. И, если угадаю, Форт туда пришел в том числе и для сокращения количества make all при отладке системы? :)


ну я не знаю для чего туда пришёл форт :) Всёж мне кажется - что просто потому что туда давно портировали все языки какие можно.

Лично меня в первую голову интересует aForth на маленькой ОС NEDOPC-ARMOS на кристалле AT91SAM7S256, что имеет 256К ПЗУ и 64К ОЗУ. Под линуксом я сейчас все аппаратно-независимые вещи тестирую. Быстрее. Как отлажу средства отладки - типа слова traceon, traceoff и trace - буду уже на живом чипе всё запускать.

Тут опять же - когда я писал ту самую NEDOPC-ARMOS - то работу с файлами оформил в виде стандартных POSIX-вызовов. Это позволило практиечески один в один переносить код с Линуса на NEDOPC-ARMOS. Это же позволило и aForth там запустить с первого раза.

Так что - СТАНДАРТЫ РУЛЯТ ! :)

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

Интерактивной оболчки пока нет - она без средств отладки бесполезна в общем.


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

Зарегистрирован: Сб июл 26, 2008 06:22
Сообщения: 21
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
mOleg писал(а):
прямое: Postscript = Forth + Lisp.


Обалдеть! А я и не знал! Спасибо - буду знать.

mOleg писал(а):
понятно, но тогда StrongForth интереснее за счет статической типизации (уж если таковую хочется)
У тебя же подход такой же как в Постскрипте


У меня подход - как проще. :) Мегабыстрые слова - можно на си или асме прописать. Не так уж много их и надо.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб июл 26, 2008 23:19 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6327
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
SfS писал(а):
Вариант б) сводится к а) практически всегда, поскольку форт-процессор не означает отсутствие периферии. Обычно проблема то не с процессором, а с переферией (встроенной или наружной - не важно).

Форт-периферия (аппаратные или сильно привязанные к формату Форта EMIT, PIXEL, KEY) очень даже реальна. Запуск аппаратного Форта много проще чем просто "какой-то процессор и Форт-машина на нем". Но это детали, да...
SfS писал(а):
Де-факто - Виндовс разработан с жёсткой привязкой к одному типу железа. Поэтому пускать Венду на АРМ

Win CE вполне работает на ARM, а вот XP, и даже XP Embedded действительно x86-only. Вот взять API от WinCE, получив поддержку всего периферийного зоопарка, файловую систему и мультимедиа - это может быть полезным. Правда, с какой стороны реально подступаться к BSP для таких систем, пока не знаю.

SfS писал(а):
Посему проще всё писать под POSIX, а ежели надо это пускать под виндой - то ставишь cyhwin (эмулаятор вызовов юникса для винды) - и большинство проблем снимаются

Ну тут я полностью поддерживаю, поскольку под cygwin пишу для MicroBlaze :) Причем Линукс в основном именно ради POSIX-интерфейсов, ну и до кучи TCP/IP + FAT32, которые вручную на Форте выписать очень трудоемко, и требует знания именно этих областей, и в меньшей степени языка (любого). Поэтому связка "стандартные решения на стандартной платформе" + "Форт для верхнего прикладного слоя, скриптующего вызовы стандартных вещей" весьма и весьма хороша именно из-за разделения стилей работы. Сначала аккуратно выписываем базовую функциональность, не углубляясь в прикладную задачу, потом начинаем быстренько конфигурировать устройство форт-приложениями, где 99% работы по редактированию текста идет именно с форт-программами, которые запускают готовые системные и библиотечные функции (которые, в свою очередь, работают 99% времени).
SfS писал(а):
Кстати - сейчас моя системка компилируется как библиотека, у которой интерфейс из трёх вызовов: инициализация, исполнения форт-файла и деинициализация. Можно её в качестве библиотеки прикрутить куда угодно.

Интерактивной оболчки пока нет - она без средств отладки бесполезна в общем.

Посмотри msyst.ru\quarkexe.zip :)
Там же msyst.ru/quark.pdf
msyst.ru/proton.zip
Вот как раз тот самый компонентный подход, только для Windows.

Вообще, я эту штуку уже собираюсь портировать под Линукс. Формат взаимодействия до ужаса тривиальный - библиотеке сбрасываются строки форт-текста (dll экспортирует функцию Evaluate(s : lpstr) : errorpos). Собственно, что именно будет там внутри, будет ли типизация, и какая - совершенно неважно. Важно то, что под IDE (которая proton) можно подкладывать разные dll. Интересно было бы подрихтовать наши две системы до их взаимозаменяемости :)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс июл 27, 2008 06:25 
Не в сети

Зарегистрирован: Сб июл 26, 2008 06:22
Сообщения: 21
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
Хищник писал(а):
Форт-периферия (аппаратные или сильно привязанные к формату Форта EMIT, PIXEL, KEY) очень даже реальна. Запуск аппаратного Форта много проще чем просто "какой-то процессор и Форт-машина на нем". Но это детали, да...


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

Хищник писал(а):
Win CE вполне работает на ARM, а вот XP, и даже XP Embedded действительно x86-only. Вот взять API от WinCE, получив поддержку всего периферийного зоопарка, файловую систему и мультимедиа - это может быть полезным. Правда, с какой стороны реально подступаться к BSP для таких систем, пока не знаю.


Вин СЕ отличается от просто Win XP или Win 98 так же как обращение "государь" от "милостивый государь". И в общем случае работоспособность программы сложнее "Hello world", написанной для WinXP и запускаемой под WinCE - скорее исключение, чем правило. Плюс - win ce - мягко говоря, далека от следования POSIX. Ещё недостатки WinCE - денег оно стоит в итоге. Программу, взятую в репозитории линуксовом/фряшном - а где ещё с открытами текстами брать, чтобы кросскомпилировать ? - уже не поставишь. В общем - WinCE для встраиваемых систем - идёт "ф топпку", IMHO.

Хищник писал(а):
Вот как раз тот самый компонентный подход, только для Windows.


Помоему подход к построению форт-системы от ОС не зависит. Более того, могу свою систему под Видовс откомпилировать тем же gcc. У меня там ни одного вызова нет, который Юникс-онли. open() close() malloc() free() - всё и для виндос работает - один в один - насколько я помню.

Хищник писал(а):
Вообще, я эту штуку уже собираюсь портировать под Линукс. Формат взаимодействия до ужаса тривиальный - библиотеке сбрасываются строки форт-текста (dll экспортирует функцию Evaluate(s : lpstr) : errorpos). Собственно, что именно будет там внутри, будет ли типизация, и какая - совершенно неважно. Важно то, что под IDE (которая proton) можно подкладывать разные dll. Интересно было бы подрихтовать наши две системы до их взаимозаменяемости :)


Ну я под виндовс не пишу уже года этак с 2003го (мелкие приблуды не считаются). Так что специфику уж позабыл.
В студенчестве писал "всё и на всём" :) Пробовал, творил, выдумывал :)
А по работе: сначала писал на ассемблере для AVR, потом на С для него же - системы автоматизации техпроцессов. Поскольку фирма была микроскопическая - все работы по разработке устройства выполнялись в общем одним человеком :) От составления принципиалльной схемы и разводки платы - до написания ПО.
Потом - в 2003м - ушёл в другую контору и занялся Линуксом в плотную. Forth для меня сейчас скорее предмет изучения, чем рабочий инструмент - у нас задачи проще решать взяв набор уже написанного ПО под лин, портировать его, дописать свой интерфейс.

Fortом же я занялся именно когда засел за программирование систем-на-кристалле AT91SAM7S256. Хотелось иметь хороший монитор и возможность удалённо менять ПО. Этим сейчас и занимаюсь. Да и интересно стало.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс июл 27, 2008 10:12 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6327
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
SfS писал(а):
По-моему проблема не в том - как занести байт в переферийное устройство, а в том, что данные получаемые/передаваемые от/в переферийного устройство - привязаны к конкретному устройству и жёстких стандартов вообще нет. Поэтому как бы мы не пихали данные в регистр устройства - всё равно придётся писать ДРАЙВЕР, который обслуживает данную конкретную железяку - и никакую более. Ну или класс железяк. Конечно, есть стандартные шины. Но шина - это только формат передачи данных и не более. Сами данные - опять же определяются разработчиком конкретной железки и ни кем более. От уровня прослойки - железо-программа, то есть от уровня драйверов - никуда не уйти. Хоть как извернись. Вопрос только в том - вкомпилировать эти драйвера в форт-систему, в ОС или подгружать их в виде модулей.

Для этого существует концепция layered драйверов. POSIX - как раз один из вариантов верхнего уровня (уровень адаптации к ОС). Как минимум делается "обвязка" с заменой "вывода в порт 123" на "вывод в BASE_ADDRESS_OF_DEVICE". Весы в этом случае качаются между слишком навороченными форматами, претендующими на абсолютную универсальность (в результате чего драйвера становятся чрезмерно сложными, и какому-нибудь UART-у приходится рассказывать, что он не накопитель, не поддерживает DMA, имеет 0 байт в дополнительной служебной области, не поддерживает через-пень-колодные-отложенные-вызовы-инициализатора-энумерации-периферийных-субсистем и прочую подобную ерунду), и чрезмерно простыми обвязками, которые по сути умеют только пересылать данные, но не реализуют протоколы обмена. Один из вариантов для Форта - векторизованные слова для обмена с периферией, реализующие только базовую функциональность (или наоборот, по умолчанию работающие со стандартным системным драйвером - навороченным и медленным). По мере появления необходимости векторы переключаются на слова, определенные разработчиком.
SfS писал(а):
Вин СЕ отличается от просто Win XP или Win 98 так же как обращение "государь" от "милостивый государь". И в общем случае работоспособность программы сложнее "Hello world", написанной для WinXP и запускаемой под WinCE - скорее исключение, чем правило. Плюс - win ce - мягко говоря, далека от следования POSIX.

Дело не столько в прямой совместимости, сколько в поддержке современных протоколов, которые очень сложно писать руками. Плюс Microsoft ну никак не захочет отставать от развития рынка, поэтому можно полагать, что при выходе новой железки, пригодной для мобильных устройств, ее поддержка все-таки появится в WinCE. В любом случае, владение и WinCE, и embedded-вариантами Линукса лучше, чем только Линуксом.
SfS писал(а):
Ещё недостатки WinCE - денег оно стоит в итоге.

170 рублей с устройства. Взамен - бренд, и возможность отсыла пользователя к смартфону или КПК, чтобы не приставали с вопросами "почему тут так?". Деньги сегодня не всегда определяющий фактор, баррель-то стоит больше, чем раньше в анекдотах фантазировали. Покупка средств разработки окупается.
SfS писал(а):
Помоему подход к построению форт-системы от ОС не зависит. Более того, могу свою систему под Видовс откомпилировать тем же gcc. У меня там ни одного вызова нет, который Юникс-онли. open() close() malloc() free() - всё и для виндос работает - один в один - насколько я помню.

О чем и речь. Для Форта вполне можно пользоваться протокольным уровнем, написанным на самом Форте, и тогда один и тот же текст будет работать под обоими основными ОС. А до кучи и на embedded-платформе.
SfS писал(а):
все работы по разработке устройства выполнялись в общем одним человеком От составления принципиалльной схемы и разводки платы - до написания ПО.

Полезный на сегодня навык :)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс июл 27, 2008 15:27 
Не в сети

Зарегистрирован: Сб июл 26, 2008 06:22
Сообщения: 21
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
Хищник писал(а):
В любом случае, владение и WinCE, и embedded-вариантами Линукса лучше, чем только Линуксом.


Не спорю. Но в моём конкретном случае - практическое использование винце - не предвидится. А от того, что я немного про неё почитал и скомпилировал пяток разных "хелловорлдов" - толку в освоении мало.

Хищник писал(а):
170 рублей с устройства. Взамен - бренд, и возможность отсыла пользователя к смартфону или КПК, чтобы не приставали с вопросами "почему тут так?". Деньги сегодня не всегда определяющий фактор, баррель-то стоит больше, чем раньше в анекдотах фантазировали. Покупка средств разработки окупается.


У нас другой бренд требуют :) МСВС называется - микрософт отдыхает :)
Я ничего не имею против винце как таковой. Но поскольку в ней нет ничего, чего не было в свободных системах - то смысла в ней особого нет. Да и госзаказчики МСВС предпочитают - ибо сертефицирована на всякие безопасности и прочую фигню. Если появится у меня реальный проект, где винце даст реальный выигрышь во времени разработки или заказчик захочет "бренд от микрософт" - то без фанатизма поставлю и буду вплотную изучать.


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

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


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

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


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

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