Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Вт мар 19, 2024 13:24

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 113 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8  След.

Куда цеплять "драйвера"?
Создавать лексиконы наподобие Си-библиотек 44%  44%  [ 4 ]
Прятать внутрь интерпретатора 0%  0%  [ 0 ]
Усложнять интерпретатор 0%  0%  [ 0 ]
Использовать более одного интерпретатора 22%  22%  [ 2 ]
FORTH устроен совсем не так 33%  33%  [ 3 ]
Всего голосов : 9
Автор Сообщение
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 10:49 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Вот тут уже ошибка. В сложной программе заведомо будут ОБА варианта! И еще пара-другая, среди которых, опять заведомо, будут совершенно одинаковые, только с разными именами.

Раз я привел гипотетический пример, то в рамках этого примера я и рассматриваю множество вариантов. В данном случае есть 4 варианта:
1. Реализована первая нотация, и нужна первая - все ок.
2. Реализована вторая нотация, и нужна вторая - все ок.
3. Реализована первая нотация, а нужна вторая - придется переписывать не только само слово, но и изменять программу. Или добавлять новые версии слов, чтобы в одном месте пользоваться простым вариантом, а в другом - сложным.
4. Реализована вторая нотация, а нужна первая. Первую из второй сделать проще, однако время-то на ненужную работу потрачено.

Что касается "заведомо будут", то смотрим, например, старые вызовы BIOS. В части графики были реализованы только наиболее универсальные вызовы - например, очень медленная функция вывода пиксела, работающая в люблм видеорежиме. Разумеется, в программах тут же появлялись быстрые специализированные версии, рассчитанные на конкретный видеорежим. Если брать что-то более современное, можно сравнить DirectDraw и OpenGL. Первая имеет функции с массой параметров, часто не вполне очевидных. Вторая реализует машину состояний - например, можно определить цвет, который будет автоматически применяться ко всем объектам, рисуемым впоследствии (и в вызовах этих функций цвет уже не указывается). Отсюда и возвращаемся к вопросу планирования - а как заранее узнать, какие форматы вызовов потребуются? Как не сделать двойной-тройной объем работы, реализуя разнообразные форматы, которые на деле не потребуются? В данном случае именно планирование в большом проекте позволит избавиться от кодирования в лоскутном стиле.

gudleifr писал(а):
Как бы, все специфические/рекомендуемые тесты (типа перечисленных Вами ниже) при таких размерах уже не работают. Просто невозможно обособить тот блок, для которого они будут "граничными" или "выроджденными".

Для блоков выполняется юнит-тестирование. Для всего проекта - интеграционное. Работающие по отдельности модули еще не означают, что при объединении они тоже заработают - например, последующему нужно еще что-то. Первый-то отработал нормально, а второй ругается. Потому что между ними забыли вызвать "полуторный". Разумеется, юнит-тестирование стоит ограничивать кусками такого размера, чтобы еще можно было что-то диагностировать.

gudleifr писал(а):
Как бы Мур и жалуется на это самое "преобладание".

Мне как-то кажется, что он совершенно зря жалуется. Уровень решаемых задач постоянно повышается. Возрастание сложности тоже объективный процесс. Простые решения? Ну пожалуйста - выходим в интернет с помощью модема на 33600. А WiFi - это устройство совершенно другого уровня.

gudleifr писал(а):
Индустрия? Подарил тут маме очередную читалку. И заодно посмотрел на нее со стороны. Почему она так тормозит? Откуда эти ложные срабатывания? Почему нет синхронизации нажатия на кнопку с фактом существования этой самой кнопки? Куда девается заряд батарейки? Нет, это не "индустрия" научилась создавать сложные программы, это просто мы привыкли к тому, что она этого не умеет...

А сколько оно стоит? Если такая читалка разрабатывалась исходя из основного пункта "у производителя появилась возможность купить дешевые дисплеи E-ink в больших количествах", то понятно, что остальные технические решения будут приняты по принципу "чтобы заработало". У всех ARM - ну и у нас ARM. Сборку линукса сейчас скачаем, логотип поменяем на свой. Pocket Book не тормозит, работает больше месяца, корректно отображает множество форматов. Дело не в индустрии как таковой, а в снижении порога вхождения в технологию, что позволяет добиваться работоспособности от устройств, выполненных неоптимально.
gudleifr писал(а):
P.S. Опять мы с чисто технического вопроса перешли на чисто философскую тему...

