OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Суббота, 18 Ноябрь, 2017 07:14

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 233 ]  На страницу Пред.  1, 2, 3, 4, 5 ... 12  След.
Автор Сообщение
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Вторник, 21 Август, 2007 23:08 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8861
Откуда: Россия, Орёл
По поводу КП - кое-какие средства введены, действительно, чтобы "заткнуть дыры" Оберона-2.
Кое-какие - очень удобны для задач высокого уровня (динамические многомерные массивы и т.п.).
Кое-какие полезны и для системного программирования в стиле первого Оберона (например, возможность объявления указательных и процедурных типов "по месту", прямо в списке параметров процедуры-"инсталлятора" методов, например).
Очень кстати импорт полей только на чтение - мы можем при необходимости гарантировать, что никто кроме фабричного модуля не переинсталлирует процедурные поля. LIMITED - к примеру, с его помощью можно гарантировать, что сообщение некоторого типа может послать только конкретный модуль, и никто не может под него "подделаться".
(в ОС это особенно актуально, если думать о защите и безопасности в многопользовательской и сетевой среде, отчего избавлены все существующие сейчас Оберон-оси).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Среда, 22 Август, 2007 11:09 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Владимир Лось писал(а):
Сергей Прохоренко писал(а):
Под "вызовами" я имел в виду параллельные вычисления - это не относится к микроконтроллерам.

КТО ЭТО ВАМ СКАЗАЛ???!!!
Вот сейчас, в простом проекте мне нужно сугубо параллельно работать и с отображением алфавитно-цифровой информации на индикаторах, и от клавиатуры нажатия ловить (причём, без прерываний, а только методом динамического-опроса-сканирования матрицы контактов), и с флэшкой работать (эмулируя и поддерживая фат16), и лить информацию по параллельному каналу, и ещё следить за кучей параметров (от отслеживания напряжения на акк.батарее и до температуры в корпусе) и большинство из них, так же, вынужденно опрашивается а не по прерываниям...
И мне бы очень пригодился формализм описания всего этого хозяйства, как взаимодействующих и выполняющихся параллельно сущностей!


:? Может, я неточно сформулировал. Я имел в виду не многозадачный режим (много разных задач одновременно выполняются на одном компьютере), давно и более или менее успешно реализованный, а распараллеливание вычислений. См. в Википедии: http://ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%BB%D0%BB%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F

Распараллеливание вычислений совершенно не характерно для микроконтроллеров. Им не приходится решать такие задачи (обработка потокового видео, моделирование метеорологических процессов, моделирование сложных химических соединений, моделирование "виртуальной реальности" и т.п.). То есть, распараллеливаться должна очень объемная задача, которая может быть разбита на множество мелких однородных и относительно независимых подзадач. Язык программирования, на котором описываются распараллеливаемые (чуть язык не сломал!) вычисления, должен иметь конструкции для описания разбиения задач на параллельные подзадачи, где это невозможно сделать автоматически. Компилятор должен обладать средствами автоматического разбиения задач на параллельные подзадачи, где это возможно. Среда исполнения должна рационально нагружать ядра процессора или процессоры многопроцессорной системы.

До недавнего времени распараллеливание вычислений было головной болью специалистов в узких областях, но сейчас происходит вытеснение одноядерных процессоров общего назначения многоядерными на обычных персоналках, так как достигнут практический предел увеличения тактовой частоты. Поэтому распараллеливание вычислений становится распространенным явлением. Это и есть "вызов" языкам программирования. :!:

Для сетей контроллеров характерно совершенно другое. Специфические задачи решаются на специально выделенных для этого микроконтроллерах. Мощность микроконтроллера подбирается под задачу, и вся она целиком решается этим микроконтроллером. Взаимодействие между микроконтроллерами (например, через шину CAN или FlexRay) сведено к необходимому минимуму. Сеть контроллеров благодаря узкой функциональной специализации микроконтроллеров, дублированной кольцевой шине и тройному модульному резервированию микроконтроллеров (включая память) надежнее защищена от сбоев и механических повреждений, чем система на мощном универсальном процессоре. :D Но она, конечно уязвима для программных ошибок. :(


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Среда, 22 Август, 2007 23:43 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1254
Сергей Прохоренко писал(а):
Распараллеливание вычислений совершенно не характерно для микроконтроллеров. Им не приходится решать такие задачи ...

Извините, Сергей, но у вас или очень однобокое понимание ЧТО ДОЛЖНЫ делать микроконтроллеры, или – очень старое.
Не верите мне – зарегистрируйтесь на муровском сайте по Си-форту – только для получения описания видения Муром со товарищи (на основании анализа тенденций), к чему идёт отрасль. Первым же примером применения нового процессора является... музыкальный центр :о) (там – от самих алгоритмов дешифрации потоков и до непосредственно управления периферией и связью между блоками)
Дальше – работа по анализу поступающей информации в аудиодатчике.
Что значит – ОБЪЁМНЫЕ задачи?
Величины входных файлов для декодера аудиопотока ЗНАЧЕНИЯ НЕ ИМЕЮТ! Главное, в этом случае, успеть дешифровать поток и передать его на ЦАП-части с соблюдением всех требований по качеству дешифрации и обработке. А будет это 1024 байта или 4-хгигобайтный фильм с ДиВиДи – КАКАЯ РАЗНИЦА?
Сергей Прохоренко писал(а):
Язык программирования, на котором описываются распараллеливаемые (чуть язык не сломал!) вычисления, должен иметь конструкции для описания разбиения задач на параллельные подзадачи, где это невозможно сделать автоматически.

Свежая мысль! :о)))
А ЧТО вы распараллеливаете? По какому аспекту, нюансу, понятию вы допускаете «невзаимовлияние» взаимодействующих сущностей?
Нет, ну, в общем, - понятно по дисциплине доступа к данным. Но – какой базовый набор (идеологию) вы выберете? Мне и позиксная понятна, и Акттивного Оберона (Явы) и из Лимбо (или QNX). Можно ещё на шаг дальше – как в Зонноне (Композите).
В том-то и вопрос...
Сергей Прохоренко писал(а):
Компилятор должен обладать средствами автоматического разбиения задач на параллельные подзадачи, где это возможно.

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

Нет никакого вызова. Если не изменится отношение к решениям задач максимум на что сподигнуться «распараллеливатели» - разнесением задач Оси и пользователей по отдельным исполняющим устройствам... И не на уровне языка описание будет, а, всё та же песня – на уровне библиотек и «пришлёпок»...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Четверг, 23 Август, 2007 15:04 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Владимир Лось писал(а):
Сергей Прохоренко писал(а):
Распараллеливание вычислений совершенно не характерно для микроконтроллеров. Им не приходится решать такие задачи ...

...
Что значит – ОБЪЁМНЫЕ задачи?


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

Цитата:

Сергей Прохоренко писал(а):
Компилятор должен обладать средствами автоматического разбиения задач на параллельные подзадачи, где это возможно.

Тогда на вас ложиться огромный труд научить компилятор зачаткам понятий из вашей предметной области... :о))))) Будем писать экспертную систему для обучения компиляторов? :о)


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

Цитата:
Сергей Прохоренко писал(а):
До недавнего времени распараллеливание вычислений было головной болью специалистов в узких областях, но сейчас происходит вытеснение одноядерных процессоров общего назначения многоядерными на обычных персоналках, так как достигнут практический предел увеличения тактовой частоты. Поэтому распараллеливание вычислений становится распространенным явлением. Это и есть "вызов" языкам программирования.

Нет никакого вызова. Если не изменится отношение к решениям задач максимум на что сподигнуться «распараллеливатели» - разнесением задач Оси и пользователей по отдельным исполняющим устройствам... И не на уровне языка описание будет, а, всё та же песня – на уровне библиотек и «пришлёпок»...


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Четверг, 23 Август, 2007 18:32 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
info21 писал(а):
Забыл добавить самое важное 8))

Теперь в Обероне INTEGER явно объявлен как 32-битовый, а SHORTINT и LONGINT исключены совсем (что, считаю, правильно для "общего знаменателя").


И как это будет работать на 8-битных контроллерах (если уж речь зашла о применимости оберона именно там)?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Четверг, 23 Август, 2007 21:24 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8861
Откуда: Россия, Орёл
Так SYSTEM.BYTE нихто не отменял... :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Четверг, 23 Август, 2007 21:49 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Так SYSTEM.BYTE нихто не отменял... :-)


