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

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 29 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Вс июн 15, 2014 21:45 
Оффтоп про КОРОБКИ: http://www.gudleifr.h1.ru/65.html.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Вс июн 15, 2014 23:46 
Не в сети
Аватара пользователя

Зарегистрирован: Вт мар 20, 2007 23:39
Сообщения: 1261
Благодарил (а): 3 раз.
Поблагодарили: 19 раз.
Ого, короткий линк? А почему не длинный с кучей нестандартных символов? :)) :lol:

_________________
Cтоимость сопровождения программного обеспечения пропорциональна квадрату творческих способностей программиста.
Роберт Д. Блисc


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Пн июн 16, 2014 00:49 
VoidVolker писал(а):
А почему не длинный с кучей нестандартных символов?
В смысле, когда форумный движок научится жрать ссылки на мою базу данных?
Не знаю.

Про базу я уже Вам, насколько помню, объяснял (http://forum.msyst.ru/viewtopic.php?f=46&t=122)...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Пн июн 16, 2014 15:18 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
in4 писал(а):
gudleifr писал(а):
1. Словоподобные структуры удобны для представления некоторой информации о действиях программы
2. Создание подобных структур программой вполне допустимо

Из (1) и (2) следует: FORTH-программа вполне может сама программировать на FORTH!
Потенциально. А на деле не хватает нескольких механизмов.
Каких?
Как об этом прочитал, сразу увидел, что на стандартной системе будет чего-то не хватать, а как задумался о реализации - мысли расползлись по вариантам, что трудно изложить. Несколько вариантов, зависит от реализации программирования программой. Как минимум, поддержка варианта шаблонов - иначе сложновато искать ошибки. Что-то из описания системы - если кодогенерация через входной буфер - возможность в него писать и из него читать. Или переназначать входной буфер на строки. И, самое главное, алгоритм, который надо закодировать - его получение, хранение, обработка - лучше, если это будут специальные слова. В общем, надо попробовать, а потом соптимизировать.

gudleifr писал(а):
А есть ли смысл разделять "компиляцию кода" и "создание структуры данных"?
Да. Как минимум для машин гарвардской архитектуры. И систем, у которых работа(скорость работы) зависят от того, как делаются обращения к коду (вроде в некоторых интеловских процессорах свежесгенерированный/докомпилированный код работает медленнее).

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Пн июн 16, 2014 15:34 
in4 писал(а):
... Как минимум для машин гарвардской архитектуры...
Наоборот. В машинах Гарвардской архитектуры шитый код неотличим от "обычных" структур данных, иначе никакие "определения через двоеточие" там невозможны.
Тоже касается и других Ваших утверждений - просто мы с Вами по-разному называем одни и те же вещи.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Пн июн 16, 2014 16:19 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
В машинах Гарвардской архитектуры шитый код неотличим от "обычных" структур данных, иначе никакие "определения через двоеточие" там невозможны.

Это определяется реализацией доступа к памяти кода. Машинный код прекрасно компилируется на лету и в гарвардской архитектуре.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Пн июн 16, 2014 16:35 
Хищник писал(а):
Это определяется реализацией доступа к памяти кода.
Реализация тут не при чем. Метод работает независимо от способности к генерации маш.кода.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Пн июн 16, 2014 16:38 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Хищник писал(а):
иначе никакие "определения через двоеточие" там невозможны

"Иначе" как раз возможны. Гарвардская архитектура как таковая не означает запрет на доступ к памяти кода для чтения/записи в процессе работы.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Пн июн 16, 2014 16:44 
Хищник писал(а):
"Иначе" как раз возможны.
Они возможны "и иначе, и не иначе", независимо от доступа к маш.коду. Эквивалентность РАМ- и РАСП-машин никто пока не отменял.
"Иначе" относилось к обязательности неотличимости шитого кода от структур данных.

Хотя, конечно, если рассматривать Гарвард как просто кривой Фон-Нейман, то мое "наоборот" слишком сильно. Скорее, надо "невзирая на"...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Вт июн 17, 2014 00:37 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Хотя, конечно, если рассматривать Гарвард как просто кривой Фон-Нейман, то мое "наоборот" слишком сильно. Скорее, надо "невзирая на"...

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Вт июн 17, 2014 00:38 
Хищник писал(а):
Так что с гарвардской архитектурой не так?
С ней настолько все в порядке, что поминать ее "своеобразие" в этой теме было излишним.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Вт июн 17, 2014 13:45 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
Реализация тут не при чем. Метод работает независимо от способности к генерации маш.кода.
Метод-то работает. Но скорость работы будет зависеть от реализации.

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

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

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

Хищник писал(а):
Так что с гарвардской архитектурой не так?
Дополнительный(нарушающий единообразность) способ доступа к коду программы. Необходимость иметь дополнительный набор слов ( , -- [c], и аналогично). Но вроде это цена за "безопасность". Или дополнительный контроль за правильностью работы аппаратуры.
Тут тоже разделение - чисто программные решения и программно-аппаратные. Во втором случае контроль важен. Если аппаратура работает неправильно, программы, скорее всего, тоже не смогут работать правильно(хотя некоторые дефекты и можно исправить программно).

А вот в первом случае возможно перекладывание недостаточной квалификации разработчика (недостаточно развитых средств разработки) с программной части на аппаратную. Типизация - один из примеров. Мур+Броуди не поддерживают идеи типизации - арифметические операции с логическими значениями - свидетельство.

Т.е. гарвардская архитектура (разделение команд и данных) - это некоторое снижение гибкости. Но и некоторое повышение надежности. И если она встретилась в целевой системе - ее особенности надо обязательно учитывать.

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Вт июн 17, 2014 14:37 
in4 писал(а):
Если реалтайм компиляция+работа требует больше времени, чем проход с условиями по структурам данных, либо на перекомпиляцию будет тратиться ограниченный ресурс системы (количество перезаписей флеш) - то это существенные отличия...
Не надо под предлогом выдуманных проблем (на Вас, что, висит десяток FORTH-проектов, которые жутко тормозят?) переходить на правдоподобные философские выводы.
Шитый код изоморфен или не изоморфен структурам данных независимо от скорости Гарвардов (как-то уже свыклись с тем, что FORTH есть FORTH независимо от вида шитого кода).
То, что я оперирую при разработке программы терминами "вторичная FORTH-машина" не значит, что в итоговом варианте от этой "машины" не останется слово-заглушка.

Опять "термины"...

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

OFFTOP
Например, бесполезно включать в FORTH ассоциативные массивы. Они в нем уже есть - словарь называется. Т.е. создавая ассоциативный массив "особого вида" я просто создаю "особую" FORTH-машину, которая "по реализации" может и отличаться от первичной, но не требует для своего описания никаких новых терминов, окромя исконно-FORTH-овских.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От удаления объектов - к ран-тайм компиляции
СообщениеДобавлено: Вт июн 17, 2014 18:26 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
in4 писал(а):
Т.е. гарвардская архитектура (разделение команд и данных) - это некоторое снижение гибкости. Но и некоторое повышение надежности. И если она встретилась в целевой системе - ее особенности надо обязательно учитывать.

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


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

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


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

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


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

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