Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Ср фев 21, 2018 22:40

...
Google Search
Forth-FAQ Spy Grafic

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




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

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

Обзор темы - о преимуществах и недостатках существующих стандартов
Автор Сообщение
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
Ethereal писал(а):
Ну я же приводил пример когда не возможен. Был найден компромисс частоты оцифровки WAV на самом пределе быстродействия. На каждом обороте цикла было время исполнить лишь часть вот этого кода
?check_buttons IF process_buttons THEN

Я не то чтобы совсем против, но идея с отдельной явно выраженной многозадачностью у меня вызывает сомнения. Это же тоже отъест ресурсы и полагаться на волшебство в виде run_task/stop_task, не написав и продумав это самостоятельно... ну вот в соседнем треде показательный пример, как там человеку натурально впихнули совершенно ненужные ему дорогие программы. Многозадачность, наряду с ФортОС и IDE для Форта - из разряда несбыточных мечт, которые обязательно должны все исправить, вот только...

Пример со звуком скорее тянет на тщательную проработку задачи в машинном коде. По идее, это как раз противоположно тому, чтобы не глядя отдать решение на откуп "бренду".

Ethereal писал(а):
Но если эти процессы писать не на ассемблере, а на Форте, то USER-переменные понадобятся.

Тут надо тщательно обдумать. Мы говорим о многозадачности или многопоточности? И опять же, USER-переменных, или просто локальных переменных потока?
Сообщение Добавлено: Пн янв 15, 2018 01:09
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
Hishnik писал(а):
Опять же, возможен "прямой" код вида
BEGIN
play_wav
?check_buttons IF process_buttons THEN
AGAIN
Ну я же приводил пример когда не возможен. Был найден компромисс частоты оцифровки WAV на самом пределе быстродействия. На каждом обороте цикла было время исполнить лишь часть вот этого кода
?check_buttons IF process_buttons THEN
Hishnik писал(а):
Отдельный подход - interrupt-driven programming. Критичные по времени процессы распределяются по прерываниям
Но если эти процессы писать не на ассемблере, а на Форте, то USER-переменные понадобятся.
Сообщение Добавлено: Пн янв 15, 2018 00:52
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
Ethereal писал(а):
Если одна задача оперативная, а вторая фоновая, разделение задач тоже делается. Пример оперативной задачи - воспроизведение WAV-файла (отсчеты в ЦАП должны засовываться со строгим периодом и по уму, если этот период будет стоять такт в такт), а фоновая - реакция на нажатия кнопок пользователем в непредсказуемые моменты времени, где с реакцией на сотые секунды можно и погодить.

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

BEGIN
play_wav
?check_buttons IF process_buttons THEN
AGAIN

Отдельный подход - interrupt-driven programming. Критичные по времени процессы распределяются по прерываниям, а основной цикл может быть и просто пустым. Однако это сильно зависит от МК.

Ethereal писал(а):
Или к примеру ПО для спутникового приемника - нужно в фоне реагировать на нажатие кнопок на морде приемника и еще на нажатия кнопок на пульте, плюс исполнять оперативную задачу фильтрации потока со спутника и скармливания команд смарт-карте и получения ответов от нее с тайм-аутами, а если шаринг, то надо еще TCP/IP соединение держать и обмениваться по эзернету и еще по COM-порту тоже обмен может быть, если к приемнику подключен донгл. Тут без многозадачности можно сразу вешаться.

TCP/IP действительно кандидат на выделение задачи, но опять же - в зависимости от общей архитектуры системы и программного проекта. Слабые МК банально просядут при попытке выделить им отдельный менеджер задач со своими временными ресурсами. Кроме того, без MMU многозадачность представляет собой нечто зыбкое в плане надежности. А уж если TCP принимает данные, нужные спутнику, то необходимо обеспечить совместный доступ к этим данным из двух задач. И даже с задекларированной многозадачностью (в виде какой-то библиотеки), но без настоящего MMU источник потенциальных проблем все равно остается.

По впечатлению - искусственные навороты не спасают(чудес не бывает и процессор один). Прерывания спасают слабо (процессор все равно один). Вот аппаратное распараллеливание уже очень хорошо и на корню решает проблему (две задачи так две задачи - значит будет два процессорных ядра). Горыныч оказался совсем удобен - там динамическое распределение временных слотов с нулевым штрафом на переход.
Сообщение Добавлено: Пн янв 15, 2018 00:10
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
mOleg писал(а):
ну, не совсем так, опрос датчиков приоритетен, а отрисовка может лагать(запаздывать).

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