А не запарит для всяких счетчиков цикла использовать SYSTEM?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Четверг, 23 Август, 2007 22:00 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8861
Откуда: Россия, Орёл
Таки есть нижний порог, при котором от бедности уже приходится отказываться от ЯВУ...
(Точно так же, как есть нижний порог, с прицелом на который сегодня нужно проектировать операционку широкого применения - это наличие MMU)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Четверг, 23 Август, 2007 22:03 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8861
Откуда: Россия, Орёл
А вообще, при реализации компилятора под конкретную платформу никто не мешает добавить тип данных для этой платформы...
Вирт, между прочим, с Oberon SA для встроенных применений вполне мудро поступил - получил язык, который непосредственно отображается на Strong-ARM, как С на PDP некогда...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Четверг, 23 Август, 2007 23:28 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
А вообще, при реализации компилятора под конкретную платформу никто не мешает добавить тип данных для этой платформы...


Никто не мешает. Только переносимость кода будет еще хуже чем у C с его плавающей разрядностью встроенных типов.

Илья Ермаков писал(а):
Вирт, между прочим, с Oberon SA для встроенных применений вполне мудро поступил - получил язык, который непосредственно отображается на Strong-ARM, как С на PDP некогда...


Для каждого дела свой язык - это идеал. Недостижимый для мэйнстрима :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Пятница, 31 Август, 2007 15:28 

Зарегистрирован: Среда, 29 Август, 2007 17:25
Сообщения: 33
Откуда: Минск, Беларусь
Наконец-то Вирт убрал RETURN, который, как и GOTO, противоречит правилам структурного программирования. Это был единственный серьезный ляпсус.

Еще мне бы хотелось писать все ключевые слова строчными буквами (мелочь, конечно).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Воскресенье, 02 Сентябрь, 2007 10:11 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7712
Откуда: Троицк, Москва
Вечером 31-го пришли "окончательные" версии документов, датированные 1.09.2007.
Но там обнаружена пара опечаток... так что пока явного "можно выкладывать!" не поступило.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Воскресенье, 02 Сентябрь, 2007 10:54 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7712
Откуда: Троицк, Москва
Кирилл Сурков писал(а):
Наконец-то Вирт убрал RETURN, который, как и GOTO, противоречит правилам структурного программирования. Это был единственный серьезный ляпсус.


Не как GOTO -- про RETURN всегда ясно, куда он прыгает.
И не единственный -- EXIT в LOOP имеет ту же природу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Оберон-007
СообщениеДобавлено: Понедельник, 19 Ноябрь, 2007 18:05 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
info21 писал(а):
...так что пока явного "можно выкладывать!" не поступило.

К католическому Рождеству-то можно ожидать?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Понедельник, 19 Ноябрь, 2007 18:30 

Зарегистрирован: Среда, 29 Август, 2007 11:04
Сообщения: 91
info21 писал(а):
Не как GOTO -- про RETURN всегда ясно, куда он прыгает.
И не единственный -- EXIT в LOOP имеет ту же природу.

RETURN -- это фактически GOTO END, разве не так? Проблема GOTO и RETURN в том, что программа "выпрыгивает" с любого уровня вложенности операторов на самый верх, создавая разрывы в логике, которые трудно отследить.
Оператор EXIT "выпрыгивает" на один уровень вверх, к тому же не имеет аргументов и не может создать ошибку (например, переполнения, при выполнении выражения RETURN A+B).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Понедельник, 19 Ноябрь, 2007 19:29 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Дмитрий Сурков писал(а):
RETURN -- это фактически GOTO END, разве не так?


Не так. RETURN - это возврат результата. Больше ничего. Усматривать тут GOTO - это паранойя.

Дмитрий Сурков писал(а):
Проблема GOTO и RETURN в том, что программа "выпрыгивает" с любого уровня вложенности операторов на самый верх, создавая разрывы в логике, которые трудно отследить.


Странная у вас логика. Никто никуда не прыгает, функция возвращает результат. С точки зрения вызывающего кода точка возврата одна. Вас не пугает оператор IF? Он тоже "прыгает" в ветку ELSE (которая в случае принципиального отказа от RETURN может оказаться довольно "далеко" и слабо различима на фоне кучи других вложенных IF).