Что правильно, поскольку прежде чем искать ответ на вопрос, надо уточнить формулировку вопроса. Сколько интерпретаторов нужно для драйверов ОС - это не окончательная формулировка.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 11:24 
Хищник писал(а):
В данном случае именно планирование в большом проекте позволит избавиться от кодирования в лоскутном стиле.
Т.е. слово "архитектура" заменили на "планирование"? И не возразишь... Капитан Очевидность, однако. А если теперь спросить: что есть планирование в FORTH? И каким оно должно быть? И не стоит ли планировать не только FORTH-программу, но и саму FORTH-систему?
Хищник писал(а):
Для блоков выполняется юнит-тестирование. Для всего проекта - интеграционное.
Еще один Капитан Очевидность. А я что говорил? Для простых программ - тестов дофига (хотя это ни от чего не спасает), а для сложных - тесты, это чисто "наработка на отказ".
Хищник писал(а):
Уровень решаемых задач постоянно повышается.
Наоборот, имеем чисто экстенсивное развитие. Более умное железо позволяет писать более глупые программы.
Хищник писал(а):
Pocket Book... добиваться работоспособности от устройств, выполненных неоптимально.
Я же говорю, привыкшему к глюкам компьютерщику это кажется нормальным. Ну, подумаешь, запомнить в какой момент жать... А для нормального человека - дикость. (Я тоже покупаю своим родственникам PocketBook-и).
Хищник писал(а):
надо уточнить формулировку вопроса. Сколько интерпретаторов нужно для драйверов ОС - это не окончательная формулировка.
Попробуйте сформулировать свое непонимание яснее. Что толку от констатации того, что я не спрашивал про "сколько интерпретаторов...?".
Вспомните какой-нибудь свой сложный программный продукт. Где-то в середине наступает момент[ы], когда надо выбрасывать прототипы. И вот тут возникает вопрос: выбрасывать только лексиконы, или заодно и сам FORTH.
Например, когда я начал писать Win-FOBOS, я взял Win32Forth и начал честно на нем экспериментировать с WIN-API. Когда понял идею, выкинул все написанное и написал g2.asm, в который вошло только то, что было нужно для работы (например, там были слова для вызова WIN-API и реализации конечных автоматов, но не было слова для умножения). Дописав почти до конца, понял, что можно сделать лучше. Переделал лексиконы - g8.txt. К этому времени созрела идея вторичной машины и собираюсь опять переделать g8.asm... Конечно, мой проект очень прост, но по количеству мусора, ушедшему из лексиконов первой версии просто в силу "оптимизации ядра", я оцениваю уровень сложности, которого смогу достичь в итоге, достаточно оптимистически...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 12:03 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Т.е. слово "архитектура" заменили на "планирование"? И не возразишь... Капитан Очевидность, однако. А если теперь спросить: что есть планирование в FORTH? И каким оно должно быть? И не стоит ли планировать не только FORTH-программу, но и саму FORTH-систему?

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

gudleifr писал(а):
Еще один Капитан Очевидность. А я что говорил? Для простых программ - тестов дофига (хотя это ни от чего не спасает), а для сложных - тесты, это чисто "наработка на отказ".

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

gudleifr писал(а):
Наоборот, имеем чисто экстенсивное развитие. Более умное железо позволяет писать более глупые программы.