Опять же, где именно отрисовка запаздывает? В семисегментном индикаторе? В LCD с SPI? В UART? Большинство устройств отображения не имеет сигналов готовности или же имеют такие режимы, которые без этих сигналов прекрасно обходятся.
Сообщение Добавлено: Вс янв 14, 2018 23:38
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
Hishnik писал(а):
Разделение задач как раз и делается для того, чтобы проблемы в работе одной задачи не влияли на другие.
Если одна задача оперативная, а вторая фоновая, разделение задач тоже делается. Пример оперативной задачи - воспроизведение WAV-файла (отсчеты в ЦАП должны засовываться со строгим периодом и по уму, если этот период будет стоять такт в такт), а фоновая - реакция на нажатия кнопок пользователем в непредсказуемые моменты времени, где с реакцией на сотые секунды можно и погодить.
Hishnik писал(а):
Многозадачность тут сильно смахивает на "магию бренда"
Решал я задачу воспроизведения WAV-файла с SD-флешки на 20-мегагерцовом PIC18. Так вот со стандартными WAV-файлами с частотой оцифровки 44100 Гц вообще быстродействия не зватило никак. Но поскольку в WAV-ах была не музыка, а вибрации сложной формы, то вопрос решился допустимым занижением частоты оцифровки. Но все равно при вопроизведении оперативная задача жрала львиную долю процессорного времени, а фоновая продвигалась короткими рывками в промежутках. Во время очередного рывка исполнялся лишь небольшой кусочек главного цикла фоновой задачи. Вот пример программы, которую без двузадачности было не написать никак. Такие задачи бывают.
Или к примеру ПО для спутникового приемника - нужно в фоне реагировать на нажатие кнопок на морде приемника и еще на нажатия кнопок на пульте, плюс исполнять оперативную задачу фильтрации потока со спутника и скармливания команд смарт-карте и получения ответов от нее с тайм-аутами, а если шаринг, то надо еще TCP/IP соединение держать и обмениваться по эзернету и еще по COM-порту тоже обмен может быть, если к приемнику подключен донгл. Тут без многозадачности можно сразу вешаться.
Сообщение Добавлено: Вс янв 14, 2018 22:10
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
Hishnik писал(а):
Прочитать датчики и выполнить действия - это по сути одна задача,

ну, не совсем так, опрос датчиков приоритетен, а отрисовка может лагать(запаздывать).
Но, конечно, это не означает, что нельзя использовать другое решение. Вопрос лишь в том как проще добиться необходимого результата. Я не вижу проблемы с пользовательскими переменными. Они, как и многозадачность, прекрасно уходят в библиотеку, и подключаются при необходимости.
Сообщение Добавлено: Вс янв 14, 2018 21:39
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
Если число задач известно заранее, то где же здесь "много-"? Прочитать датчики и выполнить действия - это по сути одна задача, хотя бы потому что данные как раз общие, а не раздельные, как при многозадачной работе. Разделение задач как раз и делается для того, чтобы проблемы в работе одной задачи не влияли на другие. А если в программе на МК отвалится датчик, то остальные компоненты программы станут бесполезны. USER-переменные в данном случае успешно заменяются на обычные локальные переменные процедур. Многозадачность тут сильно смахивает на "магию бренда", когда в проект необоснованно добавляются какие-то подходы, которые у всех на слуху, но в конкретном проекте ну совершенно ни к чему.
Сообщение Добавлено: Вс янв 14, 2018 17:13
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
Простейшая МК-система с семисегментным индикатором и кнопками уже требует двузадачности. Обычно я делаю динамическую индикацию в обработчике прерывания по таймеру и опрос кнопок и реакцию на их нажатия главным циклом. Но это на ассемблере. И вообще МК-задача типично разбивается на две - делать то, что должен делать фоновой задачей и реагировать на действия пользователя оперативно. На форте сделал бы корпоративную двузадачность. Плата за наличие такой возможности ведь минимальна - ну слова STATE BASE и еще несколько штук должны быть не value, а именно переменными плюс наличие слово USER опционально. На мой взгляд вообще не плата, ибо само наличие VALUE тоже должно быть опционально. Ну лишняя это сущность в минимальном ядре.
Сообщение Добавлено: Вс янв 14, 2018 04:33
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
один поток снимает показания с датчика (по одному потоку на датчик)
в другом крутится оболочка, занимающаяся отрисовкой и сохранением данных.
Сообщение Добавлено: Ср янв 10, 2018 15:47
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
Цитата:
У Баранова же описано. Можно было еще в ДОС запускать несколько потоков исполнения форт-команд с помощью адресного интерпретатора. Обычно, когда речь заходит о многопоточности в Форте, имеется в виду именно это. Оттуда и USER-переменные.