Дмитрий Сурков писал(а):
к тому же не имеет аргументов и не может создать ошибку (например, переполнения, при выполнении выражения RETURN A+B).


Ошибку выполнения создает не оператор RETURN, а выражение. result := A + B; EXIT; создаст точно такую же ошибку.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Понедельник, 19 Ноябрь, 2007 19:53 

Зарегистрирован: Среда, 29 Август, 2007 11:04
Сообщения: 91
Vlad писал(а):
Дмитрий Сурков писал(а):
RETURN -- это фактически GOTO END, разве не так?

Не так. RETURN - это возврат результата. Больше ничего. Усматривать тут GOTO - это паранойя.
Странная у вас логика. Никто никуда не прыгает, функция возвращает результат. С точки зрения вызывающего кода точка возврата одна. Вас не пугает оператор IF? Он тоже "прыгает" в ветку ELSE (которая в случае принципиального отказа от RETURN может оказаться довольно "далеко" и слабо различима на фоне кучи других вложенных IF).
Ошибку выполнения создает не оператор RETURN, а выражение. result := A + B; EXIT; создаст точно такую же ошибку.


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

Слово "нельзя" здесь и далее означает не "Вам нельзя", не "никому нельзя", а некое правило, которое можно спокойно обсуждать и ставить под сомнение :-) Из своего опыта я понял, что это правило очень облегчает анализ написанного чужого кода.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Понедельник, 19 Ноябрь, 2007 21:16 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
На мой взгляд, RETURN ничем не нарушает принципов структурного программирования.
Смотрите: при выходе из цикла мы переходим к оператору, непосредственно следующему за циклом.
При возврате из процедуры -- к оператору, непосредственно следующему за оператором вызова процедуры.
При чтении текста вызывающей процедуры нам не приходится гадать, куда вернется управление.

Чем плохи goto и break (кроме запутанности текста при использовании goto, как в игре "гусек")?
Рассмотрим цикл
Код:
while (B) {
    ...
}
L1: S;
Естественно полагать, что при выходе из цикла (помеченном L1) будет выполнено условие !B.
А если в теле цикла стоит break?

В отношении же RETURN подобных неудобств пока не вижу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Понедельник, 19 Ноябрь, 2007 22:15 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Дмитрий Сурков писал(а):
Оператор RETURN -- это прежде всего передача управления. Смысл моих утверждений был в том, что не должно существовать операторов передачи управления между несколькими составными операторами.


Вызов функции - это тоже передача управления. Причем вообще неизвестно куда. Отменим функции? :) Не надо доводить идеи до абсурда. Принципиален не факт передачи управления, а контроль управления. В случае вызова функции контроль не теряется, потому в точке вызова известно куда управление вернется. В случае RETURN контроль тоже не теряется - управление возвращается в точку вызова.

Дмитрий Сурков писал(а):
Нельзя из одного составного оператора "входить" в другой (это позволяет GOTO) и нельзя "выходить" сразу из нескольких составных операторов (это позволяет RETURN).


А почему ставится тождество между "входить" и "выходить"?

Дмитрий Сурков писал(а):
Слово "нельзя" здесь и далее означает не "Вам нельзя", не "никому нельзя", а некое правило, которое можно спокойно обсуждать и ставить под сомнение :-) Из своего опыта я понял, что это правило очень облегчает анализ написанного чужого кода.


Из своего опыта я понял, что глубоко вложеные структурные операторы очень затрудняют чтение кода. После второго уровня уже приходится обращаться к специальным возможностям редактора. А вот RETURN мне никогда не мешал (только не надо придумывать клинические случаи его неправильного использования).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07
СообщениеДобавлено: Вторник, 20 Ноябрь, 2007 02:26 

Зарегистрирован: Среда, 29 Август, 2007 11:04
Сообщения: 91
AVC писал(а):
На мой взгляд, RETURN ничем не нарушает принципов структурного программирования.
Смотрите: при выходе из цикла мы переходим к оператору, непосредственно следующему за циклом.
При возврате из процедуры -- к оператору, непосредственно следующему за оператором вызова процедуры.

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

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


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

Часовой пояс: UTC + 3 часа


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

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


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

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2017, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB