DRAKON.SU

Текущее время: Среда, 24 Январь, 2018 14:58

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




Начать новую тему Ответить на тему  [ Сообщений: 163 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9
Автор Сообщение
СообщениеДобавлено: Понедельник, 02 Август, 2010 11:46 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 189
Откуда: Россия, Санкт-Петербург
dvuugl писал(а):
Каждая из них по-своему будет "прятать" GOTO, но каждая в конце концов столкнётся с задачей, которая которая для БОЛЕЕ ЭФФЕКТИВНОЙ РАЗРЕШИМОСТИ- А ЗНАЧИТ И ДЛЯ СОБСТВЕННО РАЗРЕШИМОСТИ, ЕСЛИ В ПОСТАНОВКЕ ЗАДАЧИ ТРЕБУЕТСЯ ИМЕННО ЭФФЕКТИВНОСТЬ потребует или другого базиса, или углубления в свои "недра", туда где GOTO, "в виде исключения".
Сие есть весьма странный аргумент. Мало ли что кому потребуется. Я так считаю, что эффективность ни при чём. Её можно решать увеличением производительности железа, что тоже переводит вопрос за пределы алгоритмического "базиса". Другими словами, требование производительности не есть требование GOTO.

Аргумент не работает в пользу GOTO ещё и вот по какой причине: чтобы для разрешимости задачи был необходим GOTO, достаточно указать его необходимость в условии задачи ("решить с использованием GOTO").

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Август, 2010 13:10 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Кроме того, следует знать тот факт, что GOTO на современной архитектуре может сильно снизить производительность, потому что это сбивает компилятор и не позволяет ему генерировать чистый, оптимальный код.
Особенно это будет проявляться на широком командном слове (VLIW, EPIC), где компилятор упаковывает тело цикла в как можно меньшее количество широких командных слов, для параллельного выполнения нескольких независимых операций (иногда более 10) за такт.

Не говоря про то, что есть аппаратные архитектуры, изначально спроектированные под конструкции ЯВУ (машины Вирта, новосибирский "Кронос", стековая "Сетунь-2" Брусенцова, ориентированная на ДССП - "диалоговую среду структурного программирования", тереховский "Самсон" - последний является промышленной системой и эксплуатируется на АТС спецсвязи, как раз категория встроенных систем реального времени).

GOTO может брать начало в некоторых "бытовых" приёмчиках, вроде инструкций "если не... то иди на п. 4 инструкции", хотя спорный вопрос, пришло ли кому-нибудь бы в голову писать в таком стиле в докомпьютерную эпоху (скорее было бы описано каким-то сложным предложением в стиле "до тех пор, пока.."). В вычислительной же технике это имеет основу в возможном устройстве управляющего автомата выч. машины, ещё с абстракции машины Тьюринга - "перейди на такую-то клетку ленты". Частный механизм.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 12 Август, 2010 05:05 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Снова о БП
Илья Ермаков в viewtopic.php?p=50251#p50251 писал(а):
Не говоря про то, что есть аппаратные архитектуры, изначально спроектированные под конструкции ЯВУ (машины Вирта, новосибирский "Кронос", стековая "Сетунь-2" Брусенцова,...
В вычислительной же технике это имеет основу в возможном устройстве управляющего автомата выч. машины, ещё с абстракции машины Тьюринга - "перейди на такую-то клетку ленты". Частный механизм.

Да, машина Тьюринга отражает адресный (координатный, т.е. диаматически - от пространства, информатизованного разметкой на нумерованные клетки) подход к архитектуре формального исполнителя алгоритмов (в плане организации работы), а есть также, конечно, и стековый (по порядку поступления/использования алгоданных, т.е. - от времени, информатизованного порядком записи/выборки), и ассоциативный (по содержанию данных независимо от координат и времени, т.е. - от движения как "изменения вообще", различия, информатически отражаемого значением элемента данных). И возможны аналогичные "конструктивно-физические" абстракции для двух других подходов - "стековая машина", "ассоциативная машина" - да они и есть наверное.
Конечно, БП в явном виде нужен именно в адресной парадигме - в стековом процессоре будет свой механизм, в ассоциативном - свой (как и для естественного перехода, и для условного). Я всё время имел в виду именно адресную, но не указал это явно, прошу прощения - получилось, что другие т. зр. вообще игнорируются. В то же время любой алгоритм в высокоуровневой записи м.б. закодирован для исполнения любой из этих машин - поэтому каждая из них не частный механизм, а равноправный класс командных моделей.

Илья Ермаков в viewtopic.php?p=50251#p50251 писал(а):
Особенно это будет проявляться на широком командном слове (VLIW, EPIC), где компилятор упаковывает тело цикла в как можно меньшее количество широких командных слов, для параллельного выполнения нескольких независимых операций (иногда более 10) за такт.

К сожалению, деталей реализации этих и подобных архитектур не знаю. Но если отталкиваться от данного выше общего представления, возникает следующее представление. Компилятор может делать всё, что угодно, но если процессор адресный ("тьюрингов") - посмотрев на его граф-схемы микроопераций как автомата Глушкова, не обнаружим ли мы там среди случаев фазы определения адреса следующей МОп, наряду с вычислением "прибавь к начальному адресу текущей команды её длину" (что реализует естественный переход в адресной парадигме), также действие "возьми следующий адрес из заданного элемента памяти" - что и есть реализация БП в адресной парадигме? Т.е. мы имеем БП, но на уровне аппаратуры ("схемокода"), ниже уровня программного кода исполняемого алгоритма.
Вот такие мысли.

А на более высоком уровне явный БП удобен для структурирования алгоконструкций, облегчения мысленных операций над ними (особенно тому, кто не тополог по складу ума и не может, скажем, просчитать сложную рокировку матрёшки, воспринимая её как единое целое) - чем и пользуюсь в Драконографике. Конечно, он не обязателен в алгоритме - имея в виду вышесказанное, что программирование может исходить из неадресной парадигмы - но удобен как раскрытие смысла точек слияния маршрутов на нелинейных ГСА (и точек членения линейных маршрутов на фрагменты меньшего объёма при ограничениях на объём фрагмента).


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

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


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

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


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

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