Так и знал, что мы говорим о разном немножко.
Однако ж USER-переменные актуальны. В винде по крайне мере.

Цитата:
А если через вызовы ОС, то это не очень интересно, это надо не Форт изучать, а соответствующие инструменты ОС. От Форта остается только обертка.


Не знаю как раньше, но сейчас на форте иногда балуются с корпоративной многозаачностью. Вроде бы интересно, но где применяется никто не видел. В СПФ-е либа есть где-то.
Лучше уж писать "тупые" либы по работе с сетью, файлами, поиск, разбор.
Больше шансов, что пригодится.
Сообщение Добавлено: Ср янв 10, 2018 00:43
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
Victor__v писал(а):
Не, ну это как?
я лично не знаю способа запустить потоки без средств ОС.
Если Вам известен способ запустить поток минуя ОС, то я весь во внимании.

У Баранова же описано. Можно было еще в ДОС запускать несколько потоков исполнения форт-команд с помощью адресного интерпретатора. Обычно, когда речь заходит о многопоточности в Форте, имеется в виду именно это. Оттуда и USER-переменные. А если через вызовы ОС, то это не очень интересно, это надо не Форт изучать, а соответствующие инструменты ОС. От Форта остается только обертка.
Сообщение Добавлено: Ср янв 10, 2018 00:14
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
Цитата:
Вариант: запуск потоков средствами ОС. Или задач. Переизобретать управление задачами/потоками более не требуется

Не, ну это как?
я лично не знаю способа запустить потоки без средств ОС.
Если Вам известен способ запустить поток минуя ОС, то я весь во внимании.
И кто переизобретает управление потоками? Кто этот негодяй?
На современных операционках это дело лишние.

Да и форте потоки запускаются средствами ОС.
Сообщение Добавлено: Вт янв 09, 2018 20:39
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
Victor__v писал(а):
Однопоточные серверные приложения

Однопоточный Форт <> однопоточное серверное приложения. Серверные приложения ведь как-то существуют в многопоточных вариантах и без Форта.
Victor__v писал(а):
Быть сервером. Тут многопоточность по-любому.

Нет, это слишком общее. Есть понятие "сценарии применения". Что конкретно надо будет написать на таком Форте? Если просто be_server, то это опять же не вариант. Это можно вызвать просто другое серверное приложение через ShellExecute - вон как Шабронов нас тут всех "просветил". С очень большой вероятностью может оказаться, что переключение форт-потоков никакой особой проблемы и не решает.
Victor__v писал(а):
В чём тут форт имеет приемущество?
Компиляция во время выполнения.
Возможность на ходу поправить скритпы-исходники и сбросить и перезапиустить приложение.
Короче, сочетание двух ипостасей форт-системы.

Вариант: запуск потоков средствами ОС. Или задач. Переизобретать управление задачами/потоками более не требуется. Сервер устойчив к множественным запросам, точно так же, как и другие серверные приложения, использующие эти механизмы ОС.
Сообщение Добавлено: Вт янв 09, 2018 20:06
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
Victor__v писал(а):
Ежели сервер однопоточный то и DDOS не нужен :)
Ой, точно)
Сообщение Добавлено: Вт янв 09, 2018 19:19
  Заголовок сообщения:  Re: о преимуществах и недостатках существующих стандартов  Ответить с цитатой
_KROL писал(а):
Hishnik писал(а):
...
В действительности, как можно использовать однопоточность в всемирной паутине? Это может и выгодно для некоторых серверов, которые мало общаются с каждым клиентом, но как тогда защитится от DDOS атак?
Victor__v писал(а):
...
Редко встречается в нашем мире и однозадачность :D Например в Обероне, который тоже можно использовать как сервер. Но такой подход, как я понял, неплох для небольшой локальной сети, а не WWW.


Ежели сервер однопоточный то и DDOS не нужен :)
Сообщение Добавлено: Вт янв 09, 2018 19:17

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


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