Вобщем-то WiFi от модема отличается настолько сильно, что говорить о следовании требованиям программистов там просто нереально. Модем не масштабируется на скорости, которые достигаются в WiFi - медный телефонный провод не обеспечит десятки мегабит в секунду. Виды модуляции, frequency hopping, управление пакетами - все это в современных коммуникационных протоколах отнюдь не представляет собой экстенсивное развитие модема. Во многих технологиях ситуация обстоит точно так же, просто для того, чтобы удержать уровень сложности для разработчиков, образуется новая прослойка. Не так уж случайна высокая популярность преобразователей USB-serial. Да, там скорость ограничена 962 кбит/с, хотя USB как интерфейс может обеспечить и больше. Вот только сложность полнофункционального драйвера USB, который работает с этими пакетами, а не с сервисом, предоставляемым готовым драйвером USB-UART, существенно выше. Точно так же, если влезть с программой глубоко внутрь современной читалки, там "внезапно" обнаружится масса устройств, которые постоянно чего-то требуют :) У контроллера USB нет регистра, из которого можно вот просто так прочитать содержимое файла на внешней флешке. Зато у этого контроллера по стандарту есть действия типа "послать сигнал awake, потому что внешнее устройство проявило активность". Поэтому при попытке заняться низкоуровневой программной поддержкой современного железа очень быстро вспомнится поговорка "не до жиру, быть бы живу".
gudleifr писал(а):
Я же говорю, привыкшему к глюкам компьютерщику это кажется нормальным. Ну, подумаешь, запомнить в какой момент жать... А для нормального человека - дикость. (Я тоже покупаю своим родственникам PocketBook-и).

Я понимаю причины, по которым появляется такая продукция, но это не означает, что я согласен с тем, что так и надо продолжать.
gudleifr писал(а):
Вспомните какой-нибудь свой сложный программный продукт. Где-то в середине наступает момент[ы], когда надо выбрасывать прототипы. И вот тут возникает вопрос: выбрасывать только лексиконы, или заодно и сам FORTH.

Это естественный процесс. Существует "жизненный цикл быстрого прототипирования", существует итеративный подход. Первая версия в рамках этих подходов специально и создается для выяснения наиболее принципиальных моментов, с пониманием того, что потом ее надо выбрасывать. Вот и надо заранее определить, выбрасывать ли и Форт тоже. Если задачей является пересмотр Форта, то он сам по себе продукт, подлежащий разработке. В рамках данного подхода его надо выбросить и переписать заново с учетом выявленных проблем. Но совершенно не стоит бросать все в одну кучу. В Форте ли проблема? Можно отложить ее решение, пойдя на "штрафной круг" переписывания инструментария... и надеясь, что проблема сама как-то рассосется, или же новая версия решит ее волшебным способом.
gudleifr писал(а):
Например, когда я начал писать Win-FOBOS, я взял Win32Forth и начал честно на нем экспериментировать с WIN-API. Когда понял идею, выкинул все написанное и написал g2.asm, в который вошло только то, что было нужно для работы (например, там были слова для вызова WIN-API и реализации конечных автоматов, но не было слова для умножения). Дописав почти до конца, понял, что можно сделать лучше. Переделал лексиконы - g8.txt. К этому времени созрела идея вторичной машины и собираюсь опять переделать g8.asm... Конечно, мой проект очень прост, но по количеству мусора, ушедшему из лексиконов первой версии просто в силу "оптимизации ядра", я оцениваю уровень сложности, которого смогу достичь в итоге, достаточно оптимистически...

В таких случаях удобно писать сценарии использования (включая фрагменты программ, которые желательно потом запускать), по сценариям выписать спецификацию. Там уже и решить, нужно ли обязательно делать умножение и все прочее (а то потом от сложных вещей захочется отказаться с формулировкой "да ну, и так сойдет", а через пару месяцев выяснится, что пользоваться полученной программой и незачем). К спецификации, опять же, тесты. По всему проекту контрольные точки ("надо добиться того, чтобы Форт умел выводить на экран числа от 0 до 10 в цикле"). Метрические характеристики (графика со скоростью 0,1 FPS - полный провал, продолжать бессмысленно).


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 13:27 
Хищник писал(а):
gudleifr писал(а):
И не стоит ли планировать не только FORTH-программу, но и саму FORTH-систему?

Характеристики форт-системы должны отвечать требованиям тех программ, которые потом на ней будут писаться.
Тут случилось непонимание. Я имел в виду "подгонку FORTH" под единственную программу, а не планирование FORTH-системы для целого класса программ.
Хищник писал(а):
уже окончательно устоялось понятие Quality Assurance
К сожалению, это не решает проблем программиста. Самая большая польза от тестов - программирование настолько запутанных алгоритмов, что кодер может понять, что эта штука работает только, когда прошел (прописанный в ГОСТ) тест. Хотя я встречал "программистов", писавших программы так, что тесты проходили, а программа не работала...
"Quality Assurance" - это от безысходности.
Хищник писал(а):
Поэтому при попытке заняться низкоуровневой программной поддержкой современного железа очень быстро вспомнится поговорка "не до жиру, быть бы живу".
Это частое заблуждение: "сложная программа, это программа, состоящая из сложных операций". Наоборот. Сложные фрагменты (да и сложные они очень часто только потому, что нет нужной документации) - это естественные вехи в сложной программе, облегчающие навигацию в ней (т.е. делающие ее проще). Особенно хорошо это заметно при хакинге чужого хода.
Хищник писал(а):
Я понимаю причины, по которым появляется такая продукция, но это не означает, что я согласен с тем, что так и надо продолжать.
Если Вы понимаете причины, то должны согласится, что так и будет продолжаться.
Хищник писал(а):
Вот и надо заранее определить, выбрасывать ли и Форт тоже.
Именно об этом и шла речь изначально. Заранее определить наиболее симпатичные программистам способы выбрасывания.
Хищник писал(а):
В таких случаях удобно писать сценарии использования (включая фрагменты программ, которые желательно потом запускать), по сценариям выписать спецификацию.
FORTH - сам себе сценарий/спецификация.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 16:14 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Тут случилось непонимание. Я имел в виду "подгонку FORTH" под единственную программу, а не планирование FORTH-системы для целого класса программ.

А, вот как. Хорошо, принято.

gudleifr писал(а):
К сожалению, это не решает проблем программиста. Самая большая польза от тестов - программирование настолько запутанных алгоритмов, что кодер может понять, что эта штука работает только, когда прошел (прописанный в ГОСТ) тест. Хотя я встречал "программистов", писавших программы так, что тесты проходили, а программа не работала...
"Quality Assurance" - это от безысходности.

Ну, если разобраться, это само по себе отдельное направление. Тестирование сильнее проявлено в цифровом дизайне, хотя бы потому. что итерация трассировки кристалла существенно дольше, чем компиляция программы, и между итерациями хорошо бы не просто делать правки наобум, а пытаться выявить как можно больше проблем в процессе моделирования (которое работает существенно быстрее). Не всегда достижимый идеал - т.н. self-checking testbench. Например, тест 2 + 2 = 4 самотестирующимся не является, потому что 2 * 2 тоже равно 4. А вот если результат моделирования однозначно указывает на неправильно работающий блок, такой тест очень ценен. Из RTL-дизайна вообще можно взять много ценного - например, активнее проверяется покрытие тестами (code coverage) - это к вопросу о формальном прохождении тестов неработоспособной программой. Кроме "статического" тестирования сушествуют тестовые группы и последовательности, собирается статистика по "попаданиям" в отдельные комбинации тестовых условий и т.п. Я не выступаю за тотальный test-driven design, популярный в экстремальном программировании, однако раз уж приходится как-то решать проблемы, почему бы не порешать их способами, которые дают хотя бы шанс на успех.

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

А о сложных операциях речь и не шла. Напротив, базовые операции в USB или Ethernet как раз довольно-таки просты. Однако количество и взаимосвязи образуют приличный клубок проблем. Первое же, с чем сталкиваются при разработке - устройство просто выкидывается компьютером, с которым проверяется его работа. Чтобы добиться хотя бы наличия устройства с Ethernet в сети, надо как минимум обеспечить работу по протоколу ARP, а это дело отнюдь не статической отладки. Нет ответа на несколько ARP-запросов со стороны PC - все, "нет связи". Поэтому подобные вещи необходимо запускать и отлаживать "одним большим прыжком". В Форте также есть подобные места - например, поиск в словаре, интерпретация и компиляция выполняются монолитно, поскольку их простые части плотно притерты друг к другу. Как идти по словарю, зависит от того, в каком формате скомпилированы словарные статьи.
gudleifr писал(а):
FORTH - сам себе сценарий/спецификация.

Ну, не соглашусь. Мантра "у нас ANS-совместимый Форт" на практике не приводит к появлению продуктов на нем. А вот имея возможность решения каких-то практических задач, программист согласится потерпеть некоторые неудобства с синтаксисом. Вон gforth удачно мимикрирует под "стандартный Форт для Линукс" путем приписывания буквы g, но это как-то не способствует его лавинообразному распространению.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 16:36 
Не в сети

Зарегистрирован: Ср фев 17, 2010 18:10
Сообщения: 323
Откуда: Тверь
Благодарил (а): 13 раз.
Поблагодарили: 11 раз.
Кстати, вопрос. А на каком Форт предполагалось писать ОС?

На Форт-Fobos?
На SPF?
На абстрактном ANSI Форте?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 16:47 
Хищник писал(а):
Я не выступаю за тотальный test-driven design, популярный в экстремальном программировании, однако раз уж приходится как-то решать проблемы, почему бы не порешать их способами, которые дают хотя бы шанс на успех.
Об том и speech... Шанс... Шанс требуется оценить... Оценка шанса приводит к выработке некоего аппарата... Аппарат можно применить при проектировании... и т.д. В итоге имеем: т.к. тесты надо рассчитывать, то почему не рассчитать контрольные точки, пред- и пост-предикаты и саму требуемую структуру программы?
Хищник писал(а):
А о сложных операциях речь и не шла. Напротив, базовые операции в USB или Ethernet как раз довольно-таки просты.
Дык, и кодов операции процессоров, которые все выражается не так много... Понятно речь идет не о "словах", а о "предложениях" и "абзацах"...
А "связи"? Ни одно из встреченных мною устройств\алгоритмов не обладало столь сложными связями, сколько их напихает средний программист в процессе "структурного программирования", а, затем, "доводки программы".
Хищник писал(а):
Ну, не соглашусь.
А почему? Как средство конструирования языков, FORTH не имеет никаких ограничений (окромя Тьюринговских). Нам нужен язык спецификаций... Следовательно...
Хищник писал(а):
"стандартный Форт для Линукс" путем приписывания буквы g, но это как-то не способствует его лавинообразному распространению.
Я уже неоднократно писал: под Linux FORTH нафиг не нужен, там нет проблем с подобными инструментами. Годовых проблемно-ориентированных языков - дофига, средств написания таких языков - дофига, среда общения для таких языков - богатейшая, средств самодокументирования - дофига... FORTH там - бедный родственник.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 16:48 
mgw писал(а):
Кстати, вопрос. А на каком Форт предполагалось писать...
Предполагается писать не "на FORTH", а "самого FORTH" или, даже "не совсем FORTH".


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 16:56 
Не в сети

Зарегистрирован: Ср фев 17, 2010 18:10
Сообщения: 323
Откуда: Тверь
Благодарил (а): 13 раз.
Поблагодарили: 11 раз.
gudleifr писал(а):
Итак, на входе - обычный FORTH, не имеющий на борту ничего, чего бы не было необходимым для его работы (саморазвития). Нам надо расширить его некоторыми свойствами операционной системы - взаимодействием с некими устройствами, многозадачностью и прочим...

gudleifr писал(а):
Предполагается писать не "на FORTH", а "самого FORTH" или, даже "не совсем FORTH".


Так Форт есть или его нет? Тут надо определится.

Если пишем ОС, то и получится ОС. Если пишем "самого FORTH" или, даже "не совсем FORTH", то ОС не получится.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 17:06 
mgw писал(а):
Так Форт есть или его нет? Тут надо определится.
В смысле? В топикстарте ясно же сказано: берем любой FORTH и дорабатываем напильником. Использование какого-либо "стандартного FORTH" имеет отношение только к вариантам ответа (1) и (5).

"Операционные системы" в этой теме выступают только в роли "например, Слоненка". Как возможная сфера применения "сложного FORTH".

P.S. А почему "ОС не получится"? Unix же из "самого C" получился же...


Последний раз редактировалось gudleifr Ср апр 30, 2014 17:12, всего редактировалось 1 раз.

Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 17:12 
Не в сети

Зарегистрирован: Ср фев 17, 2010 18:10
Сообщения: 323
Откуда: Тверь
Благодарил (а): 13 раз.
Поблагодарили: 11 раз.
Хорошо. Тогда вопрос, в этом типовом Форте есть ли библиотеки:
1 - работа со строками
2 - работа с памятью
3 - работа с файлами
4 - работа с модулями
5 - работа с ООП

или предполагается, что как такового набора готовых библиотек нету и будем по ходу работы добавлять новые функции (слова) ?

По мне так вообще нет разницы между Фортом и С, с точки зрения построения ОС. Разница в библиотеках. Например драйвер TTY в Linux реализован на С, но вся его работа - это кольцевая очередь, с одного конца наполняет клавиатура с другого конца забирает READ. Так на Форте будем реализовывать библиотеку поддержки кольцевого буфера, или нет?


Последний раз редактировалось mgw Ср апр 30, 2014 17:16, всего редактировалось 1 раз.

Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 17:14 
mgw писал(а):
Хорошо. Тогда вопрос, в этом типовом Форте есть ли библиотеки...

gudleifr писал(а):
Итак, на входе - обычный FORTH, не имеющий на борту ничего, чего бы не было необходимым для его работы (саморазвития).
Вы можете сделать библиотеки органичной частью FORTH в этом смысле?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 17:18 
Не в сети

Зарегистрирован: Ср фев 17, 2010 18:10
Сообщения: 323
Откуда: Тверь
Благодарил (а): 13 раз.
Поблагодарили: 11 раз.
По мне так вообще нет разницы между Фортом и С, с точки зрения построения ОС. Разница в библиотеках. Например драйвер TTY в Linux реализован на С, но вся его работа - это кольцевая очередь, с одного конца наполняет клавиатура с другого конца забирает READ. Так на Форте будем реализовывать библиотеку поддержки кольцевого буфера, или нет?

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 17:36 
mgw писал(а):
По мне так вообще нет разницы между Фортом и С, с точки зрения построения ОС.
Разница проста: авторы Unix написали язык C под себя, для удобной реализации на нем Unix... А фортеры как только начинают писать ОС, убеждаются, что игра не стоит свеч, т.к. все и так прекрасно работает...
mgw писал(а):
Так на Форте будем реализовывать библиотеку поддержки кольцевого буфера, или нет?
Это в тему. Внутри вашего FORTH есть процедура (условно EXPECT), которая получает символы. Она реализована через кольцевой буфер? Допустим, нет. Что проще, ограничиться при написании нашей "ОС-подобной" программы уже готовым EXPECT, сделать второй ввод при помощи библиотеки/лексикона "кольцевого" EXPECT-2, или переписать свой EXPECT (и, соответственно свой FORTH) под кольцевой буфер?
mgw писал(а):
где заканчивается обычный Форт и начинается другой слой, слой проблемноориентированных интерфейсов
Во всех вариантах ответа (1-5) - по-разному.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Ср апр 30, 2014 17:50 
Не в сети

Зарегистрирован: Ср фев 17, 2010 18:10
Сообщения: 323
Откуда: Тверь
Благодарил (а): 13 раз.
Поблагодарили: 11 раз.
gudleifr писал(а):
Это в тему. Внутри вашего FORTH есть процедура (условно EXPECT), которая получает символы. Она реализована через кольцевой буфер? Допустим, нет. Что проще, ограничиться при написании нашей "ОС-подобной" программы уже готовым EXPECT, сделать второй ввод при помощи библиотеки/лексикона "кольцевого" EXPECT-2, или переписать свой EXPECT (и, соответственно свой FORTH) под кольцевой буфер?

Это место не понятно. Что значит, что проще? EXPECT уже есть? Он отвечает понятию ОС? Он работает по прерываниям, он может буферизировать поток и т.д. Тогда используем его. Если он этого не умеет, то пишем "правильный" ОСный. Выбора то нету. Но я всё о том же, где переход на другой уровень абстракции?

Пример: Окна новое Окно№1 Окно№1.Покажи 200 300 Окно№1.Размеры


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

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


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

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


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

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